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
Security Version is a mechanism based on UEFI Secure Boot to keep the
user from loading an insecure kernel accidentally. It's a monotonically
increasing number representing how "secure" the kernel is. The distro
kernel maintainer has to specify the distro name (signer) and the distro
version to distinguish the distro kernel among other kernel images. When
a critical vulnerability is fixed, the maintainer bumps Security Version,
and the bootloader (e.g. shim) records the Security Version in a UEFI
BootService variable. If the user tries to load a kernel with a lower
Security Version, the bootloader shows a warning prompt, and the user
decides whether to boot the kernel or not.
For the better portability, Security Version utilizes the resource
section(*) of PE/COFF to locate the struct of Security Version. The
resource section is a read-only section to index data in a binary-sorted
tree structure. The Windows images stores the resource data in a three
levels struture. For simplicity, we only use one level for Security
Version. A directory called "LinuxSV" is created and it contains the
offset to the struct of Security Version. The bootloader just follows
the resource table to fetch the details.
The struct of Security Version can be presented as the following:
struct sv_hdr {
__u16 header_length;
__u16 security_version;
__u32 distro_version;
} __attribute__((packed));
char *signer;
It consists of a fixed size structure and a null-terminated string.
"header_length" is the size of "struct sv_hdr". It's also used as a
kind of the "header version" in case a new member is introduced later.
(*) PE Format: The .rsrc Section
https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#the_.rsrc_section
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: Joey Lee <[email protected]>
Signed-off-by: Gary Lin <[email protected]>
---
arch/x86/boot/header.S | 55 ++++++++++++++++++++++++++++++++++++++++++++
drivers/firmware/efi/Kconfig | 40 ++++++++++++++++++++++++++++++++
2 files changed, 95 insertions(+)
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 850b8762e889..dc1b80b29478 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -188,7 +188,12 @@ extra_header_fields:
.quad 0 # ExportTable
.quad 0 # ImportTable
+#ifdef CONFIG_SECURITY_VERSION_SUPPORT
+ .long rsrc_table # ResourceTable
+ .long rsrc_table_size
+#else
.quad 0 # ResourceTable
+#endif
.quad 0 # ExceptionTable
.quad 0 # CertificationTable
.quad 0 # BaseRelocationTable
@@ -634,3 +639,53 @@ die:
setup_corrupt:
.byte 7
.string "No setup signature found...\n"
+
+#ifdef CONFIG_SECURITY_VERSION_SUPPORT
+# Resource Table
+ .section ".rodata", "a", @progbits
+ .align 2
+rsrc_table:
+ # Resource Directory
+ .long 0 # Characteristics
+ .long 0 # TimeDateStamp
+ .short 0 # MajorVersion
+ .short 0 # MinorVersion
+ .short 1 # NumberOfNamedEntries
+ .short 0 # NumberOfIdEntries
+
+ # Resource Directory Entry
+ .long name_offset | 0x80000000 # NameOffset:31
+ # NameIsString:1
+ .long rsrc_data_entry - rsrc_table # OffsetToData
+
+ .set name_offset, . - rsrc_table
+ # Resource Directory String
+ .short 7 # Length
+ .short 0x4C00 # 'L'
+ .short 0x6900 # 'i'
+ .short 0x6E00 # 'n'
+ .short 0x7500 # 'u'
+ .short 0x7800 # 'x'
+ .short 0x5300 # 'S'
+ .short 0x5600 # 'V'
+
+ .set svdata_entry_offset, . - rsrc_table
+ # Resource Data Entry
+rsrc_data_entry:
+ .long svdata_begin # OffsetToData
+ .long svdata_end - svdata_begin # Size
+ .long 0 # CodePage
+ .long 0 # Reserved
+
+ .set rsrc_table_size, . - rsrc_table
+
+ # Security Version
+svdata_begin:
+ .short sv_signer - svdata_begin
+ .short CONFIG_SECURITY_VERSION
+ .long CONFIG_DISTRO_VERSION
+sv_signer:
+ .string CONFIG_SIGNER_NAME
+svdata_end:
+
+#endif /* CONFIG_SECURITY_VERSION_SUPPORT */
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 2b4c39fdfa91..1dd82f1dd094 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -161,6 +161,46 @@ config RESET_ATTACK_MITIGATION
still contains secrets in RAM, booting another OS and extracting the
secrets.
+menuconfig SECURITY_VERSION_SUPPORT
+ bool "Security Version Support" if EFI_STUB
+ help
+ The security version is the number defined by the distribution
+ to indicate the critical security fixes. The bootloader could
+ maintain a list of the security versions of the current kernels.
+ After fixing a severe vulnerability in the kernel, the distribution
+ bumps the security version to notify the bootloader to update
+ the list. If the user tries to load a kernel with a smaller security
+ version, the bootloadr could show a warning to the user to avoid
+ a vulnerable kernel from being loaded accidentally.
+
+ This is mainly designed for the distribution kernel maintainer.
+ Say N if you don't know what it is.
+
+
+config SIGNER_NAME
+ string "Signer Name" if SECURITY_VERSION_SUPPORT
+ depends on EFI && X86
+ default ""
+ help
+ This option specifies who signs or releases this kernel.
+
+config DISTRO_VERSION
+ int "Distribution Version" if SECURITY_VERSION_SUPPORT
+ depends on EFI && X86
+ default 0
+ range 0 4294967295
+ help
+ This option specifies the distribution version which this
+ kernel belongs to.
+
+config SECURITY_VERSION
+ int "Security Version" if SECURITY_VERSION_SUPPORT
+ depends on EFI && X86
+ default 0
+ range 0 65535
+ help
+ This option specifies the security version of this kernel.
+
endmenu
config UEFI_CPER
--
2.15.0
This commit introduces Security Version for ARM64. As in x86, it
utilizes the resource section defined in the PE/COFF format(*) to locate
the struct of Security Version.
Similar to the debug table, the resource table is stored in .init.rodata
section while the struct of Security Version is in the 4K padding area of
the EFI header.
(*) PE Format: The .rsrc Section
https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#the_.rsrc_section
Cc: Catalin Marinas <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Matt Fleming <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Cc: Joey Lee <[email protected]>
Signed-off-by: Gary Lin <[email protected]>
---
arch/arm64/kernel/efi-header.S | 57 ++++++++++++++++++++++++++++++++++++++++++
drivers/firmware/efi/Kconfig | 6 ++---
2 files changed, 60 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/efi-header.S b/arch/arm64/kernel/efi-header.S
index 613fc3000677..f4404db6ca5c 100644
--- a/arch/arm64/kernel/efi-header.S
+++ b/arch/arm64/kernel/efi-header.S
@@ -61,7 +61,12 @@ extra_header_fields:
.quad 0 // ExportTable
.quad 0 // ImportTable
+#ifdef CONFIG_SECURITY_VERSION_SUPPORT
+ .long rsrc_table - _head // ResourceTable
+ .long rsrc_table_size
+#else
.quad 0 // ResourceTable
+#endif
.quad 0 // ExceptionTable
.quad 0 // CertificationTable
.quad 0 // BaseRelocationTable
@@ -103,6 +108,58 @@ section_table:
.set section_count, (. - section_table) / 40
+#ifdef CONFIG_SECURITY_VERSION_SUPPORT
+ /*
+ * Resource Table
+ */
+ __INITRODATA
+
+ .align 2
+rsrc_table:
+ // Resource Directory
+ .long 0 // Characteristics
+ .long 0 // TimeDateStamp
+ .short 0 // MajorVersion
+ .short 0 // MinorVersion
+ .short 1 // NumberOfNamedEntries
+ .short 0 // NumberOfIdEntries
+
+ // Resource Directory Entry
+ .long name_offset | 0x80000000 // NameOffset:31
+ // NameIsString:1
+ .long rsrc_data_entry - rsrc_table // OffsetToData
+
+ .set name_offset, . - rsrc_table
+ // Resource Directory String
+ .short 7 // Length
+ .short 0x4C00 // 'L'
+ .short 0x6900 // 'i'
+ .short 0x6E00 // 'n'
+ .short 0x7500 // 'u'
+ .short 0x7800 // 'x'
+ .short 0x5300 // 'S'
+ .short 0x5600 // 'V'
+
+ // Resource Data Entry
+rsrc_data_entry:
+ .long svdata_begin - _head // OffsetToData
+ .long svdata_end - svdata_begin // Size
+ .long 0 // CodePage
+ .long 0 // Reserved
+
+ .set rsrc_table_size, . - rsrc_table
+ .previous
+
+ // Security Version
+svdata_begin:
+ .short sv_signer - svdata_begin
+ .short CONFIG_SECURITY_VERSION
+ .long CONFIG_DISTRO_VERSION
+sv_signer:
+ .string CONFIG_SIGNER_NAME
+svdata_end:
+#endif
+
#ifdef CONFIG_DEBUG_EFI
/*
* The debug table is referenced via its Relative Virtual Address (RVA),
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 1dd82f1dd094..3cad8d63897e 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -179,14 +179,14 @@ menuconfig SECURITY_VERSION_SUPPORT
config SIGNER_NAME
string "Signer Name" if SECURITY_VERSION_SUPPORT
- depends on EFI && X86
+ depends on EFI && (X86 || ARM64)
default ""
help
This option specifies who signs or releases this kernel.
config DISTRO_VERSION
int "Distribution Version" if SECURITY_VERSION_SUPPORT
- depends on EFI && X86
+ depends on EFI && (X86 || ARM64)
default 0
range 0 4294967295
help
@@ -195,7 +195,7 @@ config DISTRO_VERSION
config SECURITY_VERSION
int "Security Version" if SECURITY_VERSION_SUPPORT
- depends on EFI && X86
+ depends on EFI && (X86 || ARM64)
default 0
range 0 65535
help
--
2.15.0
On Tue, Dec 5, 2017 at 5:01 AM, 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. 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" <[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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> On Tue, Dec 5, 2017 at 5:01 AM, 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. 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.
>
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.
Since Security Version is meant to be a warning, not a hard block, we
can introduce a timeout to the warning prompt if necessary. The system
still boots, but with a longer boot time.
Gary Lin
> 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" <[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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
* Gary Lin <[email protected]> wrote:
> On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > On Tue, Dec 5, 2017 at 5:01 AM, 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. 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.
> >
> 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?
Thanks,
Ingo
On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
>
> * Gary Lin <[email protected]> wrote:
>
> > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > On Tue, Dec 5, 2017 at 5:01 AM, 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. 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.
> > >
> > 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.
Cheers,
Gary Lin
* Gary Lin <[email protected]> wrote:
> On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> >
> > * Gary Lin <[email protected]> wrote:
> >
> > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > On Tue, Dec 5, 2017 at 5:01 AM, 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. 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.
> > > >
> > > 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?
Thanks,
Ingo
On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
>
> * Gary Lin <[email protected]> wrote:
>
> > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > >
> > > * Gary Lin <[email protected]> wrote:
> > >
> > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > On Tue, Dec 5, 2017 at 5:01 AM, 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. 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.
> > > > >
> > > > 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?
>
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.
The Security Version check is a warning rather than a hard block like the
signature check. The current plan is to add an extra check in the shim
verify protocol, so that we can check SV right after the signature check.
I'm thinking about adding a UEFI variable to control the timeout of the
warning prompt, e.g. 30 for 30 seconds and 0 for waiting indefinitely,
so that the warning prompt won't block the system boot unless the system
administrator wants so.
As for other bootloaders, SV is just a few extra bytes in the kernel
image and means nothing to them.
Cheers,
Gary Lin
* Gary Lin <[email protected]> wrote:
> On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> >
> > * Gary Lin <[email protected]> wrote:
> >
> > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > >
> > > > * Gary Lin <[email protected]> wrote:
> > > >
> > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > On Tue, Dec 5, 2017 at 5:01 AM, 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. 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.
> > > > > >
> > > > > 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?
>
> 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.
Thanks,
Ingo
On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
>
> * Gary Lin <[email protected]> wrote:
>
> > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > >
> > > * Gary Lin <[email protected]> wrote:
> > >
> > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > >
> > > > > * Gary Lin <[email protected]> wrote:
> > > > >
> > > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > > On Tue, Dec 5, 2017 at 5:01 AM, 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. 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.
> > > > > > >
> > > > > > 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?
> >
> > 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.
>
Even though the bootloader doesn't actually block the booting?
If the bootloader loads a kernel with lower SV, by default, the warning
prompt lasts for 30 seconds, and the system continues booting if the
user doesn't intervene. For the paranoid user, a variable can be set to
make the bootloader wait forever. Is it acceptable?
Thanks,
Gary Lin
* Gary Lin <[email protected]> wrote:
> On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> >
> > * Gary Lin <[email protected]> wrote:
> >
> > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > >
> > > > * Gary Lin <[email protected]> wrote:
> > > >
> > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > >
> > > > > > * Gary Lin <[email protected]> wrote:
> > > > > >
> > > > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > > > On Tue, Dec 5, 2017 at 5:01 AM, 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. 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.
> > > > > > > >
> > > > > > > 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?
> > >
> > > 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.
> >
> 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...
Thanks,
Ingo
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.
It just feels like an attempt to solve the problem in completely the
wrong place.
Alan
On Thu, Dec 07, 2017 at 11:35:52AM +0100, Ingo Molnar wrote:
>
>
> * Gary Lin <[email protected]> wrote:
>
> > On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> > >
> > > * Gary Lin <[email protected]> wrote:
> > >
> > > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > > >
> > > > > * Gary Lin <[email protected]> wrote:
> > > > >
> > > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > > >
> > > > > > > * Gary Lin <[email protected]> wrote:
> > > > > > >
> > > > > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > > > > On Tue, Dec 5, 2017 at 5:01 AM, 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. 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.
> > > > > > > > >
> > > > > > > > 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?
> > > >
> > > > 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.
> > >
> > 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...
>
OK, it seems the implementation in shim brings up some concern. I'll
discuss with my colleagues for other possible solutions.
Cheers,
Gary Lin
On Thu, Dec 07, 2017 at 02:26:57PM +0000, Alan Cox wrote:
> 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.
>
Ya, a menu for those kernels is also a kind of warning to the users.
Thanks for pointing the direction.
> Why do you even need this in the EFI stub ?
>
For 2 reasons.
1. We want the version number being unalterable. In a system with UEFI
Secure Boot, the signature appended to the kernel guarantees that the
version number is genuine.
2. For the cross-architecture support. Since the version number could be
anywhere in the image file, we need at least a offset to point to the
version number. That's why I choose the resource section/table in the
EFI header. It exists as long as the EFI stub exists. The design of
the directory allows different data stored separately.
If there is a better place for the version number, I'd be glad to adopt
it.
> 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.
>
The idea is that the security version only bumps only when it's really
necessary. For example, the new kernel fixes a severe bug that invalidates
the signature check of the modules. Or, the distro makes an official
release and would like to obsolete the alpha/beta/RC kernel. Anyway, it
depends on the distro policy.
Actually, our main target is only for the enterprise server, and the
kernel update path is relatively simple. Since it may bring some
confusion in a multi-boot system, we are currently not planning to
enable SV for the community distro, i.e. openSUSE.
Thanks,
Gary Lin