On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin <glin@xxxxxxxx> wrote: > The series of patches introduce Security Version to EFI stub. > > Security Version is a monotonically increasing number and designed to > prevent the user from loading an insecure kernel accidentally. The > bootloader maintains a list of security versions corresponding to > different distributions. After fixing a critical vulnerability, the > distribution kernel maintainer bumps the "version", and the bootloader > updates the list automatically. When the user tries to load a kernel > with a lower security version, the bootloader shows a warning prompt > to notify the user the potential risk. If a distribution releases a kernel with a higher security version and that it automatically updated on boot, what happens if that kernel contains a different bug that causes it to fail to boot or break critical functionality? At that point, the user's machine would be in a state where the higher security version is enforced but the only kernel that provides that is broken. Wouldn't that make a bad situation even worse by now requiring manual acceptance of the older SV kernel boot physically at the machine? I feel like I'm missing a detail here or something. josh > For more details: https://github.com/lcp/shim/wiki/Security-Version > > The original idea is to add a new PE/COFF section to store the data. > However, there are some restrictions. > > 1. For x86, the size limit of the EFI header is 0x200, and a section entry > in the section table takes 40 bytes. Currently, the EFI header already > occupies the first 0x1da bytes, so there is no room for a new section > entry. > > 2. The MemoryAttributes table sets the attributes of memory pages according > to the section flags. For ARM64, the minimal granularity is 4KB, but > Security Version only needs a few bytes, and it's pointless to allocate > 4KB for it. > > Fortunately, there is a special section defined in PE/COFF: resource > section. The only known user of the resource section in UEFI is the HII > protocol which fetches data from "HII" directory. For Security Version, a > new directory called "LinuxSV" is created and it contains the file offset > to the struct of Security Version. The bootloader just follows the > resource table to fetch the "version" from the image file. > > v3: > - Move everything to the resource section to be compatible with both > x86 and ARM64 > v2: > - Decrease the size of secdata_offset to 2 bytes since the setup header > is limited to around 32KB. > - Restructure the secdata section. The signer is now a null-terminated > string. The type of distro_version changes to u32 in case the distro > uses a long version. > - Modify the Kconfig names and add help. > - Remove the signer name hack in build.c. > > Cc: "H. Peter Anvin" <hpa@xxxxxxxxx> > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > Cc: Ingo Molnar <mingo@xxxxxxxxxx> > Cc: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> > Cc: Catalin Marinas <catalin.marinas@xxxxxxx> > Cc: Will Deacon <will.deacon@xxxxxxx> > Cc: Joey Lee <jlee@xxxxxxxx> > Signed-off-by: Gary Lin <glin@xxxxxxxx> > > Gary Lin (2): > x86/efi: Introduce Security Version to x86 > arm64/efi: Introduce Security Version to ARM64 > > arch/arm64/kernel/efi-header.S | 57 ++++++++++++++++++++++++++++++++++++++++++ > arch/x86/boot/header.S | 55 ++++++++++++++++++++++++++++++++++++++++ > drivers/firmware/efi/Kconfig | 40 +++++++++++++++++++++++++++++ > 3 files changed, 152 insertions(+) > > -- > 2.15.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-efi" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
