-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BMC firmware validation / Secure boot #57
Comments
Yet another alternative: IS25LP512M-RMLE The locking functionality is not the same in these chips, which does not come as a surprise. That means that to support this we need a configuration option, or dynamically detect (which is fragile), how to ensure that the chips are locked and how to program the lock tables. For my own notes, found both for delivery to Sweden: |
Re the second thing... I think u-boot should just verify the kernel and the full initramfs. Why allow random files around init to be modified, and why rely on having to make a Linux kernel patch to verify init? |
I agree what you're saying, but I'm not sure how to do it in practice. Where should we store the SSH server key and the gRPC TLS certificate+keys? Those will be generated by the BMC and we cannot let the BMC be able to sign it's own stuff while also be resistent to tampering, I think? |
Oh, re-reading your reply I think you misunderstood my proposal. I could have been clearer, I admit.
I'm talking about a "1st stage initramfs" that is static, that will indeed be validated by u-boot. Not patching the kernel. That 1 stage initramfs will then do a gpg check or whatever on /init and then exec it if it passes. |
Create keys and sign the kernel + DTB and enable mandatory image verification. This is part of u-root#57 and is useless right now as userspace can just replace any part anyway, but let's take this in small iterations. Signed-off-by: Christian Svensson <bluecmd@google.com>
Create keys and sign the kernel + DTB and enable mandatory image verification. This is part of u-root#57 and is useless right now as userspace can just replace any part anyway, but let's take this in small iterations. Signed-off-by: Christian Svensson <bluecmd@google.com>
Create keys and sign the kernel + DTB and enable mandatory image verification. This is part of #57 and is useless right now as userspace can just replace any part anyway, but let's take this in small iterations. Signed-off-by: Christian Svensson <bluecmd@google.com>
The second part of u-root#57. Signs the resulting bb binary using the same u-boot keys that was generated for the vboot. Uses a loader application living in a signed ramdisk to mount and verify that /init is signed. Signed-off-by: Christian Svensson <bluecmd@google.com>
The second part of u-root#57. Signs the resulting bb binary using the same u-boot keys that was generated for the vboot. Uses a loader application living in a signed ramdisk to mount and verify that /init is signed. Signed-off-by: Christian Svensson <bluecmd@google.com>
The second part of u-root#57. Signs the resulting bb binary using the same u-boot keys that was generated for the vboot. Uses a loader application living in a signed ramdisk to mount and verify that /init is signed. Signed-off-by: Christian Svensson <bluecmd@google.com>
The second part of u-root#57. Signs the resulting bb binary using the same u-boot keys that was generated for the vboot. Uses a loader application living in a signed ramdisk to mount and verify that /init is signed. Signed-off-by: Christian Svensson <bluecmd@google.com>
The second part of #57. Signs the resulting bb binary using the same u-boot keys that was generated for the vboot. Uses a loader application living in a signed ramdisk to mount and verify that /init is signed. Signed-off-by: Christian Svensson <bluecmd@google.com>
Chips arrived, MT25QL512ABB8ESF-0SIT seems to have worked out of the box, IS25LP512M-RMLE did not. For now I think it's OK if the locking of the boot flash is done in the loader application, that should be simple. After that, what needs to be done is to make sure that the PCH cannot boot before the flash has been locked. Alternatively we can detect that the PCH is turned on when we have booted userspace from cold-boot and force it to shut down by long-pressing the power button. Then we can proceed with the firmware validation. It seems more complicated than it may be worth though, just holding the reset line seems simpler. |
Current state is that the RDID command works in qemu but not on real chip, it just returns
|
Given that we're targeting specific platforms this is going to be optional and not useful for everyone.
However, it should be possible to create something that's reasonably secure by default.
The idea so far is to:
Ensure the BMC SPI flash has a protectable region that is volatile.
Volatile is to prevent bricking, but the locking also needs to be persistent until power reset without any other option to unlock. For the Leopards I have access to that means replacing the SPI flashes with something like MT25QL256ABA (or even MT25QL512ABB for a nice upgrade).
Make u-boot verify Linux kernel, make the Linux kernel verify /init
U-boot can already do this using signatures, and Linux can be made to do it using a initramfs.
This would still allow for persistence for files around the /init - but not modifications of /init (bbin/bb) itself.
There are some interesting open issues that needs to be solved.
The text was updated successfully, but these errors were encountered: