Open junzsalez opened 2 years ago
there is not currently
Would it be possible to add this feature in a future release? There are a few schools using your firmware on EOL Chromebooks to install Chrome OS FLex (to continue receiving updates) and would be great to have the ability to enable a password to prevent students from booting off a USB etc.
I don't expect to add one anytime soon, it's not a feature in upstream Tianocore, so I'd have to implement it from scratch which is a PITA
I was looking for something similar, and I had the thought that maybe the firmware could be built without support for entering setup menus or the EFI shell. This would prevent someone from changing the boot order, at the cost of making it difficult to troubleshoot without external reflashing. Do you happen to know if this is possible and what configuration flags would be needed? Or what documentation I should reference to dig up this information?
See also #114
I dug through the source and I think I found what would be needed to fully disable the boot menu and EFI shell.
~For EDKII, it appears that pressing escape to show the boot menu can be disabled by setting CONFIG_EDK2_BOOT_MANAGER_ESCAPE
to n
.~ To disable the EFI shell you would probably need to set CONFIG_EDK2_HAVE_EFI_SHELL
to n
. See https://github.com/MrChromebox/coreboot/blob/2022.10.24/payloads/external/edk2/Makefile.
For legacy SeaBIOS, it looks like the menu can be disabled by setting show-boot-menu
to 0
per https://seabios.org/Runtime_config. I'm not sure how this would be configured if building the firmware on your own, as I am focused on UEFI for my own use case and didn't have time to dig in further.
Would appreciate any feedback on this approach.
For EDKII, it appears that pressing escape to show the boot menu can be disabled by setting CONFIG_EDK2_BOOT_MANAGER_ESCAPE to n
no, that just means it will use the default value of F2 instead of ESC
Thanks for the correction, much appreciated.
I did some further research, and although it should be possible to create a "kiosk" style firmware without the menu, it is non-trivial (but not impossible). From this mailing list discussion it appears that you can strip out UiApp to remove the menu entirely, but there's no configuration option for this. For anyone else who wants to do this, it would require modifying the EDKII source used in the build process. The mailing list discussion should at least provide some hints to get started. You would also need to turn off CONFIG_EDK2_HAVE_EFI_SHELL
as described above.
You should ensure that your system is bootable from an uncustomized MrChromebox firmware before flashing a firmware customized in this way. I believe you should then be able to use efibootmgr
to either remove USB boot entirely, or place it after HDD boot to allow for a fallback boot option if all else fails.
~Edit: The biggest unanswered question I have is whether or not the firmware will prioritize EFI partitions from USB drives during boot. If so then I assume that a USB drive with an EFI partition could change the EFI boot order since (as I understand it) that information is stored in the EFI partition. If that is the case then further configuration or modification of EDKII may be needed.~ You will also need to ensure that the firmware prefers the internal EFI partition for boot configuration. This is the EDK default, but the MrChromebox firmware changes this to prefer USB. I'm not sure where this would be changed and I haven't had time to look yet.
I was hoping this would be easier, so I may or may not get to this, but if I do then I'll try to provide an update with more information. Hopefully this serves as a workaround for anyone who needs this.
how to you intend to boot a USB to install your OS without either a boot menu or shell?
I'd think a better approach would be to change the boot menu key to some unusual combo (SHIFT+J ?) and hide the text prompt, and shorten the timeout to 1s
Edit: The biggest unanswered question I have is whether or not the firmware will prioritize EFI partitions from USB drives during boot. If so then I assume that a USB drive with an EFI partition could change the EFI boot order since (as I understand it) that information is stored in the EFI partition. If that is the case then further configuration or modification of EDKII may be needed.
upstream EDK does, my fork prioritizes internal over external
Thanks once again for the EDK info, will update my instructions above.
For installing an OS, you would boot first with the standard firmware, install the OS, then flash the locked down firmware. Alternately, install the OS to HDD using a separate box and then install the HDD in the locked down box. The first is obviously preferable as you can verify that the OS configuration boots properly under the standard bootloader.
The method you suggested is also workable as long as you aren't concerned that someone may discover your secret hotkey scheme. With USB boot and setup menus disabled completely, a machine sealed in a tamper-evident enclosure should be significantly hardened against attacks that rely on altering the boot process (for example, installing a rootkit on the main OS via USB boot).
This would be a great addition for securing devices in general. In addition to being able to prevent external boot media, Chromebooks seem to have really great support for using Secure Boot, but:
There are certain conditions making for an ideal setup of Secure boot:
- UEFI considered mostly trusted (despite having some well known criticisms and vulnerabilities[1]) and necessarily protected by a strong password
...
The only way to prevent anyone with physical access from disabling Secure Boot is to protect the firmware settings with a password. Most UEFI firmwares provide such a feature, usually listed under the "Security" section in the firmware settings.
This would be a great addition for securing devices in general. In addition to being able to prevent external boot media, Chromebooks seem to have really great support for using Secure Boot, but:
There are certain conditions making for an ideal setup of Secure boot:
- UEFI considered mostly trusted (despite having some well known criticisms and vulnerabilities[1]) and necessarily protected by a strong password
... The only way to prevent anyone with physical access from disabling Secure Boot is to protect the firmware settings with a password. Most UEFI firmwares provide such a feature, usually listed under the "Security" section in the firmware settings.
if it were simple to do, I would have done it already
if it were simple to do, I would have done it already
No doubt from me, diff speaks for itself concerning complexity. Seconding the issue from a portable device security perspective.
Some resources I came across, linking here for visibility:
seems there's reference in-tree:
MdeModulePkg/Universal/DriverSampleDxe/VfrStrings.uni
116:#string STR_PASSWORD_PROMPT #language en-US "Set the system password"
sadly that's not going to work as-is for us, because it's using SMM to manage the password storage/verification, and we're not using SMM in edk2. But it's not a bad starting point
I am using the UEFI firmware for the Dell Chromebook 11 3120 (Baytrail) and was wondering if there is a way to set a password on the BIOS?