Introduce Security Version to EFI Stub

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.

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" <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Ard Biesheuvel <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Matt Fleming <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Will Deacon <[email protected]>

Cc Joey Lee <[email protected]>

Signed-off-by Gary Lin <[email protected]>

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 at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 10 lines · Gary Lin

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

Quoted 60 lines

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" <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Ard Biesheuvel <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Matt Fleming <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Will Deacon <[email protected]>

Cc Joey Lee <[email protected]>

Signed-off-by Gary Lin <[email protected]>

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 at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 21 lines · Josh Boyer

Quoted 10 lines · Gary Lin

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?

Quoted 2 lines

I feel like I'm missing a detail here or something.

If the new kernel fails to boot, then the user has to choose the kernel manually anyway, and there will be an option in the warning prompt to lower SV.

Quoted 22 lines · Gary Lin

Quoted 21 lines · Josh Boyer

Quoted 10 lines · Gary Lin

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?

Quoted 5 lines

Quoted 2 lines

I feel like I'm missing a detail here or something.

If the new kernel fails to boot, then the user has to choose the kernel manually anyway, and there will be an option in the warning prompt to lower SV.

And what if the firmware does not support a lowering of the SV?

Quoted 27 lines · Ingo Molnar

Quoted 24 lines · Gary Lin

Quoted 23 lines · Josh Boyer

Quoted 10 lines · Gary Lin

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.

Quoted 6 lines

Quoted 3 lines

If the new kernel fails to boot, then the user has to choose the kernel manually anyway, and there will be an option in the warning prompt to lower SV.

And what if the firmware does not support a lowering of the SV?

The SV list is manipulated by the bootloader, and the firmware only provides the interface to the storage, i.e. non-volatile flash.

Quoted 32 lines · Gary Lin

Quoted 31 lines · Ingo Molnar

Quoted 27 lines · Gary Lin

Quoted 21 lines · Josh Boyer

Quoted 10 lines · Gary Lin

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?

Quoted 2 lines

I feel like I'm missing a detail here or something.

If the new kernel fails to boot, then the user has to choose the kernel manually anyway, and there will be an option in the warning prompt to lower SV.

Quoted 4 lines

Quoted 2 lines

And what if the firmware does not support a lowering of the SV?

The SV list is manipulated by the bootloader, and the firmware only provides the interface to the storage, i.e. non-volatile flash.

What about systems where the bootloader is part of the system and users only have the ability to provide kernel images, but no ability to change the boot loader?

Quoted 40 lines · Ingo Molnar

Quoted 36 lines · Gary Lin

Quoted 25 lines · Ingo Molnar

Quoted 22 lines · Gary Lin

Quoted 21 lines · Josh Boyer

Quoted 10 lines · Gary Lin

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?

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

I feel like I'm missing a detail here or something.

If the new kernel fails to boot, then the user has to choose the kernel manually anyway, and there will be an option in the warning prompt to lower SV.

And what if the firmware does not support a lowering of the SV?

The SV list is manipulated by the bootloader, and the firmware only provides the interface to the storage, i.e. non-volatile flash.

Quoted 2 lines

What about systems where the bootloader is part of the system and users only have the ability to provide kernel images, but no ability to change the boot loader?

It depends on how the bootloader works. If the system uses my implementation of shim loader, it surely has the ability to lower SV, but it requires physical access on purpose.

Quoted 44 lines · Gary Lin

Quoted 42 lines · Ingo Molnar

Quoted 28 lines · Gary Lin

Quoted 27 lines · Ingo Molnar

Quoted 24 lines · Gary Lin

Quoted 23 lines · Josh Boyer

Quoted 10 lines · Gary Lin

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.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

If the new kernel fails to boot, then the user has to choose the kernel manually anyway, and there will be an option in the warning prompt to lower SV.

And what if the firmware does not support a lowering of the SV?

The SV list is manipulated by the bootloader, and the firmware only provides the interface to the storage, i.e. non-volatile flash.

What about systems where the bootloader is part of the system and users only have the ability to provide kernel images, but no ability to change the boot loader?

Quoted 3 lines

It depends on how the bootloader works. If the system uses my implementation of shim loader, it surely has the ability to lower SV, but it requires physical access on purpose.

And that's my problem: if in practice the bootloader is 'part of the system', is signed and is updated like the firmware, then putting a "Security Version" into the kernel image and architecting a boot protocol for a monotonic method for the bootloader to restrict the loading of kernel images is an obviously bad idea.

Quoted 51 lines · Ingo Molnar

Quoted 47 lines · Gary Lin

Quoted 35 lines · Ingo Molnar

Quoted 32 lines · Gary Lin

Quoted 31 lines · Ingo Molnar

Quoted 27 lines · Gary Lin

Quoted 21 lines · Josh Boyer

Quoted 10 lines · Gary Lin

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?

Quoted 2 lines

I feel like I'm missing a detail here or something.

If the new kernel fails to boot, then the user has to choose the kernel manually anyway, and there will be an option in the warning prompt to lower SV.

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

And what if the firmware does not support a lowering of the SV?

The SV list is manipulated by the bootloader, and the firmware only provides the interface to the storage, i.e. non-volatile flash.

What about systems where the bootloader is part of the system and users only have the ability to provide kernel images, but no ability to change the boot loader?

It depends on how the bootloader works. If the system uses my implementation of shim loader, it surely has the ability to lower SV, but it requires physical access on purpose.

Quoted 5 lines

And that's my problem: if in practice the bootloader is 'part of the system', is signed and is updated like the firmware, then putting a "Security Version" into the kernel image and architecting a boot protocol for a monotonic method for the bootloader to restrict the loading of kernel images is an obviously bad idea.

Even though the bootloader doesn't actually block the booting?

Quoted 57 lines · Gary Lin

Quoted 56 lines · Ingo Molnar

Quoted 41 lines · Gary Lin

Quoted 40 lines · Ingo Molnar

Quoted 36 lines · Gary Lin

Quoted 25 lines · Ingo Molnar

Quoted 22 lines · Gary Lin

Quoted 21 lines · Josh Boyer

Quoted 10 lines · Gary Lin

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?

Quoted 8 lines

Quoted 5 lines

Quoted 2 lines

I feel like I'm missing a detail here or something.

If the new kernel fails to boot, then the user has to choose the kernel manually anyway, and there will be an option in the warning prompt to lower SV.

And what if the firmware does not support a lowering of the SV?

The SV list is manipulated by the bootloader, and the firmware only provides the interface to the storage, i.e. non-volatile flash.

Quoted 6 lines

Quoted 2 lines

What about systems where the bootloader is part of the system and users only have the ability to provide kernel images, but no ability to change the boot loader?

It depends on how the bootloader works. If the system uses my implementation of shim loader, it surely has the ability to lower SV, but it requires physical access on purpose.

And that's my problem: if in practice the bootloader is 'part of the system', is signed and is updated like the firmware, then putting a "Security Version" into the kernel image and architecting a boot protocol for a monotonic method for the bootloader to restrict the loading of kernel images is an obviously bad idea.

Quoted 1 line

Even though the bootloader doesn't actually block the booting?

We don't know that for sure, in that scenario *how* the bootloader interprets the SV is not under the user's control...

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.

Quoted 8 lines · On Tue, 5 Dec 2017 18:01:46 +0800 Gary Lin <[email protected]> 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.

This seems a mindbogglingly complicated way to implement something you could do with a trivial script in the package that updates the list of iffy kernels and when generating the new grub.conf puts them in a menu of 'old insecure' kernels.

Why do you even need this in the EFI stub ?

What happens if you want to invalidate an old kernel but not push a new one ? Today if you've got a package that maintains the list of 'iffy' kernels you can push a tiny package, under your scheme you've got to push new kernels which is an un-necessary and high risk OS change.