Jump to content

EFI Variable Store on Aptio V (Haswell-E and up)

mhaeuser

By mhaeuser,
in UEFI

 Share
198 posts in this topic

Recommended Posts

goodwin_c
goodwin_c
Posted
Posted

RunImageWithOverrides is not supposed to return.

 

EDIT: Sorry, overread the last message...  that OvrSetVirtualAddressMap works fine proofs that the issue is not related to the original SMM buffer issue (physical and virtual write to the same buffer here). Also, KernelEntryPatchJumpBack is not called with AptioFix2 - call it and try again?

 

Yeah, missed that KernelEntryPatchJumpBack is commented in MOExitBootServices. Than FixBootingWithoutRelocBlock is not called as well. So looks like that on all stages of AptioFix - nvram is still working fine.

What is sequence - Clover+AptioFix, than boot.efi and then kernel? No calls to AptioFix between boot.efi and kernel?

Also, am i right that MOExitBootServices is last call to AptioFix? I can still write to nvram before exiting from MOExitBootServices. Is there any way to test nvram between boot.efi and kernel?

P.S. Looks like i just confused with KernelEntryPatchJumpBack and commented KernelEntryFromMachOPatchJump call in MOExitBootServices. 

P.P.S. Ahaaa. Looks like KernelEntryFromMachOPatchJump calls KernelEntryPatchJump and it is matching entry point with asm code to call KernelEntryPatchJumpBack later. Huh. Is it right? Not so easy to understand all steps.

P.P.S. Does this mean that if i will uncomment KernelEntryFromMachOPatchJump than we will have call to AptioFix in between of boot.efi and real kernel?

Ok, new results. Uncommented KernelEntryPatchJumpBack and now i have variable created from KernelEntryPatchJumpBack. This is last called point from AptioFix that i know. Do you have any other ideas to check? Looks like nvram is working properly when called from AptioFix on all available stages. If KernelEntryPatchJumpBack is really called after boot.efi (i'm not sure, but looks like so) - then nvram is broken by kernel or kext, or it not broken physically - and macos is just making wrong call to runtime services to write variable (can this be related to IODeviceTree entries? Maybe bcz of some reason AppleEFIRuntime is not doing things right?)

Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

Yes. AptioFix replacs the kernel entry to do the reloc block stuff, this is not needed for AptioFix2 though, hence disabled. SetVirtualAddressMapp is currently the last call, I think. I would try the userland app I suggested.

 

Yeah, and before exiting from OvrSetVirtualAddressMap nvram is still writable. and on exit from KernelEntryPatchJumpBack - it is also working. you can share any thoughts and ideas - and i will try to help as much as i can. Really nvram is not so big deal - there is almost zero problems with Emu driver. But it is annoying me - i want to bring as much working things as possible. Already fixed most things on my laptop - sleep, video glitches (famous HD530), made Speed Shift working (both using freq vectors for native support starting from ElCap and through my own kext - for manual controlling this feature), full fix of ACPI (not best code by Dell, even linux throws a lot of acpi errors in log) and e lot of other things. But NVRAM issue is annoying me.

Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

boot.efi bumps the event OnExitBootService so AptioFix will be called again.

 

In MOExitBootServices i have also one rt->setvariable before return - and it is creating fine. so as for now looks like problem starts after kernel boot, i think it is somewhere around AppleEFIRuntime kext and it's plugin for nvram

Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

Yes. AptioFix replacs the kernel entry to do the reloc block stuff, this is not needed for AptioFix2 though, hence disabled. SetVirtualAddressMapp is currently the last call, I think. I would try the userland app I suggested.

Do you have any success with user app? Do you have any example of code to access runtime services?

Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

Hey, something interesting - Slice suggested to check dmpstore for BS variables - and guess what? There are NvramSmiBuffer and NvramMailbox with physical addresses inside - but this addresses are in Available regions of memory, looks like they are not protected by UEFI in any way. Do you think we can try to analyze this variables and manually protect this regions? But main problem is - how to detect size of this regions...

There are memmap and dmpstore dumps, you can check

https://drive.google.com/open?id=0B1xZ4VKT4JKZcmN5eTVETjJLZkU

https://drive.google.com/open?id=0B1xZ4VKT4JKZeEhDUDU1OGhfSVE

Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

Ok, sorry, i was not really right - i forgot that we are dealing with endian, it has reversed order.

So, looks like NvramSmiBuffer is located inside of last RT_Data block that is protected by MMIO renaming. Same region contains original SystemTable

About NvramMailbox - it is located in next region after RtData with SystemTable - it is RT_Code region, and it is renamed by AptioFix to AcpiNVS. Also, AptioFix removes realtime flag from that region. Maybe this is our problem? But any changes to that part of code in AptioFix makes my system unbootable - mostly, it is freeze on kexts load stage (somewhere after FakeSMC load. I suppose that AppleEFIRuntime is loaded somewhere around)

Link to comment
Share on other sites
  • 2 weeks later...
mhaeuser
mhaeuser
Posted
  • Author
Posted

Ok, sorry, i was not really right - i forgot that we are dealing with endian, it has reversed order.

So, looks like NvramSmiBuffer is located inside of last RT_Data block that is protected by MMIO renaming. Same region contains original SystemTable

About NvramMailbox - it is located in next region after RtData with SystemTable - it is RT_Code region, and it is renamed by AptioFix to AcpiNVS. Also, AptioFix removes realtime flag from that region. Maybe this is our problem? But any changes to that part of code in AptioFix makes my system unbootable - mostly, it is freeze on kexts load stage (somewhere after FakeSMC load. I suppose that AppleEFIRuntime is loaded somewhere around)

Any news on this? If flagging RT_code as MMIO as well doesn't work, I ran out of ideas. Will need to check the ASM diff some day, but I'm busy.

 

EDIT1:

post-895511-0-06508900-1482874735_thumb.png

 

Would you be ready to flash your fw? Could try removing setting mVirtual to 0 - this happens when an unknown event is triggered. Windows and Linux might be mapping physical->virtual.

 

EDIT2:

Hmm, actually no event should trigger after SetVirtualAddressMap, so setting it to 0 should not happen after that. :/

 

EDIT3:

@D-F Just thought I'd throw my research into the mix. I have found that you can enable NVRAM writes in Asus AptioV bioses my replacing the NvramSmi SMM module with the combined SMM/DXE NvramSmi module (same GUID) from older bioses that allow NVRAM writes. You also need to delete the NvramSmiDxe driver module when you do this replacement. Unfortunately this only seems to work for Asus boards. Have tried using the combined SMM/DXE module in ASRock bioses but no go. So it seems to be that NvramSmi implementation is where the issue lies, unfortunately I don't know how to proceed from here...

And you did not replace the driver called 'Runtime'?

Link to comment
Share on other sites
dgsga
dgsga
Posted
Posted

EDIT3:

And you did not replace the driver called 'Runtime'?

@D-F Just thought I'd throw my research into the mix. I have found that you can enable NVRAM writes in Asus AptioV bioses my replacing the NvramSmi SMM module with the combined SMM/DXE NvramSmi module (same GUID) from older bioses that allow NVRAM writes. You also need to delete the NvramSmiDxe driver module when you do this replacement. Unfortunately this only seems to work for Asus boards. Have tried using the combined SMM/DXE module in ASRock bioses but no go. So it seems to be that NvramSmi implementation is where the issue lies, unfortunately I don't know how to proceed from here...

 

@D-F. I'm willing to experiment. I have a FastBootRuntimeDxe and a RuntimeSmm but no RuntimeDxe. I presume I need to try replacing the RuntimeSmm?? When I do these replacements should I just replace the PE32 image body or the entire ffs?

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
  • Author
Posted

@D-F. I'm willing to experiment. I have a FastBootRuntimeDxe and a RuntimeSmm but no RuntimeDxe. I presume I need to try replacing the RuntimeSmm?? When I do these replacements should I just replace the PE32 image body or the entire ffs?

No, I meant when you tried earlier, you only replaced the NvramSmi/Dxe driver and you did not touch Runtime* ?

Link to comment
Share on other sites
  • 2 weeks later...
  • 2 weeks later...
  • 4 weeks later...
Slice
Slice
Posted
Posted

Now I also have testing machine. Comp#1 in my sig. And I want to continue the investigations.

Nvram reads working everywhere. Writes working in Clover and not in macOS.

I see no significant difference in memory map between working and non-working case with other users:

- same RT_Data

- same NvramSmiBuffer location

- same redirection and virtualization

- same MMIO protection

It seems to be not a real reason.

  • Like 4
Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
  • Author
Posted

Can somebody please confirm being 100% sure that writing a random variable (e.g. "Test") works on either Linux or Windows?

Just looked at the broken driver again and what I saw made zero sense to me.

Alternatively I can provide a modded AptioFix that reboots if write fails (so, the tester would need to be able to use UEFI Shell).

 

EDIT: nvm, AptioFix test will not work.

  • Like 2
Link to comment
Share on other sites
  • 3 months later...
goodwin_c
goodwin_c
Posted
Posted

Can somebody please confirm being 100% sure that writing a random variable (e.g. "Test") works on either Linux or Windows?

Just looked at the broken driver again and what I saw made zero sense to me.

Alternatively I can provide a modded AptioFix that reboots if write fails (so, the tester would need to be able to use UEFI Shell).

 

EDIT: nvm, AptioFix test will not work.

Yes, NVRAM writes from Linux just fine (same as writing random data and deleting existing variables), and also it works just fine from EFI stage (preboot). But from moment when boot.efi catches control - NVRAM writes are not working anymore (but reads just perfectly)

Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
  • Author
Posted

Yes, NVRAM writes from Linux just fine (same as writing random data and deleting existing variables), and also it works just fine from EFI stage (preboot). But from moment when boot.efi catches control - NVRAM writes are not working anymore (but reads just perfectly)

preboot is not a good factor because the Variable services are replaced for Runtime (so, for Windows, Linux, macOS, ...), but Linux is fine. Also, NVRAM read in macOS is likely not fine, though seems to work because macOS caches the variables into DT. I don't think I can be much of a help without the necessary hardware, sorry.

Link to comment
Share on other sites
goodwin_c
goodwin_c
Posted
Posted

about preboot - yes, it is place where SMI is not working yet for NVRAM protection. About macos reading - i suppose it should be sign that things are not too bad - as i remember, in moment when boot.efi starts we have already SMI NVRAM initialized (and this is affecting on AMI uefi only write function, get func is not touched during this)

If you have at least any ideas, even most crazy ones - i can test on my laptop. And i can provide any information that you may need. I have try a lot of my ideas - no one worked. So currently I don't know in which direction to move.

  • Like 2
Link to comment
Share on other sites
  • 1 month later...
gujiangjiang
gujiangjiang
Posted
Posted

about preboot - yes, it is place where SMI is not working yet for NVRAM protection. About macos reading - i suppose it should be sign that things are not too bad - as i remember, in moment when boot.efi starts we have already SMI NVRAM initialized (and this is affecting on AMI uefi only write function, get func is not touched during this)

If you have at least any ideas, even most crazy ones - i can test on my laptop. And i can provide any information that you may need. I have try a lot of my ideas - no one worked. So currently I don't know in which direction to move.

 

I have found a document about uefi-variables in ubuntu.

https://firmware.intel.com/blog/accessing-uefi-variables-linux

 

I found it have fakesmc-key in our native-nvram i think it maybe clover do.

 

So i have an idea to figure out want to happend.

 

When in ubuntu,open the terminal and type /sys/firmware/efi/vars/

Then you will find a lot of native nvrams,each of nvrams have 5 files below:

attributes

data

guid

raw_var

size

Now i want to find a real mac device and run in ubuntu and also get into /sys/firmware/efi/vars/ and find each os this 5 files.

 

I think it maybe can describe why osx cant r/w our native nvram if we compare this files.

 

Such as guid value if format is not accepted by osx then osx cant r/w it.

 

If we can find the real reason about why ouer native-nvram cant work througout ubuntu and we will find a solution to solve this.

 

But i dont have real mac and near so if you have times you can look into these folders and files and compare to a real mac and find some regular.

 

Thanks.

Link to comment
Share on other sites
  • 1 month later...
 Share
Go to topic listing
×
×
  • Create New...