Jump to content
vit9696

AptioMemoryFix

484 posts in this topic

Recommended Posts

I do not believe that the UDK-provided ZeroMem could be of any issue. If it is, then it should reported to edk2-devel.
right. in do part, there is something wrong in some bios.
zeromem is no problem. i checked it again.
Pavo has freeze when using cleannvram.efi.
maybe he can help you for debug.
[mention=980913]Sherlocks[/mention],
I have not looked at code. Just wild guess -- may be SMM code trying to protect integrity of NVRAM?
no. seems logic has some wrong part that causes freeze.

나의 LG-F800S 의 Tapatalk에서 보냄

Share this post


Link to post
Share on other sites
Advertisement
11 hours ago, Sherlocks said:

no. seems logic has some wrong part that causes freeze.

I just went through it and while one aspect seems to be borked, I don't see anything that should cause a stall.

Maybe GetNextVariableName() never returns EFI_NOT_FOUND on that machine? We'll need more information on the issue.

Share this post


Link to post
Share on other sites
I just went through it and while one aspect seems to be borked, I don't see anything that should cause a stall.

Maybe GetNextVariableName() never returns EFI_NOT_FOUND on that machine? We'll need more information on the issue.

 

maybe. not sure. i can't debug correctly.

i fixed this issue like this.

 

maybe some system never stop do funtion(?). Pavo system has freeze issue.

cleannvram efi is no problem on my system.

https://sourceforge.net/p/cloverefiboot/code/4718/tree//rEFIt_UEFI/Platform/Nvram.c#l341

 

 

Share this post


Link to post
Share on other sites

Hello again vit9696,

 

How are you?

I come to you with another issue related to AptioMemoryFix (latest rev):

 

When it is used on boards with chipset Z390 (and according to some other reports, it seems that also with H370/B370/H310 chipsets) - problems appear:

- it results in OSX kernel panic on reboot/shutdown (you can see some reports, for example, in this topic).

- there also seems to be a problem with native NVRAM from within OSX, as a test var saved from OSX with 'nvram' command is NOT existing after reboot (Clover's last chosen OS is being saved though).

 

I just replaced my board to an AsRock Z390 ITX/ac (I had before an AsRock Z370 ITX/ac, really similar boards), and these issues started appearing (everything was fine with AptioMemoryFix and Z370).

Now, In my case, OSX starts fine with AptioMemoryFix, but when I reboot/shutdown, I don't even get to see the console screen with panic information, and the system ends up either hanging up or (uncleanly) rebooting (I use -v, and I do see the console screen with AptioMemoryFix when OSX loads).

 

When I add EmuVariableUefi (toghether with AptioMemoryFix, although I know it is not the intended use), shutdown/reboot work properly, and I also see the -v output when shutting down or rebooting.

 

I will gladly help with any further information or tests you may need.

 

Thanks.

 

Edited by Pene

Share this post


Link to post
Share on other sites

Hi Pene,

 

I am aware of this issue, but as you can imagine I do not have the hardware to research it.

 

What happened here is another change in APTIO. In former versions there were 3 drivers to implement NVRAM: NvramDxe, NvramSmm, NvramSmi. In newer boards NvramSmi and NvramSmm became one driver. I believe we can try to research this to a certain level with a considerable amount of help from your side.

 

Frankly said, I am not sure Hardware NVRAM works on these boards in any OS at all, so the first step would be to:

1) Test NVRAM support in UEFI Linux, I believe they have a tool for this

2) Test NVRAM support in UEFI Windows, you will have to write some tool that elevates the privileges and utilises GetFirmwareEnvironmentVariableA/SetFirmwareEnvironmentVariableA APIs, see this tool for an example.

 

The "test" we want here is fairly simple. Firstly we want to try to write some variable to Apple Boot Variable GUID: 7C436110-AB2A-4BBB-A880-FE41995C9F8, then read it, reboot, and read again. If it all fails, we could try writing to Efi Global Variable GUID: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C, and check if it at least some GUIDs are available for writing.

 

Next, the kernel panic on reboot is what really worries me. We know that macOS writes stuff to NVRAM during the reboot, and I would like to know if disabling SetVariable/GetVariable, GetVariableNext "fixes" the problem with the reboot. Just like we debugged it previously, write jmp ASM_PFX(RtShimsReturnInvalidParameter) to the relevant shims here for a test:

https://github.com/acidanthera/AptioFixPkg/blob/master/Platform/AptioMemoryFix/X64/AsmRtShims.nasm

 

Thirdly, regarding the panics on reboot, I would like to get as much information as possible. Please apply the kernel patch mentioned here: https://applelife.ru/posts/686953, which disables kext list printing in the panic log, and try screening the kernel panic in -v keepsyms=1 debug=0x100 mode. We should hopefully see more data to stat to work with.

 

@Slice, unfortunately this one is new. These guys never learn, and they managed to bork things once again. So it is neither the issue we researched a year ago, nor the whitelist. It is just another extension of the borked code.

 

Vit

Edited by vit9696

Share this post


Link to post
Share on other sites
16 hours ago, vit9696 said:

What happened here is another change in APTIO. In former versions there were 3 drivers to implement NVRAM: NvramDxe, NvramSmm, NvramSmi. In newer boards NvramSmi and NvramSmm became one driver. I believe we can try to research this to a certain level with a considerable amount of help from your side.

 

Hi again,

 

Thank you for your reply. Here are some results:

 

NVRAM is writable from Windows. I used before a Windows tool for writing to the nvram (UEFIVAR). So I issued this command from Windows:

uefivar -G:"7C436110-AB2A-4BBB-A880-FE41995C9F82" -N:"TestVarWin" -WHEX:"01020304" -A:"NV"

EDIT: NVRAM is also writable from Linux:

# sudo -s
# printf "\x07\x00\x00\x00\x01\x02\x03\x04" > /sys/firmware/efi/efivars/TestVarLin-7c436110-ab2a-4bbb-a880-fe41995c9f82

And then, under OSX:

$ nvram -p | grep TestVar
TestVarWin	%01%02%03%04
TestVarLin	%01%02%03%04

 

For the second test, disabling only SetVariable in AptioMemoryFix solved the panic, and system shuts down properly.

 

For the third test, I cannot post any result, because, as I mentioned, I do not get the console window on shutdown/restart when the panic occurs, so with the steps you mentioned, I just get a black screen forever, until I press the power button to turn off the PC.

 

More tests are welcome ;)

 

P.S. Hi Slice :) But apparently as Vit mentioned we are "lucky" with a new Aptio issue. Hopefully solvable.

 

Edited by Pene

Share this post


Link to post
Share on other sites

Well, with the random reboots there is no real issue indeed, just NVRAM variable saving once again corrupts our memory. I believe, if you try to write a lot of variables from macOS the operating system will eventually panic. That could have been somewhat usable if you were able to get the log dumps, but otherwise it is probably not beneficial.

 

Basically what needs to be done here now is reverse-engineering NvramSmm/NvramDxe and comparing them against the previous versions, which we fortunately have sources for. I do not think I will have much time any soon for that, so if you have time and are able to use IDA Pro/Hex-Rays, help will be welcome here.

 

Share this post


Link to post
Share on other sites
1 hour ago, vit9696 said:

I believe, if you try to write a lot of variables from macOS the operating system will eventually panic. That could have been somewhat usable if you were able to get the log dumps, but otherwise it is probably not beneficial.

Well, I didn't manage to make macOS panic by a lot of variable writes. But then again... does OSX save these vars to EFI in runtime or does it store internally and then call SetVariable only on reboot/shutdown?

In any case, the lifetime of these added variables is just as long as the computer doesn't reboot. After reboot they are all gone.

Share this post


Link to post
Share on other sites

It depends on the GUID you write to, from what I remember. If you write to apple guid, then they are applied on later onwards, otherwise immediately. That is how I got the idea of their NVRAM driver.

Share this post


Link to post
Share on other sites

Mmmm... kernel panic did not occur when writing to any GUID (with SetVariable enabled, of course). Only on reboot/shutdown I get the panic.

And when SetVariable is disabled, it seems I can still "write" to any GUID. All Info is present while in OSX, but gone after reboot.

 

As a side note, NVRAM write can work with AptioMemoryFix when not in OSX.

So, for example, if we return InvalidParameter only when we have a virtualized pointer, Clover's Last booted OS is saved to nvram, and OSX won't panic on reboot/shutdown:

global ASM_PFX(RtShimSetVariable)
ASM_PFX(RtShimSetVariable):
    ; For performance and simplicity do initial validation ourselves.
    test       rcx, rcx
    jz         ASM_PFX(RtShimsReturnInvalidParameter)     ; VariableName is NULL
    test       rdx, rdx
    jz         ASM_PFX(RtShimsReturnInvalidParameter)     ; VendorGuid is NULL
.INITIAL_VALIDATION_OVER:
    ; Once boot.efi virtualizes the pointers we should protect read-only
    ; variables from writing.
    mov        rax, qword [ASM_PFX(gGetVariableOverride)]
    test       rax, rax
    jnz        .SKIP_ACCESS_CHECK
    ; We have a virtualized pointer, so we also need to protect write-only
    ; variables from reading. Compare VendorGuid against gReadOnlyVariableGuid
    ; and return EFI_SECURITY_VIOLATION on equals.
    mov        rax, qword [rdx]
    cmp        qword [ASM_PFX(gReadOnlyVariableGuid)], rax
    ;jnz        .SKIP_ACCESS_CHECK
jnz ASM_PFX(RtShimsReturnInvalidParameter)
    mov        rax, qword [rdx+8]
    cmp        qword [ASM_PFX(gReadOnlyVariableGuid)+8], rax
    jz         ASM_PFX(RtShimsReturnSecurityViolation)
.SKIP_ACCESS_CHECK:
    mov        rax, qword [ASM_PFX(gSetVariable)]
    jmp        short FiveArgsShim

 

Edited by Pene

Share this post


Link to post
Share on other sites

yes, of course. I just mentioned it in the idea that the code in AptioMemroyFix basically works on the new Aptio.

As with SetVariable completely disabled, Clover won't update its last booted OS, when booting OSX.

 

Edited by Pene

Share this post


Link to post
Share on other sites

ellaosx, the information is just for debugging purposes. Emuvariable is not being used, nor rc scripts. We don't have a proper solution yet.

Edited by Pene

Share this post


Link to post
Share on other sites

vit9696,

 

I figured out that if I shutdown the system using 'sudo shutdown -h now' I do get to see the panic. So here is a photo:

 

unnamed.jpg

Share this post


Link to post
Share on other sites

Hmmm, a timeout… There could be some infinite loop in their code. But let's try to disable the timeout first. Add slto_us=0 to boot-args and tell me whether anything changed.

Share this post


Link to post
Share on other sites

10000 is about the lowest that loads. And it still panics.

And about the panic details - I guess it was mere luck that I managed to see it, as once again it freezes before I get to see it.

By the way, did you notice in the previous screenshot the multiple vm_map_delete: .... nothing at <address>? Is that normal?

Share this post


Link to post
Share on other sites

Well, the guard prints at vm_map_delete are most likely work in progress for improving the vm_map unexpected situation detection. It is very unlikely that it has anything to do to us.

I believe without debug=0x100 you should be able to see the panic, but I suppose it could be the same.

Share this post


Link to post
Share on other sites

I found out that what allowed me to view the panic before was actually the nv_disable=1 argument. So I have now a reliable method to see panics.

 

Here are some panics when using slto_us=10000:

 

IMG_6350.JPG

 

IMG_6354.JPG

 

IMG_6356.JPG

Edited by Pene

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×