search

acidanthera / bugtracker

Acidanthera Bugtracker
385 stars 45 forks source link

[OpenCore]When SecureBootModel is set to Default, the menu does not appear due to an internal error. #1868

Closed mifjpn closed 2 years ago

mifjpn commented 2 years ago

Thanks for all the useful developments.

I have configured the following environment according to Dortania.

CPU:Corei9-10900F MB:ASUS TUF GAMING H570-PRO RAM:32GB GPU:RX-570（MSI)

I was able to boot when SecureBootModel was disabled. However, when I set SecureBootModel to Default, it did not boot. I don't think there is any internal inconsistency, but it is strange. Is it a bug? opencore-2021-11-15-163043.txt.zip config2111160832.plist.zip EFI.ocsb2111160832.zip

Than you very much.

mikebeaton commented 2 years ago

Try NVRAM reset?

mifjpn commented 2 years ago

thank you. I forgot the first way. A little embarrassed.

mifjpn commented 2 years ago

Thank you very much for making me aware of this. I'm super embarrassed. Here are the results as I wanted them to be. ーーーーーー alpha@iMac ~ % sysctl hw.target hw.target: J185FAP alpha@iMac ~ % nvram 94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel 94B73556-2197-4702-82A8-3E1337DAFBFB:HardwareModel j185fap%00 ーーーーーー I didn't think that clearing the NVRAM would fix the internal invalids. Thank you so much.

mikebeaton commented 2 years ago

The error OC: Failed to bootstrap [SB|IMG4] Values - Invalid Parameter actually meant that the NVRAM was in a state where it cannot be set - but don't worry, we agreed that this was not too obvious from the error messages you saw so we just updated them slightly. :-) https://github.com/acidanthera/OpenCorePkg/commit/a79900c6370846c8bc1bb9c2db141bb4a82961a7

mifjpn commented 2 years ago

Thank you so much！！

mifjpn commented 2 years ago

Hello. I use both OpenCore and Clover.

If we start OpenCore after starting Clover, the same phenomenon will occur. Which NV-RAM parameter is bad?

I think it's better to set Delete on the OpenCore side, so please let me know.

Thank you for your cooperation.

mikebeaton commented 2 years ago

Clover is writing some of these variables non-volatile. OC is choosing to write them volatile - less wear on physical NVRAM, and of course they are only ever needed in the context of booting macOS. But a volatile var cannot overwrite a non-volatile one, so OC's code cannot overwrite what Clover has left behind. I was wondering where these values were coming from...!

You are correct that adding NVRAM Delete to the affected variables (HardwareModel as you identified, and possibly 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:BridgeOSHardwareModel too) in OpenCore will resolve the problem. Perhaps you could confirm that you have this working and booting on both bootloaders, but I believe this should be fine.

mifjpn commented 2 years ago

OK I try it soon.

mikebeaton commented 2 years ago

Summary of further info on this after checking with Vit: The way Clover writes these vars is the 'wrong' way, i.e. it opens a security hole; making the vars volatile as done in OC prohibits macOS or any other OS from changing them; this may not matter much to Clover as they are not attempting to be secure by design. Therefore booting via Clover opens the security hole. Booting via OC, even with the additional Delete in place, remains secure.

mifjpn commented 2 years ago

Thank you for your quick answer.

I was able to solve the problem by putting the following items in the DELETE of NVRAM 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:BridgeOSHardwareModel

　Each of these can have a different design philosophy. But first of all, it must be a fact that OpenCore refuses to work with the NVRAM environment at that time. (If possible, it should be turned off automatically, and whether it is the responsibility of the user is a difficult decision.)

　And I don't think it is the act of a freedom-loving hacker to refuse to allow both bootloaders to choose or coexist.

　I'll be sure to mention this to the developers in the discussion over there. But I don't understand (sorry) what the security hole actually is.

　I would really appreciate an approach from your side as well.

Thank you so much!

mikebeaton commented 2 years ago

Well as far as I can see, the security hole is only present if a loader allows a pre-existing, potentially malicious value to pass through and be used. @vit9696 may want to comment if I've misunderstood. I do not know how Clover acts in that respect. It perhaps does not make much sense to use persistent NVRAM for a value which will always be ignored at reboot (if that is what Clover is doing), but in that case it would not be a security hole.

Current OpenCore behaviour is to say "this value exists in NVRAM, it should not, abort". You can clear NVRAM and it will then work. As long as no one malicious and no other bootloaders are doing suspect things in NVRAM it will continue to work. As you yourself pointed out, you can work round having an unsupported setup (co-existence with Clover), where the value will sometimes be incorrectly present, by using additional config.

Unsupported does not mean "actively worked against" of course. It just means unsupported! And even an unsupported setup should - ofc - continue to remain secure when booted through OC; as you're no doubt already aware, a perfectly standard response of a secure boot system (such as you are using with secure boot turned on in OC) is "refuse to boot, system is in invalid state".

mifjpn commented 2 years ago

Thank you for your kind and quick reply.

　I think "not actively opposing" is a good thing. I'm sure many freedom-loving hackers would support it. And I understand what you mean about 「not supporting each other」, since they are different.

　But if it threatens users' freedom, it should be clearly stated in the manual, "Your freedom will be taken away”. (This is a joke, since you don't actively oppose it.)

　If, however, in order to be secure, you impose a certain NVRAM requirement and say that it is dangerous and you can't move it, then this is a complete problem, and even the release version should be labeled as "dangerous".

　I would be very happy to hear if it is so dangerous that it should not be run.

Thank you very much for your energetic development.

mikebeaton commented 2 years ago

I don't understand. Accepting the value in question and using it would allow (e.g.) a downgrade attack. Since the value is never going to be accepted by OC on bootup (because of this potential for security downgrade), it makes no sense to store it persistently. If, for all that, an attacker or another bootloader leaves the value set, OC's existing behaviour (which only occurs in this unsupported scenario) is to refuse to boot (which is safe), or you can apply a work-around (which is to explicitly tell OC: "delete this value, which Clover leaves there, which should not really be there"). This is also safe, when booted through OC. When booted through Clover, either they are using the value, in which case there is some potential for security downgrade, or they are not using it, in which case there was no point storing it persistently in the first place (even though there is no security issue), but those are both issues for Clover, not OC. So hopefully there is no remaining problem? :-)

mifjpn commented 2 years ago

I am very sorry. 　Okay, I understand that it is so dangerous that I should not move it. 　I understand that it is so dangerous that it should not be executed, and I feel that you are pointing out that Clover is committing this dangerous situation, even though it may not be in the best interest of the users. (I'm sure that's what you mean when you say you don't understand.) I think it's sad. 　I was simply suggesting that if you think something is dangerous, you should display "dangerous" in OpenCore and point it out to the Clover's developer. 　I don't think there is any reason for you not to understand. I'm sorry if I'm wrong about something. 　If so, the answer would be yes or no. I apologize if I misspoke in any way. Thank you.

mikebeaton commented 2 years ago

You're talking about things being "dangerous" and "shouldn't be run", that's what I don't understand. This is an OpenCore issue tracker so I assumed you were talking about OpenCore!

You may perfectly well use Clover for your own purposes, if you want macOS to boot successfully. If you want macOS to boot with as high as possible security against malicious attacks, of course we would say (and perhaps even Clover would agree, idk!), then you should use OpenCore.

vit9696 commented 2 years ago

TL;DR Just trying to silently delete this variable in OpenCore may lead to (at least) these two paths, both of which we want to avoid:

At a step we receive the value we only have the information that the system was badly tampered with, and with this knowledge we can only say that the operating system cannot be booted with the security features you enabled in the configuration. It is entirely your choice to enable Apple Secure Boot, and it is our mission to ensure that this Secure Boot is actually secure. Hope it helps =)

mifjpn commented 2 years ago

Thank you Vit9696 for your detailed explanation. 　I apologize for any misunderstanding I may have caused. 　I don't think I said anything so radical as "OpenCore can boot when it is not secure". 　Please forgive me if I misunderstood you in this regard. 　I just think that if OpenCore decides that NVRAM is dangerous, OpenCore should indicate that it is "dangerous" even in debug mode and stop it. 　And I'm suggesting that you point out to the Clover devs that they are in danger. 　It's all very well to "not actively disagree”. 　But it sounds like mikebeaton is telling me to choose the dangerous one if I like, without considering what the Clover developers will do with this point. It's very sad. I apologize if I misspoke in some extreme way. Thank you very much.

　I am a hacker who likes freedom, but I think freedom also goes back to basics. That is. I believe that true freedom is to voluntarily obey the laws of moral obligation (moral law), which every human being must obey at all times.

　This time, the moral law is the conscience of OpenCore, and I hope Clover is the same.

vit9696 commented 2 years ago

There is a fundamental difference between Clover and OpenCore approach. Clover will unlikely see any reason to change this. But we may reword the message eventually.

mifjpn commented 2 years ago

Well, it seems that it is a difference in thinking. I can very much agree with respecting it to the maximum.

　One question, however, is that this variable is required for a securely booted macOS, and is also defined when you start OpenCore. So, the OpenCore philosophy is that it needs to be turned off when you stop the OS to be secure.

Having said that, is there any other way to boot macOS other than Clover and OpenCore? 　If there is another way to boot, I think there could be a downgrade attack. (If I'm wrong about that, I apologize) 　I think the only other way to boot is to boot Clover without the HW.target setting. However, in that case, this NVRAM entry will not be created (it will be erased).

　If that's the case, then the NVRAM item will still be needed when macOS finishes booting, since the same secure settings will be configured in both Clover and OpenCore anyway.

　Why shouldn't there be an NVRAM item in the first place, which is set for both OpenCore and Clover when they are secure, if there is no other way to boot? 　For example, if you want to do a downgrade attack, you need to boot, but is there any other way to achieve that than booting?

　I believe that "unity of word and deed" is one of the good morals. In other words, the words of thought should match the actions.

　If that is the case, does it mean that the variables that OpenCore creates should not be there when OpenCore is started, even though they cannot be booted, because they are the ideas of the "word" world, and not related to the "action" idea of booting, which cannot actually be realized?

　Please forgive me if I misspoke or sound like I'm ranting.

　It is natural that there are differences in design philosophy, but as I said at the beginning, I believe that coexistence is also a natural activity of freedom-loving hackers.

　I would be honored if you could answer some of the questions that I find strange. Thank you very much.

LeeBinder commented 2 years ago

@mifjpn you write:

I was able to solve the problem by putting the following items in the DELETE of NVRAM 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:BridgeOSHardwareModel

but even though you use plural, you only mention one item, BridgeOSHardwareModel

Just BridgeOSHardwareModel is not enough to handle this issue here without a NVRAM reset. Can you please share that complete part of your OC config.plist via copy/ paste in here? Thank you.

BTW @mikebeaton @vit9696 : is there a EFI BIOS boot menu friendly variant of resetting NVRAM? Everytime after performing a NVRAM reset, all custom entries in the BIOS boot picker menu are erased, too, and it's really annoying having to restore them again every once in a while.

(as a side note: Clover NVRAM reset via F11 preserves the BIOS boot menu entries, but it doesn't fix sticky NVRAM remnants like this one.)

mifjpn commented 2 years ago

@mifjpnhttps://github.com/mifjpn you write:

I was able to solve the problem by putting the following items in the DELETE of NVRAM 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:BridgeOSHardwareModel

but even though you use plural, you only mention one item, BridgeOSHardwareModel

Just BridgeOSHardwareModel is not enough to handle this issue here without a NVRAM reset. Can you please share that complete part of your OC config.plist via copy/ paste in here? Thank you.

BTW @mikebeatonhttps://github.com/mikebeaton @vit9696https://github.com/vit9696 : is there a EFI BIOS boot menu friendly variant of resetting NVRAM? Everytime after performing a NVRAM reset, all custom entries in the BIOS boot picker menu are erased, too, and it's really annoying having to restore them again every once in a while.

(as a side note: Clover NVRAM reset via F11 preserves the BIOS boot menu entries, but it doesn't fix sticky NVRAM remainders like this one.)

—

Hello. 　First of all, I would like to thank you for pointing out my mistakes in English. 　It is not my native language and I am having a hard time. Especially in Japanese, we often omit the subject, and there is no difference between singular and plural forms. 　Therefore, I have to translate what I have corrected into English into Japanese again, check it, and then re-check it based on my knowledge. 　This time, I mistook the singular for the plural. I apologize for that. First of all, I will attach my config.plist to this mail. Also, here is the URL for OpenCore EFI on my web page. https://mifmif.mydns.jp/pcpc/public/alpha/OcStable076-i9-10900F-H570.zip

I personally agree with what you are saying in ”BTW.” However, when I discussed with Vit9696, I as asian imagine some of the unspoken parts. (Sorry if I'm wrong). 　Maybe the word "hacker" itself is already an old term. Please forgive me. 　The idea of a freedom-loving hacker, what is freedom? 　Is there an absolute good or not? 　To this, OpenCore does not lie in any way. And it seems to have an attitude of openness to all developers. 　This is not a bad thing. If anything, it exposes all the inconveniences that the BIOS industry and motherboard industry would rather hide. 　This goes along with OpenCore's signed declaration that, as you know, many BIOSes from a series of previous generations do not have the correct standardized behavior.

However. 　In other words, they are not flexible. 　We have to move the government even if our democracy leads to the suppression of minority opinions, even if the political debate leads to what the ruling party says, because we do not have the time. 　Even if we are wrong, we have to work the administration to move things first. 　This is the way of capitalism at the same time. If we don't come up with something new, we can't sell it, otherwise we will lose our company and won't be able to employ people. 　In this way, administrative = industry mistakes become the standard. But it can be ugly. 　However, there is no convenient mechanism in this process that would make us switch to an artificial heart lung to treat the blood vessels.(That must be wrong for think of all the motherboards from all the BIOS manufacturers that have to be recalled and repaired because of a standard error, and then the company goes under and doesn't hire anyone anymore.) 　Socialism has failed. You can't make something good without competition.

　So for myself, it is ideal that it is good because it is the best. So I won't criticize it. But,　 We all know the word "infinite". But we can't see everything "from beginning to end". 　So I think there should be a mix of idealism and realism.

I'm sure there are some parts of the translation that are strange because of the ambiguous wording. Please forgive me for that. I'm sorry.

差出人: LeeBinder @.> 送信日時: 2021年12月28日 6:26 宛先: acidanthera/bugtracker @.> CC: mifjpn @.>; Mention @.> 件名: Re: [acidanthera/bugtracker] [OpenCore]When SecureBootModel is set to Default, the menu does not appear due to an internal error. (Issue #1868)

@mifjpnhttps://github.com/mifjpn you write:

I was able to solve the problem by putting the following items in the DELETE of NVRAM 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:BridgeOSHardwareModel

but even though you use plural, you only mention one item, BridgeOSHardwareModel

Just BridgeOSHardwareModel is not enough to handle this issue here without a NVRAM reset. Can you please share that complete part of your OC config.plist via copy/ paste in here? Thank you.

BTW @mikebeatonhttps://github.com/mikebeaton @vit9696https://github.com/vit9696 : is there a EFI BIOS boot menu friendly variant of resetting NVRAM? Everytime after performing a NVRAM reset, all custom entries in the BIOS boot picker menu are erased, too, and it's really annoying having to restore them again every once in a while.

(as a side note: Clover NVRAM reset via F11 preserves the BIOS boot menu entries, but it doesn't fix sticky NVRAM remainders like this one.)

— Reply to this email directly, view it on GitHubhttps://github.com/acidanthera/bugtracker/issues/1868#issuecomment-1001767074, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB2WHWV2DH7HGWDKDLJJA7DUTDKXZANCNFSM5IC6Q2JA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>

LeeBinder commented 2 years ago

@mifjpn

Your English is close to perfect. And obviouilsy your'e a philosopher.

Thank for sharing OcStable076-i9-10900F-H570.zip. As you wrote, you only have BridgeOSHardwareModel in the DELETE of NVRAM 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14

We all here are using "hackintoshes", but the OC team brought security back to us, which is superb.

@mikebeaton @vit9696 I also boot Windows 10, 11 and different flavors of Linux, so sometimes NVRAM gets borked and needs a reset.

mikebeaton commented 2 years ago

@LeeBinder - I'll speak to @vit9696 about it.

LeeBinder commented 2 years ago

@mikebeaton great, thank you 👍 There is more threads on the web with people being irritated about this, so it'll be helpful to others, too.

LeeBinder commented 2 years ago

Is there a EFI BIOS boot menu friendly variant of resetting NVRAM? Everytime after performing a NVRAM reset, all custom entries in the BIOS boot picker menu are erased, too, and it's really annoying having to restore them again every once in a while.

(as a side note: Clover NVRAM reset via F11 preserves the BIOS boot menu entries, but it doesn't fix sticky NVRAM remnants like this one.)

mikebeaton commented on Dec 30, 2021:

@LeeBinder - I'll speak to vit9696 about it.

Hi @mikebeaton @vit9696 . I hope you haven't totally forgotten about this?

mikebeaton commented 2 years ago

Basic problem is not wanting a reset nvram option which does not fix all problems. Invalid or out of date boot menu entries can themselves cause problems. If everything is cleared, all such potential problems are cleared.

LeeBlnder commented 2 years ago

Yes, I 100% agree with you that the existing ClearNVRAM.efi needs to stay exactly the way it is for the reasons you specify. What I am suggesting is what I'd dub a 2nd "ClearNVRAM_lite.efi" with everything ClearNVRAM.efi does - (minus) clearing UEFI BIOS boot menu entries. So when issues arise which might (or might NOT) be NVRAM related, users run the lite version first, check if the issue is resolved, and if yes, can continue on happily without having to run the "nuclear/ atomic" full ClearNVRAM.efi, forcing upon the user to again having to restore the boot menu even though the error wasn't UEFI boot menu related at all. Or in other words: why use an axe to cut a vegetable (= over-the-top) when a little knife is enough for that :) Rather than that, provide an option.

LeeBinder commented 2 years ago

mikebeaton commented on Feb 25:

Basic problem is not wanting a reset nvram option which does not fix all problems. Invalid or out of date boot menu entries can themselves cause problems. If everything is cleared, all such potential problems are cleared.

0.8.1 Latest

💯 👍

mikebeaton commented 2 years ago

I was just toeing the party line. But I sneaked it in. With adequate warnings that it would be a stupid feature to want to use. (I use it. 🤣) You probably don't need to write quite as many essays about vegetables and axes ... but since it was worth doing (as an option) anyway ....

LeeBinder commented 2 years ago

LOL you're funny. Might depend on the size and consistency of the vegetable, and the sharpness of available knives .. 😄

And using stupid features qualifies you as a worthwhile member of the human race, I suppose 😉