> If you don't have secure boot then an attacker with root can modify your > bootloader or kernel, and on next boot lockdown can be silently disabled. Stop being narrow minded you don't need secure boot to protect bootloader or kernel the classic is only boot from read only media. Another is network boot using https can coreboot firmware. This checks the certificate of the https server against selected CA before downloading anything and as long as the firmware is set read only in hardware the attack has absolutely nothing to work on. In fact the network boot form https server is more secure than UEFI secureboot due to highly limited parties who can alter/provide the approved boot loader/kernel image. Having root user rights does not override physical security. The fact there are other ways of doing bootloader and kernel security other than UEFI secureboot that are in lots of cases more secure than UEFI secureboot due to using more limited keys is the absolute reason why lockdown is required without UEFI secureboot. It would make sense to extend kexec to support UEFI secureboot verification and also kexec to have frameworks to support other security options like https server storage of all kernel images. Please note kexec supporting UEFI secureboot verification should also support booting non UEFI secureboot but verified by some other method and having own PK/KEK set for kexec and this would be when the Linux kernel is placed in firmware and used instead of EFI firmware.. Please note there are many UEFI firmwares that with secureboot off allow setting up secure https bootting where you are not in fact validating the boot loader or kernel but validating the source you get them from. There are three different ways to achieve a protected boot process. 1) validate the boot files.(this is like UEFI secure boot and many other methods) 2) validate source the boot files. Yes this can be apply key check to image if image is not signed don't boot from it and the image contain boot loader and kernel then not bother validating the boot loader and kernel image/parts individually same with https. 3) make boot files read only. All three achieve the same level of security. If you are using any of the three lockdown option may provide some benefit. Yes https network boot effectively does 2 and 3 so making having a very limit threat against the boot process. Remember there is more 1 way to skin a cat just like there is more than 1 way to make a secure system. Currently being too narrow in methods for doing protected booting. Peter Dolding. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
