[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[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.

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@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Joey Lee <jlee@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>

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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[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.

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-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Cc: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
Cc: Joey Lee <jlee-IBi9RG/b67k@public.gmane.org>
Signed-off-by: Gary Lin <glin-IBi9RG/b67k@public.gmane.org>

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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[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.

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@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Joey Lee <jlee@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>

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

[RFC v3 PATCH 1/2] x86/efi: Introduce Security Version to x86

[Gary Lin]

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" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Joey Lee <jlee@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>
---
 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

[RFC v3 PATCH 1/2] x86/efi: Introduce Security Version to x86

[Gary Lin]

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" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Joey Lee <jlee@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>
---
 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

[RFC v3 PATCH 2/2] arm64/efi: Introduce Security Version to ARM64

[Gary Lin]

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 <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Joey Lee <jlee@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>
---
 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

[RFC v3 PATCH 2/2] arm64/efi: Introduce Security Version to ARM64

[Gary Lin]

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 <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Joey Lee <jlee@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>
---
 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

[RFC v3 PATCH 2/2] arm64/efi: Introduce Security Version to ARM64

[Gary Lin]

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 <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Joey Lee <jlee@suse.com>
Signed-off-by: Gary Lin <glin@suse.com>
---
 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Josh Boyer]

On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin <glin@suse.com> 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@zytor.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Matt Fleming <matt@codeblueprint.co.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Joey Lee <jlee@suse.com>
> Signed-off-by: Gary Lin <glin@suse.com>
>
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Josh Boyer]

On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin <glin-IBi9RG/b67k@public.gmane.org> 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-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
> Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
> Cc: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
> Cc: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
> Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
> Cc: Joey Lee <jlee-IBi9RG/b67k@public.gmane.org>
> Signed-off-by: Gary Lin <glin-IBi9RG/b67k@public.gmane.org>
>
> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Josh Boyer]

On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin <glin@suse.com> 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@zytor.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Matt Fleming <matt@codeblueprint.co.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Joey Lee <jlee@suse.com>
> Signed-off-by: Gary Lin <glin@suse.com>
>
> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin <glin@suse.com> 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" <hpa@zytor.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Matt Fleming <matt@codeblueprint.co.uk>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Joey Lee <jlee@suse.com>
> > Signed-off-by: Gary Lin <glin@suse.com>
> >
> > 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@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin <glin-IBi9RG/b67k@public.gmane.org> 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" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
> > Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
> > Cc: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Cc: Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Cc: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
> > Cc: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
> > Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
> > Cc: Joey Lee <jlee-IBi9RG/b67k@public.gmane.org>
> > Signed-off-by: Gary Lin <glin-IBi9RG/b67k@public.gmane.org>
> >
> > 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin <glin@suse.com> 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" <hpa@zytor.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Matt Fleming <matt@codeblueprint.co.uk>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Joey Lee <jlee@suse.com>
> > Signed-off-by: Gary Lin <glin@suse.com>
> >
> > 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
> 

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin <glin-IBi9RG/b67k@public.gmane.org> 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 <glin-IBi9RG/b67k@public.gmane.org> 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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> 
> * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> 
> * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> 
> * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin <glin@suse.com> wrote:

> On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin <glin@suse.com> wrote:

> On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin <glin@suse.com> wrote:

> On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin <glin@suse.com> wrote:
> 
> > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin <glin@suse.com> wrote:
> 
> > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin <glin@suse.com> wrote:
> 
> > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin <glin@suse.com> wrote:

> On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin <glin@suse.com> wrote:
> > 
> > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin <glin-IBi9RG/b67k@public.gmane.org> wrote:

> On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin <glin-IBi9RG/b67k@public.gmane.org> wrote:
> > 
> > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Gary Lin <glin-IBi9RG/b67k@public.gmane.org> 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 <glin-IBi9RG/b67k@public.gmane.org> 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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin <glin@suse.com> wrote:

> On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin <glin@suse.com> wrote:
> > 
> > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin <glin@suse.com> wrote:
> 
> > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin <glin@suse.com> wrote:
> > > 
> > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > 
> > > > > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin <glin-IBi9RG/b67k@public.gmane.org> wrote:
> 
> > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin <glin-IBi9RG/b67k@public.gmane.org> wrote:
> > > 
> > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > 
> > > > > * Gary Lin <glin-IBi9RG/b67k@public.gmane.org> 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 <glin-IBi9RG/b67k@public.gmane.org> 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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin <glin@suse.com> wrote:
> 
> > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin <glin@suse.com> wrote:
> > > 
> > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > 
> > > > > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin <glin@suse.com> wrote:

> On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin <glin@suse.com> wrote:
> > 
> > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Gary Lin <glin@suse.com> wrote:
> > > > 
> > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > > 
> > > > > > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin <glin-IBi9RG/b67k@public.gmane.org> wrote:

> On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin <glin-IBi9RG/b67k@public.gmane.org> wrote:
> > 
> > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Gary Lin <glin-IBi9RG/b67k@public.gmane.org> wrote:
> > > > 
> > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > > 
> > > > > > * Gary Lin <glin-IBi9RG/b67k@public.gmane.org> 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 <glin-IBi9RG/b67k@public.gmane.org> 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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin <glin@suse.com> wrote:

> On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin <glin@suse.com> wrote:
> > 
> > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Gary Lin <glin@suse.com> wrote:
> > > > 
> > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > > 
> > > > > > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Alan Cox]

On Tue,  5 Dec 2017 18:01:46 +0800
Gary Lin <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Alan Cox]

On Tue,  5 Dec 2017 18:01:46 +0800
Gary Lin <glin@suse.com> 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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Alan Cox]

On Tue,  5 Dec 2017 18:01:46 +0800
Gary Lin <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 11:35:52AM +0100, Ingo Molnar wrote:
> 
> 
> * Gary Lin <glin@suse.com> wrote:
> 
> > On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin <glin@suse.com> wrote:
> > > 
> > > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > > > 
> > > > > * Gary Lin <glin@suse.com> wrote:
> > > > > 
> > > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > > > 
> > > > > > > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 11:35:52AM +0100, Ingo Molnar wrote:
> 
> 
> * Gary Lin <glin@suse.com> wrote:
> 
> > On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin <glin@suse.com> wrote:
> > > 
> > > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > > > 
> > > > > * Gary Lin <glin@suse.com> wrote:
> > > > > 
> > > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > > > 
> > > > > > > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 11:35:52AM +0100, Ingo Molnar wrote:
> 
> 
> * Gary Lin <glin@suse.com> wrote:
> 
> > On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin <glin@suse.com> wrote:
> > > 
> > > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > > > 
> > > > > * Gary Lin <glin@suse.com> wrote:
> > > > > 
> > > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > > > 
> > > > > > > * Gary Lin <glin@suse.com> 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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[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 <glin@suse.com> 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

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[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 <glin@suse.com> 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

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[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 <glin@suse.com> 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