Announcement

Collapse
No announcement yet.

Booting Linux On A Modern AMD Ryzen 6000 Series Laptop / ThinkPad X13 Gen3

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #81
    Originally posted by kreijack View Post
    However this requires to put in place a organization that:
    - check that the software that are going to be signed is not dangerous
    - in case that a key is compromised, it can be revoked
    - in case that a software signed shows bugs that can leads to an attack, the signature key can be revoked
    And this organization needs to be trusted by the computer manufacturer.

    And yes, Microsoft was used to perform the check above with its 3rd party certificate.
    This all sound simple. But the real answer is absolutely not that. The reality is the Linux distribution bootloaders have basically been bipassing all of that. Linux distributions have been getting one shim signed by Microsoft then using MOK for the distribution keys.
    https://wiki.ubuntu.com/UEFI/SecureBoot

    We would not have the problem if the default firmware in fact support MOK and gave clear message to end users about missing KEK as problem why disc will not boot.

    Think about it there is a simple core problem. There are over 300 active Linux distributions needing signing keys. Add in other third party Operating systems.

    Think about it your default key list could be a lot shorter kreijack if MOK was support out box because when you installed windows it would be added to the MOK so not needing to be in the default list. Same with the Canonical Ltd key.

    Why does your default UEFI have to have PK/KEK for operating systems you may not be using. Only reason is there is not a third party KEK storage option. Yes this lack of third party storage does create it own security issues.

    Like what to say that the attacking disc against you system is not a Windows PE disc with all parts correctly signed by Microsoft??? There is a reason to have per OS KEKs for bootloaders to reduce attack surface. Yes this cannot be done using the existing PK/KEK setup of UEFI as this setup encourages the all or nothing solution.
    Last edited by oiaohm; 16 July 2022, 01:14 PM.

    Comment


    • #82
      Originally posted by rommyappus View Post
      Forgive my ignorance but why can’t the Linux distro use their own official Certificate to sign their uefi boot loaders and such like Microsoft does? I must be missing something here…
      You missed something mega simple why OEM vendors asked Microsoft to be the gate keeper. Its space. Think for one min if all 300 active Linux distributions wanted their KEK added. Now you are writing this to the firmware flash that has limited write cycles.. Things are not going to go well.

      The MOK solution used by Linux distribution shim to add signing keys by have extra KEK stored in approved file in the UEFI partition.

      Comment


      • #83
        Originally posted by oiaohm View Post

        Really you like quoting that site. There are glaring bias in that write up.
        Well, birdie said he wrote the article, so maybe we shouldn't be surprised it's biased? The Windows moan pages are much shorter too, incidentally.

        It does make some good points, but it's very out of date in a lot of places in my opinion.

        Comment


        • #84
          Originally posted by oiaohm View Post

          This all sound simple. But the real answer is absolutely not that. The reality is the Linux distribution bootloaders have basically been bipassing all of that. Linux distributions have been getting one shim signed by Microsoft then using MOK for the distribution keys.
          https://wiki.ubuntu.com/UEFI/SecureBoot

          We would not have the problem if the default firmware in fact support MOK and gave clear message to end users about missing KEK as problem why disc will not boot.

          Think about it there is a simple core problem. There are over 300 active Linux distributions needing signing keys. Add in other third party Operating systems.

          Think about it your default key list could be a lot shorter kreijack if MOK was support out box because when you installed windows it would be added to the MOK so not needing to be in the default list. Same with the Canonical Ltd key.

          Why does your default UEFI have to have PK/KEK for operating systems you may not be using. Only reason is there is not a third party KEK storage option. Yes this lack of third party storage does create it own security issues.

          Like what to say that the attacking disc against you system is not a Windows PE disc with all parts correctly signed by Microsoft??? There is a reason to have per OS KEKs for bootloaders to reduce attack surface. Yes this cannot be done using the existing PK/KEK setup of UEFI as this setup encourages the all or nothing solution.
          Shim is not so different than secure boot. Both allow to boot an SO if its signature matches a certificate stored in a such way that cannot tampered without an explicit user action.

          One of the main driver to shim was to allow the user to manage the certificate in a ONE standard ways (and not depending by the UEFI implementation). But it doesn't add nothing than an UEFI bios. You can add/remove/update a certificate both in UEFI and shim.

          Instead of sign shim, the linux distribution could sign the bootloader directly. However signing shim (which in turn run the bootloader) give more flexibility:
          - it is more simply and less update; so the renew rate of the signature is lower than a generic boot loader
          - it can implement an user interface to manage the certificate, which is not something that historically interested to the bootloader

          Comment


          • #85
            Originally posted by kreijack View Post
            One of the main driver to shim was to allow the user to manage the certificate in a ONE standard ways (and not depending by the UEFI implementation). But it doesn't add nothing than an UEFI bios. You can add/remove/update a certificate both in UEFI and shim.
            https://www.linuxjournal.com/content...fi-secure-boot

            There is a problem UEFI bios in the standard does not define that you can add/remove/update any certificate you like in simple way. By UEFI standard all KEK accepted have to be signed by using the platform key private key of course the deployed UEFI firmware only has the platform key public key. By UEFI standard the only way to add you own KEK is clear and replace the platform key(PK).

            There are implementations like what you find on HP servers that have MOK functionality include in the base UEFI firmware these you can in fact add/remove/update KEK without altering the PK and without resetting the UEFI required KEK. Yes UEFI drivers are signed and must be signed by a KEK signed by the PK.

            Interesting point is MOK can be implemented in shim and in UEFI firmware.

            UEFI secureboot from my point of view has a critical flaw. Why are OS KEK and UEFI driver KEK in the same set. If there was a OS/bootloader PK and UEFI driver PK changing the OS KEK by changing the OS PK would not be a risk of complete system bricking. That way you screw up the OS KEK and the system still will boot into firmware where you could try again. Compared to current where you screw up the PK KEK set and now your firmware is not booting because UEFI drivers signatures are failing.

            Of course since adding and removing KEK without reseting the PK is not officially in UEFI standard there is no unified terms for UEFI vendors to use in the interface for doing it.

            The problem here starts with what Microsoft proposed to UEFI for secureboot and that need to be fixed up.

            The main driver for the shim was to avoid having to do the process of KEK approved 300+ times per vendor. The shim was only made because the UEFI standard is lacking.

            The shim implemented what called MOK stands for Machine Owner Keys. As in the person who own the machine wants to add keys in a safe way. The problem here is majority of your UEFI implementations don't give machine owner means to safely add keys just using what the firmware provides. Adding keys by reseting the PK and doing up a new set is not safe as you can screw up and lock yourself out. Think about it you screw up with MOK are you absolutely screwed the answer is no you are not.

            Personally I don't think we should need a shim to have MOK. I really think MOK functionality should be added to the UEFI standard as require functionality. Also standard should have a requirement if finding incorrectly signed boot-loader informing user of such not silent failure.

            Comment


            • #86
              I've submitted some amendments in the comments section of your website, birdie. Hopefully they are useful.

              Comment


              • #87
                Originally posted by oiaohm View Post

                https://www.linuxjournal.com/content...fi-secure-boot
                The main driver for the shim was to avoid having to do the process of KEK approved 300+ times per vendor. The shim was only made because the UEFI standard is lacking.
                Each shim contains the distributions keys. This means that the (e.g.) debian "shim" is different from the (e.g.) red-hat "shim". So each shim has to be approved if you want to install an OS without user intervention. So still be the problem of the "300+ approver request".

                What shim provide, is a cleaner path to update the keys.

                Obviously you can install the redhat shim (no intervention is required) and then install the debian certificate. However this latter step requires an user intervention.



                Comment


                • #88
                  Originally posted by kreijack View Post
                  Each shim contains the distributions keys. This means that the (e.g.) debian "shim" is different from the (e.g.) red-hat "shim". So each shim has to be approved if you want to install an OS without user intervention. So still be the problem of the "300+ approver request".

                  What shim provide, is a cleaner path to update the keys.

                  Obviously you can install the redhat shim (no intervention is required) and then install the debian certificate. However this latter step requires an user intervention.
                  https://wiki.ubuntu.com/UEFI/SecureBoot
                  The user installs Ubuntu on a new system

                  The user steps through the installer. Early on, when preparing to install and only if the system requires third-party modules to work, the user is prompted for a system password that is clearly marked as being required after the install is complete, and while the system is being installed, a new MOK is automatically generated without further user interaction.

                  Third-party drivers or kernel modules required by the system will be automatically built when the package is installed, and the build process includes a signing step. The signing step automatically uses the MOK generated earlier to sign the module, such that it can be immediately loaded once the system is rebooted and the MOK is included in the system's trust database.

                  Once the installation is complete and the system is restarted, at first boot the user is presented with the MokManager program (part of the installed shim loader), as a set of text-mode panels that all the user to enroll the generated MOK. The user selects "Enroll MOK", is shown a fingerprint of the certificate to enroll, and is prompted to confirm the enrollment. Once confirmed, the new MOK will be entered in firmware and the user will be asked to reboot the system.

                  When the system reboots, third-party drivers signed by the MOK just enrolled will be loaded as necessary.
                  The the MokManager in the shim makes the process quite simple for third party distributions. You will find Ubuntu and Debian .... based distributions using the main distribution shim and using the MokManager to add their own KEK/Key.

                  Reality is when you look at the top 300 distributions quite few of them are using user intervention because they have not bothered going to Microsoft to get their own shim. So you go from 300+ to less than 30.

                  Also quite few like arch turns out the provide shim does not in fact have distribution key. You are expect with arch todo mokmanager enrolment on new install.

                  kreijack the reality is not every distribution UEFI shim in fact contains a default distribution key. All of the distributions shims have a mokmanager. Fun point you can do mokmanager setup on a install media.

                  Yes the reality if the default UEFI contains mokmanager we could go from less than 30 to basically zero. Yes user would have the annoyance of having to enrol distribution so loader and system works. The fact many distributions already have there users do Mok enrolment either for drivers or for full distribution the user interacting cannot be classed as a huge barrier. Its a bigger issue when user is left in dark about what the failure is.

                  Comment


                  • #89
                    Originally posted by birdie View Post
                    So, a single switch in BIOS? OMG, such a drama. Not.



                    Market manipulation? Um, what? Linux has become a commercial OS and it's competing with Windows for the desktop? Where can I buy Linux (RHEL and other mostly server subscriptions aside)? Do Microsoft or OEMs prevent you from using Linux or other OSes? Doesn't look like it at all. Secure boot can be disabled all you want. The third-party key can be enabled all you want.

                    There's nothing to discuss here. There was never any issue in the first place.
                    If it wasn't for folks fighting the "nothing to see here" folks like yourself during the era of the Halloween documents ... you wouldn't EVEN be able to run Linux on most X86 hardware today. If it wasn't for folks with vision and foresight, you'd be running Windows only right now. If Microsoft hadn't been kept in check by the "zealots" ... etc .. etc.

                    Maybe you weren't a computer user during the era of Win only hardware such as the dreaded WinModem era. Microsoft doesn't now nor did they ever care about the user, it's about money and gobbling up market share by any means necessary.

                    Ah well. I'm sure someone will tell us all how Microsoft has changed in the last 10 years ... as Flav would say, "Don't believe the hype."

                    Comment

                    Working...
                    X