Jump to content

Pene

Coders
  • Content Count

    155
  • Joined

  • Last visited

  • Days Won

    1

Pene last won the day on January 3 2013

Pene had the most liked content!

About Pene

  • Rank
    InsanelyMac Geek

Profile Information

  • Gender
    Male

Recent Profile Visitors

4,480 profile views
  1. Pene

    AptioMemoryFix

    Thanks, as you expected, it is 0. What puzzles me, is that if it indeed is a DXE/SMM issue, shouldn't it have affected Windows/Linux nvram writes as well? That's why I thought it should be something specific to the mac-specific reallocation. Just for reference, here is the memory map from my system:
  2. Pene

    AptioMemoryFix

    Hey DF! How are you? Good to see you around Yes, I know it should. But I was more referring to a situation in which from some reason guarding doesn't work on the newer Aptio.
  3. Pene

    AptioMemoryFix

    By the way, no chance it is not guarded? How can we check this?
  4. Pene

    AptioMemoryFix

    Hi vit9696, Yes, an uneasy situation indeed... Meanwhile I made some test, with a rather strange result. I set a simple override for SetVariable, something like: OvrSetVariable( IN CHAR16 *VariableName, IN EFI_GUID *VendorGuid, IN UINT32 Attributes, IN UINTN DataSize, IN VOID *Data ) { EFI_GUID gEfiAppleBootGuid = {0x7C436110, 0xAB2A, 0x4BBB, {0xA8, 0x80, 0xFE, 0x41, 0x99, 0x5C, 0x9F, 0x82}}; return gOrgRS.SetVariable(L"TestVar", &gEfiAppleBootGuid, EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, 4, "1234"); } ... which from some reason didn't panic on restart (obviously the "TestVar" was updated first by Clover's call to SetVariable, so I don't think it actually tried to write anything to nvram on restart). But then I changed only the preset apple boot guid to: return gOrgRS.SetVariable(L"TestVar", VendorGuid, EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, 4, "1234"); ... which resulted again in panic on restart. Can't really explain why. Perhaps you have an idea. EDIT: Maybe it panics only when it actually has data to change? Otherwise it probably just returns EFI_SUCCESS and exists. Regarding your suggestion, it sounds like a good plan, but it's a bit too big for me at the moment, considering my limited experience with runtime EFI drivers combined with the limited free time that I currently have. But if someone else is up for this task, I'll be more than willing to test it on the Z390.
  5. Pene

    AptioMemoryFix

    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:
  6. Pene

    AptioMemoryFix

    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?
  7. Pene

    AptioMemoryFix

    OSX won't start at all with slto_us=0. Panics on startup.
  8. Pene

    AptioMemoryFix

    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:
  9. Pene

    AptioMemoryFix

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

    AptioMemoryFix

    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.
  11. Pene

    AptioMemoryFix

    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
  12. Pene

    AptioMemoryFix

    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.
  13. Pene

    AptioMemoryFix

    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.
  14. Pene

    AptioMemoryFix

    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.
  15. Thank you. Indeed, it seems to be an AptioMemoryFix issue.
×