Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-10-02 Thread Gary Lin
On Fri, Sep 08, 2017 at 01:59:00PM -0700, h...@zytor.com wrote:
> On September 8, 2017 2:45:10 AM PDT, Gary Lin  wrote:
> >On Thu, Sep 07, 2017 at 02:16:21PM -0700, h...@zytor.com wrote:
> >> On September 7, 2017 2:44:51 AM PDT, Gary Lin  wrote:
> >> >On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
> >> >> On 1 June 2017 at 08:11, Gary Lin  wrote:
> >> >> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> >> >> >> A new section, secdata, in the setup header is introduced to
> >store
> >> >the
> >> >> >> distro-specific security version which is designed to help the
> >> >> >> bootloader to warn the user when loading a less secure or
> >> >vulnerable
> >> >> >> kernel. The secdata section can be presented as the following:
> >> >> >>
> >> >> >> struct sec_hdr {
> >> >> >>   __u16 header_length;
> >> >> >>   __u32 distro_version;
> >> >> >>   __u16 security_version;
> >> >> >> } __attribute__((packed));
> >> >> >> char *signer;
> >> >> >>
> >> >> >> It consists of a fixed size structure and a null-terminated
> >> >string.
> >> >> >> "header_length" is the size of "struct sec_hdr" and can be used
> >as
> >> >the
> >> >> >> offset to "signer". It also can be a kind of the "header
> >version"
> >> >to
> >> >> >> detect if any new member is introduced.
> >> >> >>
> >> >> >> The kernel packager of the distribution can put the distro name
> >in
> >> >> >> "signer" and the distro version in "distro_version". When a
> >severe
> >> >> >> vulnerability is fixed, the packager increases
> >"security_version"
> >> >in
> >> >> >> the kernel build afterward. The bootloader can maintain a list
> >of
> >> >the
> >> >> >> security versions of the current kernels and only allows the
> >> >kernel with
> >> >> >> a higher or equal security version to boot. If the user is
> >going
> >> >to boot
> >> >> >> a kernel with a lower security version, a warning should show
> >to
> >> >prevent
> >> >> >> the user from loading a vulnerable kernel accidentally.
> >> >> >>
> >> >> >> Enabling UEFI Secure Boot is recommended when using the
> >security
> >> >version
> >> >> >> or the attacker may alter the security version stealthily.
> >> >> >>
> >> >> > Any comment?
> >> >> >
> >> >> 
> >> >> This is now entirely x86-specific. My preference would be to have
> >a
> >> >> generic solution instead.
> >> >> 
> >> >After check the headers again, another idea came to my mind: the
> >MS-DOS
> >> >stub. It's designed to show a warning while the image is loaded in
> >> >DOS(*),
> >> >but I wonder if it still matters. In the x86 linux efi header, the
> >stub
> >> >is just a 3-lines message, while arm64 completely ignores the stub.
> >> >
> >> >Since there is a offset to the PE header at 0x3c, we can
> >theoretically
> >> >put any thing between 0x40 and the PE header without affecting the
> >> >current settings.
> >> >
> >> >HPA,
> >> >
> >> >Does the MS-DOS stub raise any concern to you?
> >> >
> >> >Thanks,
> >> >
> >> >Gary Lin
> >> >
> >> >(*)
> >>
> >>https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_
> >> >
> >> >> -- 
> >> >> Ard.
> >> >> 
> >> >> 
> >> >> >> 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: Ard Biesheuvel 
> >> >> >> Cc: "H. Peter Anvin" 
> >> >> >> Cc: Thomas Gleixner 
> >> >> >> Cc: Ingo Molnar 
> >> >> >> Cc: Joey Lee 
> >> >> >> Signed-off-by: Gary Lin 
> >> >> >> ---
> >[snip]
> >> >> >> --
> >> >> >> 2.12.2
> >> >> >>
> >> >> 
> >> 
> >> I really don't think that is a good idea.  I would much rather keep
> >this in a space we fully own.
> >Fine. I'll find another place for ARM64 (probably append the structure
> >right after the PE-header and denote the 2-byte offset in the reserved
> >fields in the first 64 bytes header).
> >
> >Thanks,
> >
> >Gary Lin
> 
> Another "safe" option would be to put it in a COFF segment; then it would be 
> system-independent.
Hi HPA,

Sorry for the late reply, I was travelling last two weeks.

In the beginning, I thought a new coff section was feasible. However, it
seems not possible for x86-64.

Although the section itself can be anywhere, we have to register an
entry in the section table in the coff optional header. For the x86-64
kernel image, the section table starts at 0x13b while every entry takes
40 bytes. Currently, there are 4 sections: .setup, .reloc, .text, and
.bss, so the new entry should be added at (0x13b + 0x24 

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-10-02 Thread Gary Lin
On Fri, Sep 08, 2017 at 01:59:00PM -0700, h...@zytor.com wrote:
> On September 8, 2017 2:45:10 AM PDT, Gary Lin  wrote:
> >On Thu, Sep 07, 2017 at 02:16:21PM -0700, h...@zytor.com wrote:
> >> On September 7, 2017 2:44:51 AM PDT, Gary Lin  wrote:
> >> >On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
> >> >> On 1 June 2017 at 08:11, Gary Lin  wrote:
> >> >> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> >> >> >> A new section, secdata, in the setup header is introduced to
> >store
> >> >the
> >> >> >> distro-specific security version which is designed to help the
> >> >> >> bootloader to warn the user when loading a less secure or
> >> >vulnerable
> >> >> >> kernel. The secdata section can be presented as the following:
> >> >> >>
> >> >> >> struct sec_hdr {
> >> >> >>   __u16 header_length;
> >> >> >>   __u32 distro_version;
> >> >> >>   __u16 security_version;
> >> >> >> } __attribute__((packed));
> >> >> >> char *signer;
> >> >> >>
> >> >> >> It consists of a fixed size structure and a null-terminated
> >> >string.
> >> >> >> "header_length" is the size of "struct sec_hdr" and can be used
> >as
> >> >the
> >> >> >> offset to "signer". It also can be a kind of the "header
> >version"
> >> >to
> >> >> >> detect if any new member is introduced.
> >> >> >>
> >> >> >> The kernel packager of the distribution can put the distro name
> >in
> >> >> >> "signer" and the distro version in "distro_version". When a
> >severe
> >> >> >> vulnerability is fixed, the packager increases
> >"security_version"
> >> >in
> >> >> >> the kernel build afterward. The bootloader can maintain a list
> >of
> >> >the
> >> >> >> security versions of the current kernels and only allows the
> >> >kernel with
> >> >> >> a higher or equal security version to boot. If the user is
> >going
> >> >to boot
> >> >> >> a kernel with a lower security version, a warning should show
> >to
> >> >prevent
> >> >> >> the user from loading a vulnerable kernel accidentally.
> >> >> >>
> >> >> >> Enabling UEFI Secure Boot is recommended when using the
> >security
> >> >version
> >> >> >> or the attacker may alter the security version stealthily.
> >> >> >>
> >> >> > Any comment?
> >> >> >
> >> >> 
> >> >> This is now entirely x86-specific. My preference would be to have
> >a
> >> >> generic solution instead.
> >> >> 
> >> >After check the headers again, another idea came to my mind: the
> >MS-DOS
> >> >stub. It's designed to show a warning while the image is loaded in
> >> >DOS(*),
> >> >but I wonder if it still matters. In the x86 linux efi header, the
> >stub
> >> >is just a 3-lines message, while arm64 completely ignores the stub.
> >> >
> >> >Since there is a offset to the PE header at 0x3c, we can
> >theoretically
> >> >put any thing between 0x40 and the PE header without affecting the
> >> >current settings.
> >> >
> >> >HPA,
> >> >
> >> >Does the MS-DOS stub raise any concern to you?
> >> >
> >> >Thanks,
> >> >
> >> >Gary Lin
> >> >
> >> >(*)
> >>
> >>https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_
> >> >
> >> >> -- 
> >> >> Ard.
> >> >> 
> >> >> 
> >> >> >> 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: Ard Biesheuvel 
> >> >> >> Cc: "H. Peter Anvin" 
> >> >> >> Cc: Thomas Gleixner 
> >> >> >> Cc: Ingo Molnar 
> >> >> >> Cc: Joey Lee 
> >> >> >> Signed-off-by: Gary Lin 
> >> >> >> ---
> >[snip]
> >> >> >> --
> >> >> >> 2.12.2
> >> >> >>
> >> >> 
> >> 
> >> I really don't think that is a good idea.  I would much rather keep
> >this in a space we fully own.
> >Fine. I'll find another place for ARM64 (probably append the structure
> >right after the PE-header and denote the 2-byte offset in the reserved
> >fields in the first 64 bytes header).
> >
> >Thanks,
> >
> >Gary Lin
> 
> Another "safe" option would be to put it in a COFF segment; then it would be 
> system-independent.
Hi HPA,

Sorry for the late reply, I was travelling last two weeks.

In the beginning, I thought a new coff section was feasible. However, it
seems not possible for x86-64.

Although the section itself can be anywhere, we have to register an
entry in the section table in the coff optional header. For the x86-64
kernel image, the section table starts at 0x13b while every entry takes
40 bytes. Currently, there are 4 sections: .setup, .reloc, .text, and
.bss, so the new entry should be added at (0x13b + 0x24 * 4) = 0x1db and
ended at 0x1ff. Unfortunately, the x86 boot protocol requires the setup
header starts at 0x1f1, so there is no room for a new entry in the 

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-09-10 Thread Gary Lin
On Fri, Sep 08, 2017 at 01:59:00PM -0700, h...@zytor.com wrote:
> On September 8, 2017 2:45:10 AM PDT, Gary Lin  wrote:
> >On Thu, Sep 07, 2017 at 02:16:21PM -0700, h...@zytor.com wrote:
> >> On September 7, 2017 2:44:51 AM PDT, Gary Lin  wrote:
> >> >On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
> >> >> On 1 June 2017 at 08:11, Gary Lin  wrote:
> >> >> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> >> >> >> A new section, secdata, in the setup header is introduced to
> >store
> >> >the
> >> >> >> distro-specific security version which is designed to help the
> >> >> >> bootloader to warn the user when loading a less secure or
> >> >vulnerable
> >> >> >> kernel. The secdata section can be presented as the following:
> >> >> >>
> >> >> >> struct sec_hdr {
> >> >> >>   __u16 header_length;
> >> >> >>   __u32 distro_version;
> >> >> >>   __u16 security_version;
> >> >> >> } __attribute__((packed));
> >> >> >> char *signer;
> >> >> >>
> >> >> >> It consists of a fixed size structure and a null-terminated
> >> >string.
> >> >> >> "header_length" is the size of "struct sec_hdr" and can be used
> >as
> >> >the
> >> >> >> offset to "signer". It also can be a kind of the "header
> >version"
> >> >to
> >> >> >> detect if any new member is introduced.
> >> >> >>
> >> >> >> The kernel packager of the distribution can put the distro name
> >in
> >> >> >> "signer" and the distro version in "distro_version". When a
> >severe
> >> >> >> vulnerability is fixed, the packager increases
> >"security_version"
> >> >in
> >> >> >> the kernel build afterward. The bootloader can maintain a list
> >of
> >> >the
> >> >> >> security versions of the current kernels and only allows the
> >> >kernel with
> >> >> >> a higher or equal security version to boot. If the user is
> >going
> >> >to boot
> >> >> >> a kernel with a lower security version, a warning should show
> >to
> >> >prevent
> >> >> >> the user from loading a vulnerable kernel accidentally.
> >> >> >>
> >> >> >> Enabling UEFI Secure Boot is recommended when using the
> >security
> >> >version
> >> >> >> or the attacker may alter the security version stealthily.
> >> >> >>
> >> >> > Any comment?
> >> >> >
> >> >> 
> >> >> This is now entirely x86-specific. My preference would be to have
> >a
> >> >> generic solution instead.
> >> >> 
> >> >After check the headers again, another idea came to my mind: the
> >MS-DOS
> >> >stub. It's designed to show a warning while the image is loaded in
> >> >DOS(*),
> >> >but I wonder if it still matters. In the x86 linux efi header, the
> >stub
> >> >is just a 3-lines message, while arm64 completely ignores the stub.
> >> >
> >> >Since there is a offset to the PE header at 0x3c, we can
> >theoretically
> >> >put any thing between 0x40 and the PE header without affecting the
> >> >current settings.
> >> >
> >> >HPA,
> >> >
> >> >Does the MS-DOS stub raise any concern to you?
> >> >
> >> >Thanks,
> >> >
> >> >Gary Lin
> >> >
> >> >(*)
> >>
> >>https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_
> >> >
> >> >> -- 
> >> >> Ard.
> >> >> 
> >> >> 
> >> >> >> 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: Ard Biesheuvel 
> >> >> >> Cc: "H. Peter Anvin" 
> >> >> >> Cc: Thomas Gleixner 
> >> >> >> Cc: Ingo Molnar 
> >> >> >> Cc: Joey Lee 
> >> >> >> Signed-off-by: Gary Lin 
> >> >> >> ---
> >[snip]
> >> >> >> --
> >> >> >> 2.12.2
> >> >> >>
> >> >> 
> >> 
> >> I really don't think that is a good idea.  I would much rather keep
> >this in a space we fully own.
> >Fine. I'll find another place for ARM64 (probably append the structure
> >right after the PE-header and denote the 2-byte offset in the reserved
> >fields in the first 64 bytes header).
> >
> >Thanks,
> >
> >Gary Lin
> 
> Another "safe" option would be to put it in a COFF segment; then it would be 
> system-independent.

Creating a new COFF section looks promising. Thanks for pointing the direction.

Gary Lin


Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-09-10 Thread Gary Lin
On Fri, Sep 08, 2017 at 01:59:00PM -0700, h...@zytor.com wrote:
> On September 8, 2017 2:45:10 AM PDT, Gary Lin  wrote:
> >On Thu, Sep 07, 2017 at 02:16:21PM -0700, h...@zytor.com wrote:
> >> On September 7, 2017 2:44:51 AM PDT, Gary Lin  wrote:
> >> >On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
> >> >> On 1 June 2017 at 08:11, Gary Lin  wrote:
> >> >> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> >> >> >> A new section, secdata, in the setup header is introduced to
> >store
> >> >the
> >> >> >> distro-specific security version which is designed to help the
> >> >> >> bootloader to warn the user when loading a less secure or
> >> >vulnerable
> >> >> >> kernel. The secdata section can be presented as the following:
> >> >> >>
> >> >> >> struct sec_hdr {
> >> >> >>   __u16 header_length;
> >> >> >>   __u32 distro_version;
> >> >> >>   __u16 security_version;
> >> >> >> } __attribute__((packed));
> >> >> >> char *signer;
> >> >> >>
> >> >> >> It consists of a fixed size structure and a null-terminated
> >> >string.
> >> >> >> "header_length" is the size of "struct sec_hdr" and can be used
> >as
> >> >the
> >> >> >> offset to "signer". It also can be a kind of the "header
> >version"
> >> >to
> >> >> >> detect if any new member is introduced.
> >> >> >>
> >> >> >> The kernel packager of the distribution can put the distro name
> >in
> >> >> >> "signer" and the distro version in "distro_version". When a
> >severe
> >> >> >> vulnerability is fixed, the packager increases
> >"security_version"
> >> >in
> >> >> >> the kernel build afterward. The bootloader can maintain a list
> >of
> >> >the
> >> >> >> security versions of the current kernels and only allows the
> >> >kernel with
> >> >> >> a higher or equal security version to boot. If the user is
> >going
> >> >to boot
> >> >> >> a kernel with a lower security version, a warning should show
> >to
> >> >prevent
> >> >> >> the user from loading a vulnerable kernel accidentally.
> >> >> >>
> >> >> >> Enabling UEFI Secure Boot is recommended when using the
> >security
> >> >version
> >> >> >> or the attacker may alter the security version stealthily.
> >> >> >>
> >> >> > Any comment?
> >> >> >
> >> >> 
> >> >> This is now entirely x86-specific. My preference would be to have
> >a
> >> >> generic solution instead.
> >> >> 
> >> >After check the headers again, another idea came to my mind: the
> >MS-DOS
> >> >stub. It's designed to show a warning while the image is loaded in
> >> >DOS(*),
> >> >but I wonder if it still matters. In the x86 linux efi header, the
> >stub
> >> >is just a 3-lines message, while arm64 completely ignores the stub.
> >> >
> >> >Since there is a offset to the PE header at 0x3c, we can
> >theoretically
> >> >put any thing between 0x40 and the PE header without affecting the
> >> >current settings.
> >> >
> >> >HPA,
> >> >
> >> >Does the MS-DOS stub raise any concern to you?
> >> >
> >> >Thanks,
> >> >
> >> >Gary Lin
> >> >
> >> >(*)
> >>
> >>https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_
> >> >
> >> >> -- 
> >> >> Ard.
> >> >> 
> >> >> 
> >> >> >> 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: Ard Biesheuvel 
> >> >> >> Cc: "H. Peter Anvin" 
> >> >> >> Cc: Thomas Gleixner 
> >> >> >> Cc: Ingo Molnar 
> >> >> >> Cc: Joey Lee 
> >> >> >> Signed-off-by: Gary Lin 
> >> >> >> ---
> >[snip]
> >> >> >> --
> >> >> >> 2.12.2
> >> >> >>
> >> >> 
> >> 
> >> I really don't think that is a good idea.  I would much rather keep
> >this in a space we fully own.
> >Fine. I'll find another place for ARM64 (probably append the structure
> >right after the PE-header and denote the 2-byte offset in the reserved
> >fields in the first 64 bytes header).
> >
> >Thanks,
> >
> >Gary Lin
> 
> Another "safe" option would be to put it in a COFF segment; then it would be 
> system-independent.

Creating a new COFF section looks promising. Thanks for pointing the direction.

Gary Lin


Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-09-08 Thread hpa
On September 8, 2017 2:45:10 AM PDT, Gary Lin  wrote:
>On Thu, Sep 07, 2017 at 02:16:21PM -0700, h...@zytor.com wrote:
>> On September 7, 2017 2:44:51 AM PDT, Gary Lin  wrote:
>> >On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
>> >> On 1 June 2017 at 08:11, Gary Lin  wrote:
>> >> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
>> >> >> A new section, secdata, in the setup header is introduced to
>store
>> >the
>> >> >> distro-specific security version which is designed to help the
>> >> >> bootloader to warn the user when loading a less secure or
>> >vulnerable
>> >> >> kernel. The secdata section can be presented as the following:
>> >> >>
>> >> >> struct sec_hdr {
>> >> >>   __u16 header_length;
>> >> >>   __u32 distro_version;
>> >> >>   __u16 security_version;
>> >> >> } __attribute__((packed));
>> >> >> char *signer;
>> >> >>
>> >> >> It consists of a fixed size structure and a null-terminated
>> >string.
>> >> >> "header_length" is the size of "struct sec_hdr" and can be used
>as
>> >the
>> >> >> offset to "signer". It also can be a kind of the "header
>version"
>> >to
>> >> >> detect if any new member is introduced.
>> >> >>
>> >> >> The kernel packager of the distribution can put the distro name
>in
>> >> >> "signer" and the distro version in "distro_version". When a
>severe
>> >> >> vulnerability is fixed, the packager increases
>"security_version"
>> >in
>> >> >> the kernel build afterward. The bootloader can maintain a list
>of
>> >the
>> >> >> security versions of the current kernels and only allows the
>> >kernel with
>> >> >> a higher or equal security version to boot. If the user is
>going
>> >to boot
>> >> >> a kernel with a lower security version, a warning should show
>to
>> >prevent
>> >> >> the user from loading a vulnerable kernel accidentally.
>> >> >>
>> >> >> Enabling UEFI Secure Boot is recommended when using the
>security
>> >version
>> >> >> or the attacker may alter the security version stealthily.
>> >> >>
>> >> > Any comment?
>> >> >
>> >> 
>> >> This is now entirely x86-specific. My preference would be to have
>a
>> >> generic solution instead.
>> >> 
>> >After check the headers again, another idea came to my mind: the
>MS-DOS
>> >stub. It's designed to show a warning while the image is loaded in
>> >DOS(*),
>> >but I wonder if it still matters. In the x86 linux efi header, the
>stub
>> >is just a 3-lines message, while arm64 completely ignores the stub.
>> >
>> >Since there is a offset to the PE header at 0x3c, we can
>theoretically
>> >put any thing between 0x40 and the PE header without affecting the
>> >current settings.
>> >
>> >HPA,
>> >
>> >Does the MS-DOS stub raise any concern to you?
>> >
>> >Thanks,
>> >
>> >Gary Lin
>> >
>> >(*)
>>
>>https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_
>> >
>> >> -- 
>> >> Ard.
>> >> 
>> >> 
>> >> >> 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: Ard Biesheuvel 
>> >> >> Cc: "H. Peter Anvin" 
>> >> >> Cc: Thomas Gleixner 
>> >> >> Cc: Ingo Molnar 
>> >> >> Cc: Joey Lee 
>> >> >> Signed-off-by: Gary Lin 
>> >> >> ---
>[snip]
>> >> >> --
>> >> >> 2.12.2
>> >> >>
>> >> 
>> 
>> I really don't think that is a good idea.  I would much rather keep
>this in a space we fully own.
>Fine. I'll find another place for ARM64 (probably append the structure
>right after the PE-header and denote the 2-byte offset in the reserved
>fields in the first 64 bytes header).
>
>Thanks,
>
>Gary Lin

Another "safe" option would be to put it in a COFF segment; then it would be 
system-independent.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-09-08 Thread hpa
On September 8, 2017 2:45:10 AM PDT, Gary Lin  wrote:
>On Thu, Sep 07, 2017 at 02:16:21PM -0700, h...@zytor.com wrote:
>> On September 7, 2017 2:44:51 AM PDT, Gary Lin  wrote:
>> >On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
>> >> On 1 June 2017 at 08:11, Gary Lin  wrote:
>> >> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
>> >> >> A new section, secdata, in the setup header is introduced to
>store
>> >the
>> >> >> distro-specific security version which is designed to help the
>> >> >> bootloader to warn the user when loading a less secure or
>> >vulnerable
>> >> >> kernel. The secdata section can be presented as the following:
>> >> >>
>> >> >> struct sec_hdr {
>> >> >>   __u16 header_length;
>> >> >>   __u32 distro_version;
>> >> >>   __u16 security_version;
>> >> >> } __attribute__((packed));
>> >> >> char *signer;
>> >> >>
>> >> >> It consists of a fixed size structure and a null-terminated
>> >string.
>> >> >> "header_length" is the size of "struct sec_hdr" and can be used
>as
>> >the
>> >> >> offset to "signer". It also can be a kind of the "header
>version"
>> >to
>> >> >> detect if any new member is introduced.
>> >> >>
>> >> >> The kernel packager of the distribution can put the distro name
>in
>> >> >> "signer" and the distro version in "distro_version". When a
>severe
>> >> >> vulnerability is fixed, the packager increases
>"security_version"
>> >in
>> >> >> the kernel build afterward. The bootloader can maintain a list
>of
>> >the
>> >> >> security versions of the current kernels and only allows the
>> >kernel with
>> >> >> a higher or equal security version to boot. If the user is
>going
>> >to boot
>> >> >> a kernel with a lower security version, a warning should show
>to
>> >prevent
>> >> >> the user from loading a vulnerable kernel accidentally.
>> >> >>
>> >> >> Enabling UEFI Secure Boot is recommended when using the
>security
>> >version
>> >> >> or the attacker may alter the security version stealthily.
>> >> >>
>> >> > Any comment?
>> >> >
>> >> 
>> >> This is now entirely x86-specific. My preference would be to have
>a
>> >> generic solution instead.
>> >> 
>> >After check the headers again, another idea came to my mind: the
>MS-DOS
>> >stub. It's designed to show a warning while the image is loaded in
>> >DOS(*),
>> >but I wonder if it still matters. In the x86 linux efi header, the
>stub
>> >is just a 3-lines message, while arm64 completely ignores the stub.
>> >
>> >Since there is a offset to the PE header at 0x3c, we can
>theoretically
>> >put any thing between 0x40 and the PE header without affecting the
>> >current settings.
>> >
>> >HPA,
>> >
>> >Does the MS-DOS stub raise any concern to you?
>> >
>> >Thanks,
>> >
>> >Gary Lin
>> >
>> >(*)
>>
>>https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_
>> >
>> >> -- 
>> >> Ard.
>> >> 
>> >> 
>> >> >> 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: Ard Biesheuvel 
>> >> >> Cc: "H. Peter Anvin" 
>> >> >> Cc: Thomas Gleixner 
>> >> >> Cc: Ingo Molnar 
>> >> >> Cc: Joey Lee 
>> >> >> Signed-off-by: Gary Lin 
>> >> >> ---
>[snip]
>> >> >> --
>> >> >> 2.12.2
>> >> >>
>> >> 
>> 
>> I really don't think that is a good idea.  I would much rather keep
>this in a space we fully own.
>Fine. I'll find another place for ARM64 (probably append the structure
>right after the PE-header and denote the 2-byte offset in the reserved
>fields in the first 64 bytes header).
>
>Thanks,
>
>Gary Lin

Another "safe" option would be to put it in a COFF segment; then it would be 
system-independent.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-09-08 Thread Gary Lin
On Thu, Sep 07, 2017 at 02:16:21PM -0700, h...@zytor.com wrote:
> On September 7, 2017 2:44:51 AM PDT, Gary Lin  wrote:
> >On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
> >> On 1 June 2017 at 08:11, Gary Lin  wrote:
> >> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> >> >> A new section, secdata, in the setup header is introduced to store
> >the
> >> >> distro-specific security version which is designed to help the
> >> >> bootloader to warn the user when loading a less secure or
> >vulnerable
> >> >> kernel. The secdata section can be presented as the following:
> >> >>
> >> >> struct sec_hdr {
> >> >>   __u16 header_length;
> >> >>   __u32 distro_version;
> >> >>   __u16 security_version;
> >> >> } __attribute__((packed));
> >> >> char *signer;
> >> >>
> >> >> It consists of a fixed size structure and a null-terminated
> >string.
> >> >> "header_length" is the size of "struct sec_hdr" and can be used as
> >the
> >> >> offset to "signer". It also can be a kind of the "header version"
> >to
> >> >> detect if any new member is introduced.
> >> >>
> >> >> The kernel packager of the distribution can put the distro name in
> >> >> "signer" and the distro version in "distro_version". When a severe
> >> >> vulnerability is fixed, the packager increases "security_version"
> >in
> >> >> the kernel build afterward. The bootloader can maintain a list of
> >the
> >> >> security versions of the current kernels and only allows the
> >kernel with
> >> >> a higher or equal security version to boot. If the user is going
> >to boot
> >> >> a kernel with a lower security version, a warning should show to
> >prevent
> >> >> the user from loading a vulnerable kernel accidentally.
> >> >>
> >> >> Enabling UEFI Secure Boot is recommended when using the security
> >version
> >> >> or the attacker may alter the security version stealthily.
> >> >>
> >> > Any comment?
> >> >
> >> 
> >> This is now entirely x86-specific. My preference would be to have a
> >> generic solution instead.
> >> 
> >After check the headers again, another idea came to my mind: the MS-DOS
> >stub. It's designed to show a warning while the image is loaded in
> >DOS(*),
> >but I wonder if it still matters. In the x86 linux efi header, the stub
> >is just a 3-lines message, while arm64 completely ignores the stub.
> >
> >Since there is a offset to the PE header at 0x3c, we can theoretically
> >put any thing between 0x40 and the PE header without affecting the
> >current settings.
> >
> >HPA,
> >
> >Does the MS-DOS stub raise any concern to you?
> >
> >Thanks,
> >
> >Gary Lin
> >
> >(*)
> >https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_
> >
> >> -- 
> >> Ard.
> >> 
> >> 
> >> >> 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: Ard Biesheuvel 
> >> >> Cc: "H. Peter Anvin" 
> >> >> Cc: Thomas Gleixner 
> >> >> Cc: Ingo Molnar 
> >> >> Cc: Joey Lee 
> >> >> Signed-off-by: Gary Lin 
> >> >> ---
[snip]
> >> >> --
> >> >> 2.12.2
> >> >>
> >> 
> 
> I really don't think that is a good idea.  I would much rather keep this in a 
> space we fully own.
Fine. I'll find another place for ARM64 (probably append the structure
right after the PE-header and denote the 2-byte offset in the reserved
fields in the first 64 bytes header).

Thanks,

Gary Lin


Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-09-08 Thread Gary Lin
On Thu, Sep 07, 2017 at 02:16:21PM -0700, h...@zytor.com wrote:
> On September 7, 2017 2:44:51 AM PDT, Gary Lin  wrote:
> >On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
> >> On 1 June 2017 at 08:11, Gary Lin  wrote:
> >> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> >> >> A new section, secdata, in the setup header is introduced to store
> >the
> >> >> distro-specific security version which is designed to help the
> >> >> bootloader to warn the user when loading a less secure or
> >vulnerable
> >> >> kernel. The secdata section can be presented as the following:
> >> >>
> >> >> struct sec_hdr {
> >> >>   __u16 header_length;
> >> >>   __u32 distro_version;
> >> >>   __u16 security_version;
> >> >> } __attribute__((packed));
> >> >> char *signer;
> >> >>
> >> >> It consists of a fixed size structure and a null-terminated
> >string.
> >> >> "header_length" is the size of "struct sec_hdr" and can be used as
> >the
> >> >> offset to "signer". It also can be a kind of the "header version"
> >to
> >> >> detect if any new member is introduced.
> >> >>
> >> >> The kernel packager of the distribution can put the distro name in
> >> >> "signer" and the distro version in "distro_version". When a severe
> >> >> vulnerability is fixed, the packager increases "security_version"
> >in
> >> >> the kernel build afterward. The bootloader can maintain a list of
> >the
> >> >> security versions of the current kernels and only allows the
> >kernel with
> >> >> a higher or equal security version to boot. If the user is going
> >to boot
> >> >> a kernel with a lower security version, a warning should show to
> >prevent
> >> >> the user from loading a vulnerable kernel accidentally.
> >> >>
> >> >> Enabling UEFI Secure Boot is recommended when using the security
> >version
> >> >> or the attacker may alter the security version stealthily.
> >> >>
> >> > Any comment?
> >> >
> >> 
> >> This is now entirely x86-specific. My preference would be to have a
> >> generic solution instead.
> >> 
> >After check the headers again, another idea came to my mind: the MS-DOS
> >stub. It's designed to show a warning while the image is loaded in
> >DOS(*),
> >but I wonder if it still matters. In the x86 linux efi header, the stub
> >is just a 3-lines message, while arm64 completely ignores the stub.
> >
> >Since there is a offset to the PE header at 0x3c, we can theoretically
> >put any thing between 0x40 and the PE header without affecting the
> >current settings.
> >
> >HPA,
> >
> >Does the MS-DOS stub raise any concern to you?
> >
> >Thanks,
> >
> >Gary Lin
> >
> >(*)
> >https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_
> >
> >> -- 
> >> Ard.
> >> 
> >> 
> >> >> 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: Ard Biesheuvel 
> >> >> Cc: "H. Peter Anvin" 
> >> >> Cc: Thomas Gleixner 
> >> >> Cc: Ingo Molnar 
> >> >> Cc: Joey Lee 
> >> >> Signed-off-by: Gary Lin 
> >> >> ---
[snip]
> >> >> --
> >> >> 2.12.2
> >> >>
> >> 
> 
> I really don't think that is a good idea.  I would much rather keep this in a 
> space we fully own.
Fine. I'll find another place for ARM64 (probably append the structure
right after the PE-header and denote the 2-byte offset in the reserved
fields in the first 64 bytes header).

Thanks,

Gary Lin


Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-09-07 Thread hpa
On September 7, 2017 2:44:51 AM PDT, Gary Lin  wrote:
>On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
>> On 1 June 2017 at 08:11, Gary Lin  wrote:
>> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
>> >> A new section, secdata, in the setup header is introduced to store
>the
>> >> distro-specific security version which is designed to help the
>> >> bootloader to warn the user when loading a less secure or
>vulnerable
>> >> kernel. The secdata section can be presented as the following:
>> >>
>> >> struct sec_hdr {
>> >>   __u16 header_length;
>> >>   __u32 distro_version;
>> >>   __u16 security_version;
>> >> } __attribute__((packed));
>> >> char *signer;
>> >>
>> >> It consists of a fixed size structure and a null-terminated
>string.
>> >> "header_length" is the size of "struct sec_hdr" and can be used as
>the
>> >> offset to "signer". It also can be a kind of the "header version"
>to
>> >> detect if any new member is introduced.
>> >>
>> >> The kernel packager of the distribution can put the distro name in
>> >> "signer" and the distro version in "distro_version". When a severe
>> >> vulnerability is fixed, the packager increases "security_version"
>in
>> >> the kernel build afterward. The bootloader can maintain a list of
>the
>> >> security versions of the current kernels and only allows the
>kernel with
>> >> a higher or equal security version to boot. If the user is going
>to boot
>> >> a kernel with a lower security version, a warning should show to
>prevent
>> >> the user from loading a vulnerable kernel accidentally.
>> >>
>> >> Enabling UEFI Secure Boot is recommended when using the security
>version
>> >> or the attacker may alter the security version stealthily.
>> >>
>> > Any comment?
>> >
>> 
>> This is now entirely x86-specific. My preference would be to have a
>> generic solution instead.
>> 
>After check the headers again, another idea came to my mind: the MS-DOS
>stub. It's designed to show a warning while the image is loaded in
>DOS(*),
>but I wonder if it still matters. In the x86 linux efi header, the stub
>is just a 3-lines message, while arm64 completely ignores the stub.
>
>Since there is a offset to the PE header at 0x3c, we can theoretically
>put any thing between 0x40 and the PE header without affecting the
>current settings.
>
>HPA,
>
>Does the MS-DOS stub raise any concern to you?
>
>Thanks,
>
>Gary Lin
>
>(*)
>https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_
>
>> -- 
>> Ard.
>> 
>> 
>> >> 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: Ard Biesheuvel 
>> >> Cc: "H. Peter Anvin" 
>> >> Cc: Thomas Gleixner 
>> >> Cc: Ingo Molnar 
>> >> Cc: Joey Lee 
>> >> Signed-off-by: Gary Lin 
>> >> ---
>> >>  arch/x86/Kconfig  | 28
>
>> >>  arch/x86/boot/header.S| 14 +-
>> >>  arch/x86/boot/setup.ld|  1 +
>> >>  arch/x86/boot/tools/build.c   |  1 -
>> >>  arch/x86/include/uapi/asm/bootparam.h |  1 +
>> >>  5 files changed, 43 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> >> index 5bbdef151805..2c5539518ce0 100644
>> >> --- a/arch/x86/Kconfig
>> >> +++ b/arch/x86/Kconfig
>> >> @@ -1817,6 +1817,34 @@ config EFI_MIXED
>> >>
>> >>  If unsure, say N.
>> >>
>> >> +config SIGNER_NAME
>> >> + string "Signer name"
>> >> + default ""
>> >> + ---help---
>> >> +This option specifies who signs or releases this kernel.
>> >> +
>> >> +config DISTRO_VERSION
>> >> + int "Distribution version"
>> >> + default 0
>> >> + range 0 4294967295
>> >> + ---help---
>> >> +   This option specifies the distribution version which this
>> >> +   kernel belongs to.
>> >> +
>> >> +config SECURITY_VERSION
>> >> + int "Security version"
>> >> + default 0
>> >> + range 0 65535
>> >> + ---help---
>> >> +The security version is the version defined by the
>distribution
>> >> +to indicate the severe security fixes. The bootloader can
>maintain
>> >> +a list of the security versions of the current kernels.
>After
>> >> +fixing a severe vulnerability in the kernel, the
>distribution can
>> >> +increase the security version to notify the bootloader to
>update
>> >> +the list. When booting a kernel with a lower security
>version,
>> >> +the bootloader warns the user to avoid 

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-09-07 Thread hpa
On September 7, 2017 2:44:51 AM PDT, Gary Lin  wrote:
>On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
>> On 1 June 2017 at 08:11, Gary Lin  wrote:
>> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
>> >> A new section, secdata, in the setup header is introduced to store
>the
>> >> distro-specific security version which is designed to help the
>> >> bootloader to warn the user when loading a less secure or
>vulnerable
>> >> kernel. The secdata section can be presented as the following:
>> >>
>> >> struct sec_hdr {
>> >>   __u16 header_length;
>> >>   __u32 distro_version;
>> >>   __u16 security_version;
>> >> } __attribute__((packed));
>> >> char *signer;
>> >>
>> >> It consists of a fixed size structure and a null-terminated
>string.
>> >> "header_length" is the size of "struct sec_hdr" and can be used as
>the
>> >> offset to "signer". It also can be a kind of the "header version"
>to
>> >> detect if any new member is introduced.
>> >>
>> >> The kernel packager of the distribution can put the distro name in
>> >> "signer" and the distro version in "distro_version". When a severe
>> >> vulnerability is fixed, the packager increases "security_version"
>in
>> >> the kernel build afterward. The bootloader can maintain a list of
>the
>> >> security versions of the current kernels and only allows the
>kernel with
>> >> a higher or equal security version to boot. If the user is going
>to boot
>> >> a kernel with a lower security version, a warning should show to
>prevent
>> >> the user from loading a vulnerable kernel accidentally.
>> >>
>> >> Enabling UEFI Secure Boot is recommended when using the security
>version
>> >> or the attacker may alter the security version stealthily.
>> >>
>> > Any comment?
>> >
>> 
>> This is now entirely x86-specific. My preference would be to have a
>> generic solution instead.
>> 
>After check the headers again, another idea came to my mind: the MS-DOS
>stub. It's designed to show a warning while the image is loaded in
>DOS(*),
>but I wonder if it still matters. In the x86 linux efi header, the stub
>is just a 3-lines message, while arm64 completely ignores the stub.
>
>Since there is a offset to the PE header at 0x3c, we can theoretically
>put any thing between 0x40 and the PE header without affecting the
>current settings.
>
>HPA,
>
>Does the MS-DOS stub raise any concern to you?
>
>Thanks,
>
>Gary Lin
>
>(*)
>https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_
>
>> -- 
>> Ard.
>> 
>> 
>> >> 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: Ard Biesheuvel 
>> >> Cc: "H. Peter Anvin" 
>> >> Cc: Thomas Gleixner 
>> >> Cc: Ingo Molnar 
>> >> Cc: Joey Lee 
>> >> Signed-off-by: Gary Lin 
>> >> ---
>> >>  arch/x86/Kconfig  | 28
>
>> >>  arch/x86/boot/header.S| 14 +-
>> >>  arch/x86/boot/setup.ld|  1 +
>> >>  arch/x86/boot/tools/build.c   |  1 -
>> >>  arch/x86/include/uapi/asm/bootparam.h |  1 +
>> >>  5 files changed, 43 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> >> index 5bbdef151805..2c5539518ce0 100644
>> >> --- a/arch/x86/Kconfig
>> >> +++ b/arch/x86/Kconfig
>> >> @@ -1817,6 +1817,34 @@ config EFI_MIXED
>> >>
>> >>  If unsure, say N.
>> >>
>> >> +config SIGNER_NAME
>> >> + string "Signer name"
>> >> + default ""
>> >> + ---help---
>> >> +This option specifies who signs or releases this kernel.
>> >> +
>> >> +config DISTRO_VERSION
>> >> + int "Distribution version"
>> >> + default 0
>> >> + range 0 4294967295
>> >> + ---help---
>> >> +   This option specifies the distribution version which this
>> >> +   kernel belongs to.
>> >> +
>> >> +config SECURITY_VERSION
>> >> + int "Security version"
>> >> + default 0
>> >> + range 0 65535
>> >> + ---help---
>> >> +The security version is the version defined by the
>distribution
>> >> +to indicate the severe security fixes. The bootloader can
>maintain
>> >> +a list of the security versions of the current kernels.
>After
>> >> +fixing a severe vulnerability in the kernel, the
>distribution can
>> >> +increase the security version to notify the bootloader to
>update
>> >> +the list. When booting a kernel with a lower security
>version,
>> >> +the bootloader warns the user to avoid loading a
>vulnerable kernel
>> >> +accidentally.
>> >> +
>> >>  config SECCOMP
>> >>   def_bool y
>> >>   prompt "Enable 

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-09-07 Thread Gary Lin
On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
> On 1 June 2017 at 08:11, Gary Lin  wrote:
> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> >> A new section, secdata, in the setup header is introduced to store the
> >> distro-specific security version which is designed to help the
> >> bootloader to warn the user when loading a less secure or vulnerable
> >> kernel. The secdata section can be presented as the following:
> >>
> >> struct sec_hdr {
> >>   __u16 header_length;
> >>   __u32 distro_version;
> >>   __u16 security_version;
> >> } __attribute__((packed));
> >> char *signer;
> >>
> >> It consists of a fixed size structure and a null-terminated string.
> >> "header_length" is the size of "struct sec_hdr" and can be used as the
> >> offset to "signer". It also can be a kind of the "header version" to
> >> detect if any new member is introduced.
> >>
> >> The kernel packager of the distribution can put the distro name in
> >> "signer" and the distro version in "distro_version". When a severe
> >> vulnerability is fixed, the packager increases "security_version" in
> >> the kernel build afterward. The bootloader can maintain a list of the
> >> security versions of the current kernels and only allows the kernel with
> >> a higher or equal security version to boot. If the user is going to boot
> >> a kernel with a lower security version, a warning should show to prevent
> >> the user from loading a vulnerable kernel accidentally.
> >>
> >> Enabling UEFI Secure Boot is recommended when using the security version
> >> or the attacker may alter the security version stealthily.
> >>
> > Any comment?
> >
> 
> This is now entirely x86-specific. My preference would be to have a
> generic solution instead.
> 
After check the headers again, another idea came to my mind: the MS-DOS
stub. It's designed to show a warning while the image is loaded in DOS(*),
but I wonder if it still matters. In the x86 linux efi header, the stub
is just a 3-lines message, while arm64 completely ignores the stub.

Since there is a offset to the PE header at 0x3c, we can theoretically
put any thing between 0x40 and the PE header without affecting the
current settings.

HPA,

Does the MS-DOS stub raise any concern to you?

Thanks,

Gary Lin

(*) 
https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_

> -- 
> Ard.
> 
> 
> >> 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: Ard Biesheuvel 
> >> Cc: "H. Peter Anvin" 
> >> Cc: Thomas Gleixner 
> >> Cc: Ingo Molnar 
> >> Cc: Joey Lee 
> >> Signed-off-by: Gary Lin 
> >> ---
> >>  arch/x86/Kconfig  | 28 
> >>  arch/x86/boot/header.S| 14 +-
> >>  arch/x86/boot/setup.ld|  1 +
> >>  arch/x86/boot/tools/build.c   |  1 -
> >>  arch/x86/include/uapi/asm/bootparam.h |  1 +
> >>  5 files changed, 43 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> index 5bbdef151805..2c5539518ce0 100644
> >> --- a/arch/x86/Kconfig
> >> +++ b/arch/x86/Kconfig
> >> @@ -1817,6 +1817,34 @@ config EFI_MIXED
> >>
> >>  If unsure, say N.
> >>
> >> +config SIGNER_NAME
> >> + string "Signer name"
> >> + default ""
> >> + ---help---
> >> +This option specifies who signs or releases this kernel.
> >> +
> >> +config DISTRO_VERSION
> >> + int "Distribution version"
> >> + default 0
> >> + range 0 4294967295
> >> + ---help---
> >> +   This option specifies the distribution version which this
> >> +   kernel belongs to.
> >> +
> >> +config SECURITY_VERSION
> >> + int "Security version"
> >> + default 0
> >> + range 0 65535
> >> + ---help---
> >> +The security version is the version defined by the distribution
> >> +to indicate the severe security fixes. The bootloader can maintain
> >> +a list of the security versions of the current kernels. After
> >> +fixing a severe vulnerability in the kernel, the distribution can
> >> +increase the security version to notify the bootloader to update
> >> +the list. When booting a kernel with a lower security version,
> >> +the bootloader warns the user to avoid loading a vulnerable kernel
> >> +accidentally.
> >> +
> >>  config SECCOMP
> >>   def_bool y
> >>   prompt "Enable seccomp to safely compute untrusted bytecode"
> >> diff --git 

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-09-07 Thread Gary Lin
On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
> On 1 June 2017 at 08:11, Gary Lin  wrote:
> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> >> A new section, secdata, in the setup header is introduced to store the
> >> distro-specific security version which is designed to help the
> >> bootloader to warn the user when loading a less secure or vulnerable
> >> kernel. The secdata section can be presented as the following:
> >>
> >> struct sec_hdr {
> >>   __u16 header_length;
> >>   __u32 distro_version;
> >>   __u16 security_version;
> >> } __attribute__((packed));
> >> char *signer;
> >>
> >> It consists of a fixed size structure and a null-terminated string.
> >> "header_length" is the size of "struct sec_hdr" and can be used as the
> >> offset to "signer". It also can be a kind of the "header version" to
> >> detect if any new member is introduced.
> >>
> >> The kernel packager of the distribution can put the distro name in
> >> "signer" and the distro version in "distro_version". When a severe
> >> vulnerability is fixed, the packager increases "security_version" in
> >> the kernel build afterward. The bootloader can maintain a list of the
> >> security versions of the current kernels and only allows the kernel with
> >> a higher or equal security version to boot. If the user is going to boot
> >> a kernel with a lower security version, a warning should show to prevent
> >> the user from loading a vulnerable kernel accidentally.
> >>
> >> Enabling UEFI Secure Boot is recommended when using the security version
> >> or the attacker may alter the security version stealthily.
> >>
> > Any comment?
> >
> 
> This is now entirely x86-specific. My preference would be to have a
> generic solution instead.
> 
After check the headers again, another idea came to my mind: the MS-DOS
stub. It's designed to show a warning while the image is loaded in DOS(*),
but I wonder if it still matters. In the x86 linux efi header, the stub
is just a 3-lines message, while arm64 completely ignores the stub.

Since there is a offset to the PE header at 0x3c, we can theoretically
put any thing between 0x40 and the PE header without affecting the
current settings.

HPA,

Does the MS-DOS stub raise any concern to you?

Thanks,

Gary Lin

(*) 
https://msdn.microsoft.com/zh-tw/library/windows/desktop/ms680547(v=vs.85).aspx#ms-dos_stub__image_only_

> -- 
> Ard.
> 
> 
> >> 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: Ard Biesheuvel 
> >> Cc: "H. Peter Anvin" 
> >> Cc: Thomas Gleixner 
> >> Cc: Ingo Molnar 
> >> Cc: Joey Lee 
> >> Signed-off-by: Gary Lin 
> >> ---
> >>  arch/x86/Kconfig  | 28 
> >>  arch/x86/boot/header.S| 14 +-
> >>  arch/x86/boot/setup.ld|  1 +
> >>  arch/x86/boot/tools/build.c   |  1 -
> >>  arch/x86/include/uapi/asm/bootparam.h |  1 +
> >>  5 files changed, 43 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> index 5bbdef151805..2c5539518ce0 100644
> >> --- a/arch/x86/Kconfig
> >> +++ b/arch/x86/Kconfig
> >> @@ -1817,6 +1817,34 @@ config EFI_MIXED
> >>
> >>  If unsure, say N.
> >>
> >> +config SIGNER_NAME
> >> + string "Signer name"
> >> + default ""
> >> + ---help---
> >> +This option specifies who signs or releases this kernel.
> >> +
> >> +config DISTRO_VERSION
> >> + int "Distribution version"
> >> + default 0
> >> + range 0 4294967295
> >> + ---help---
> >> +   This option specifies the distribution version which this
> >> +   kernel belongs to.
> >> +
> >> +config SECURITY_VERSION
> >> + int "Security version"
> >> + default 0
> >> + range 0 65535
> >> + ---help---
> >> +The security version is the version defined by the distribution
> >> +to indicate the severe security fixes. The bootloader can maintain
> >> +a list of the security versions of the current kernels. After
> >> +fixing a severe vulnerability in the kernel, the distribution can
> >> +increase the security version to notify the bootloader to update
> >> +the list. When booting a kernel with a lower security version,
> >> +the bootloader warns the user to avoid loading a vulnerable kernel
> >> +accidentally.
> >> +
> >>  config SECCOMP
> >>   def_bool y
> >>   prompt "Enable seccomp to safely compute untrusted bytecode"
> >> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> >> index 3dd5be33aaa7..37683caf1668 100644
> >> --- a/arch/x86/boot/header.S
> >> +++ 

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-08-19 Thread joeyli
Hi,

On Mon, Jul 10, 2017 at 11:24:44AM +0800, Gary Lin wrote:
> A new section, secdata, in the setup header is introduced to store the
> distro-specific security version which is designed to help the
> bootloader to warn the user when loading a less secure or vulnerable
> kernel. The secdata section can be presented as the following:
> 
> struct sec_hdr {
>   __u16 header_length;
>   __u32 distro_version;
>   __u16 security_version;
> } __attribute__((packed));
> char *signer;
> 
> It consists of a fixed size structure and a null-terminated string.
> "header_length" is the size of "struct sec_hdr" and can be used as the
> offset to "signer". It also can be a kind of the "header version" to
> detect if any new member is introduced.
> 
> The kernel packager of the distribution can put the distro name in
> "signer" and the distro version in "distro_version". When a severe
> vulnerability is fixed, the packager increases "security_version" in
> the kernel build afterward. The bootloader can maintain a list of the
> security versions of the current kernels and only allows the kernel with
> a higher or equal security version to boot. If the user is going to boot
> a kernel with a lower security version, a warning should show to prevent
> the user from loading a vulnerable kernel accidentally.
> 
> Enabling UEFI Secure Boot is recommended when using the security version
> or the attacker may alter the security version stealthily.
> 
> (For more details: https://github.com/lcp/shim/wiki/Security-Version)
> 
> 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: Ard Biesheuvel 
> Cc: "H. Peter Anvin" 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Joey Lee 
> Signed-off-by: Gary Lin 

I have reviewed and tested this patch. Please feel free to add:

Signed-off-by: Joey Lee 

Thanks
Joey Lee

> ---
>  arch/x86/Kconfig  | 28 
>  arch/x86/boot/header.S| 14 +-
>  arch/x86/boot/setup.ld|  1 +
>  arch/x86/boot/tools/build.c   |  1 -
>  arch/x86/include/uapi/asm/bootparam.h |  1 +
>  5 files changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 316152f72bb9..043ff86828a6 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1828,6 +1828,34 @@ config EFI_MIXED
>  
>  If unsure, say N.
>  
> +config SIGNER_NAME
> + string "Signer name"
> + default ""
> + ---help---
> +This option specifies who signs or releases this kernel.
> +
> +config DISTRO_VERSION
> + int "Distribution version"
> + default 0
> + range 0 4294967295
> + ---help---
> +   This option specifies the distribution version which this
> +   kernel belongs to.
> +
> +config SECURITY_VERSION
> + int "Security version"
> + default 0
> + range 0 65535
> + ---help---
> +The security version is the version defined by the distribution
> +to indicate the severe security fixes. The bootloader can maintain
> +a list of the security versions of the current kernels. After
> +fixing a severe vulnerability in the kernel, the distribution can
> +increase the security version to notify the bootloader to update
> +the list. When booting a kernel with a lower security version,
> +the bootloader warns the user to avoid loading a vulnerable kernel
> +accidentally.
> +
>  config SECCOMP
>   def_bool y
>   prompt "Enable seccomp to safely compute untrusted bytecode"
> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> index 2ed8f0c25def..c62e0baf2d89 100644
> --- a/arch/x86/boot/header.S
> +++ b/arch/x86/boot/header.S
> @@ -300,7 +300,7 @@ _start:
>   # Part 2 of the header, from the old setup.S
>  
>   .ascii  "HdrS"  # header signature
> - .word   0x020d  # header version number (>= 0x0105)
> + .word   0x020e  # header version number (>= 0x0105)
>   # or else old loadlin-1.5 will fail)
>   .globl realmode_swtch
>  realmode_swtch:  .word   0, 0# default_switch, SETUPSEG
> @@ -551,6 +551,7 @@ pref_address: .quad LOAD_PHYSICAL_ADDR
> # preferred load addr
>  
>  init_size:   .long INIT_SIZE # kernel initialization size
>  handover_offset: .long 0 # Filled in by build.c
> +secdata_offset:  .word secdata_start
>  
>  # End of setup 

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-08-19 Thread joeyli
Hi,

On Mon, Jul 10, 2017 at 11:24:44AM +0800, Gary Lin wrote:
> A new section, secdata, in the setup header is introduced to store the
> distro-specific security version which is designed to help the
> bootloader to warn the user when loading a less secure or vulnerable
> kernel. The secdata section can be presented as the following:
> 
> struct sec_hdr {
>   __u16 header_length;
>   __u32 distro_version;
>   __u16 security_version;
> } __attribute__((packed));
> char *signer;
> 
> It consists of a fixed size structure and a null-terminated string.
> "header_length" is the size of "struct sec_hdr" and can be used as the
> offset to "signer". It also can be a kind of the "header version" to
> detect if any new member is introduced.
> 
> The kernel packager of the distribution can put the distro name in
> "signer" and the distro version in "distro_version". When a severe
> vulnerability is fixed, the packager increases "security_version" in
> the kernel build afterward. The bootloader can maintain a list of the
> security versions of the current kernels and only allows the kernel with
> a higher or equal security version to boot. If the user is going to boot
> a kernel with a lower security version, a warning should show to prevent
> the user from loading a vulnerable kernel accidentally.
> 
> Enabling UEFI Secure Boot is recommended when using the security version
> or the attacker may alter the security version stealthily.
> 
> (For more details: https://github.com/lcp/shim/wiki/Security-Version)
> 
> 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: Ard Biesheuvel 
> Cc: "H. Peter Anvin" 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Joey Lee 
> Signed-off-by: Gary Lin 

I have reviewed and tested this patch. Please feel free to add:

Signed-off-by: Joey Lee 

Thanks
Joey Lee

> ---
>  arch/x86/Kconfig  | 28 
>  arch/x86/boot/header.S| 14 +-
>  arch/x86/boot/setup.ld|  1 +
>  arch/x86/boot/tools/build.c   |  1 -
>  arch/x86/include/uapi/asm/bootparam.h |  1 +
>  5 files changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 316152f72bb9..043ff86828a6 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1828,6 +1828,34 @@ config EFI_MIXED
>  
>  If unsure, say N.
>  
> +config SIGNER_NAME
> + string "Signer name"
> + default ""
> + ---help---
> +This option specifies who signs or releases this kernel.
> +
> +config DISTRO_VERSION
> + int "Distribution version"
> + default 0
> + range 0 4294967295
> + ---help---
> +   This option specifies the distribution version which this
> +   kernel belongs to.
> +
> +config SECURITY_VERSION
> + int "Security version"
> + default 0
> + range 0 65535
> + ---help---
> +The security version is the version defined by the distribution
> +to indicate the severe security fixes. The bootloader can maintain
> +a list of the security versions of the current kernels. After
> +fixing a severe vulnerability in the kernel, the distribution can
> +increase the security version to notify the bootloader to update
> +the list. When booting a kernel with a lower security version,
> +the bootloader warns the user to avoid loading a vulnerable kernel
> +accidentally.
> +
>  config SECCOMP
>   def_bool y
>   prompt "Enable seccomp to safely compute untrusted bytecode"
> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> index 2ed8f0c25def..c62e0baf2d89 100644
> --- a/arch/x86/boot/header.S
> +++ b/arch/x86/boot/header.S
> @@ -300,7 +300,7 @@ _start:
>   # Part 2 of the header, from the old setup.S
>  
>   .ascii  "HdrS"  # header signature
> - .word   0x020d  # header version number (>= 0x0105)
> + .word   0x020e  # header version number (>= 0x0105)
>   # or else old loadlin-1.5 will fail)
>   .globl realmode_swtch
>  realmode_swtch:  .word   0, 0# default_switch, SETUPSEG
> @@ -551,6 +551,7 @@ pref_address: .quad LOAD_PHYSICAL_ADDR
> # preferred load addr
>  
>  init_size:   .long INIT_SIZE # kernel initialization size
>  handover_offset: .long 0 # Filled in by build.c
> +secdata_offset:  .word secdata_start
>  
>  # End of setup header #
>  
> @@ -628,3 +629,14 @@ die:
>  setup_corrupt:
>   .byte   7

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-07-03 Thread Ard Biesheuvel
On 30 June 2017 at 23:52, joeyli  wrote:
> Hi Ard,
>
> On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
>> On 1 June 2017 at 08:11, Gary Lin  wrote:
>> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
>> >> A new section, secdata, in the setup header is introduced to store the
>> >> distro-specific security version which is designed to help the
>> >> bootloader to warn the user when loading a less secure or vulnerable
>> >> kernel. The secdata section can be presented as the following:
>> >>
>> >> struct sec_hdr {
>> >>   __u16 header_length;
>> >>   __u32 distro_version;
>> >>   __u16 security_version;
>> >> } __attribute__((packed));
>> >> char *signer;
>> >>
>> >> It consists of a fixed size structure and a null-terminated string.
>> >> "header_length" is the size of "struct sec_hdr" and can be used as the
>> >> offset to "signer". It also can be a kind of the "header version" to
>> >> detect if any new member is introduced.
>> >>
>> >> The kernel packager of the distribution can put the distro name in
>> >> "signer" and the distro version in "distro_version". When a severe
>> >> vulnerability is fixed, the packager increases "security_version" in
>> >> the kernel build afterward. The bootloader can maintain a list of the
>> >> security versions of the current kernels and only allows the kernel with
>> >> a higher or equal security version to boot. If the user is going to boot
>> >> a kernel with a lower security version, a warning should show to prevent
>> >> the user from loading a vulnerable kernel accidentally.
>> >>
>> >> Enabling UEFI Secure Boot is recommended when using the security version
>> >> or the attacker may alter the security version stealthily.
>> >>
>> > Any comment?
>> >
>>
>> This is now entirely x86-specific. My preference would be to have a
>> generic solution instead.
>>
>> --
>> Ard.
>
> On x86 platform with secure boot, UEFI boot loader (e.g. shim) keeps the
> kernel security version in boot variable for comparing to prevent replay
> attack.
>
> Will ARM platform also apply this approach? Does ARM platform have
> secure boot knob in firmware?
>

Yes, there is no reason to assume ARM differs from x86 in this
respect. Shim can be built for ARM as well as for x86.


Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-07-03 Thread Ard Biesheuvel
On 30 June 2017 at 23:52, joeyli  wrote:
> Hi Ard,
>
> On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
>> On 1 June 2017 at 08:11, Gary Lin  wrote:
>> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
>> >> A new section, secdata, in the setup header is introduced to store the
>> >> distro-specific security version which is designed to help the
>> >> bootloader to warn the user when loading a less secure or vulnerable
>> >> kernel. The secdata section can be presented as the following:
>> >>
>> >> struct sec_hdr {
>> >>   __u16 header_length;
>> >>   __u32 distro_version;
>> >>   __u16 security_version;
>> >> } __attribute__((packed));
>> >> char *signer;
>> >>
>> >> It consists of a fixed size structure and a null-terminated string.
>> >> "header_length" is the size of "struct sec_hdr" and can be used as the
>> >> offset to "signer". It also can be a kind of the "header version" to
>> >> detect if any new member is introduced.
>> >>
>> >> The kernel packager of the distribution can put the distro name in
>> >> "signer" and the distro version in "distro_version". When a severe
>> >> vulnerability is fixed, the packager increases "security_version" in
>> >> the kernel build afterward. The bootloader can maintain a list of the
>> >> security versions of the current kernels and only allows the kernel with
>> >> a higher or equal security version to boot. If the user is going to boot
>> >> a kernel with a lower security version, a warning should show to prevent
>> >> the user from loading a vulnerable kernel accidentally.
>> >>
>> >> Enabling UEFI Secure Boot is recommended when using the security version
>> >> or the attacker may alter the security version stealthily.
>> >>
>> > Any comment?
>> >
>>
>> This is now entirely x86-specific. My preference would be to have a
>> generic solution instead.
>>
>> --
>> Ard.
>
> On x86 platform with secure boot, UEFI boot loader (e.g. shim) keeps the
> kernel security version in boot variable for comparing to prevent replay
> attack.
>
> Will ARM platform also apply this approach? Does ARM platform have
> secure boot knob in firmware?
>

Yes, there is no reason to assume ARM differs from x86 in this
respect. Shim can be built for ARM as well as for x86.


Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-06-30 Thread joeyli
Hi Ard,

On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
> On 1 June 2017 at 08:11, Gary Lin  wrote:
> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> >> A new section, secdata, in the setup header is introduced to store the
> >> distro-specific security version which is designed to help the
> >> bootloader to warn the user when loading a less secure or vulnerable
> >> kernel. The secdata section can be presented as the following:
> >>
> >> struct sec_hdr {
> >>   __u16 header_length;
> >>   __u32 distro_version;
> >>   __u16 security_version;
> >> } __attribute__((packed));
> >> char *signer;
> >>
> >> It consists of a fixed size structure and a null-terminated string.
> >> "header_length" is the size of "struct sec_hdr" and can be used as the
> >> offset to "signer". It also can be a kind of the "header version" to
> >> detect if any new member is introduced.
> >>
> >> The kernel packager of the distribution can put the distro name in
> >> "signer" and the distro version in "distro_version". When a severe
> >> vulnerability is fixed, the packager increases "security_version" in
> >> the kernel build afterward. The bootloader can maintain a list of the
> >> security versions of the current kernels and only allows the kernel with
> >> a higher or equal security version to boot. If the user is going to boot
> >> a kernel with a lower security version, a warning should show to prevent
> >> the user from loading a vulnerable kernel accidentally.
> >>
> >> Enabling UEFI Secure Boot is recommended when using the security version
> >> or the attacker may alter the security version stealthily.
> >>
> > Any comment?
> >
> 
> This is now entirely x86-specific. My preference would be to have a
> generic solution instead.
> 
> -- 
> Ard.

On x86 platform with secure boot, UEFI boot loader (e.g. shim) keeps the
kernel security version in boot variable for comparing to prevent replay
attack.

Will ARM platform also apply this approach? Does ARM platform have
secure boot knob in firmware?

Thanks a lot!
Joey Lee
 
> 
> >> 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: Ard Biesheuvel 
> >> Cc: "H. Peter Anvin" 
> >> Cc: Thomas Gleixner 
> >> Cc: Ingo Molnar 
> >> Cc: Joey Lee 
> >> Signed-off-by: Gary Lin 
> >> ---
> >>  arch/x86/Kconfig  | 28 
> >>  arch/x86/boot/header.S| 14 +-
> >>  arch/x86/boot/setup.ld|  1 +
> >>  arch/x86/boot/tools/build.c   |  1 -
> >>  arch/x86/include/uapi/asm/bootparam.h |  1 +
> >>  5 files changed, 43 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> index 5bbdef151805..2c5539518ce0 100644
> >> --- a/arch/x86/Kconfig
> >> +++ b/arch/x86/Kconfig
> >> @@ -1817,6 +1817,34 @@ config EFI_MIXED
> >>
> >>  If unsure, say N.
> >>
> >> +config SIGNER_NAME
> >> + string "Signer name"
> >> + default ""
> >> + ---help---
> >> +This option specifies who signs or releases this kernel.
> >> +
> >> +config DISTRO_VERSION
> >> + int "Distribution version"
> >> + default 0
> >> + range 0 4294967295
> >> + ---help---
> >> +   This option specifies the distribution version which this
> >> +   kernel belongs to.
> >> +
> >> +config SECURITY_VERSION
> >> + int "Security version"
> >> + default 0
> >> + range 0 65535
> >> + ---help---
> >> +The security version is the version defined by the distribution
> >> +to indicate the severe security fixes. The bootloader can maintain
> >> +a list of the security versions of the current kernels. After
> >> +fixing a severe vulnerability in the kernel, the distribution can
> >> +increase the security version to notify the bootloader to update
> >> +the list. When booting a kernel with a lower security version,
> >> +the bootloader warns the user to avoid loading a vulnerable kernel
> >> +accidentally.
> >> +
> >>  config SECCOMP
> >>   def_bool y
> >>   prompt "Enable seccomp to safely compute untrusted bytecode"
> >> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> >> index 3dd5be33aaa7..37683caf1668 100644
> >> --- a/arch/x86/boot/header.S
> >> +++ b/arch/x86/boot/header.S
> >> @@ -301,7 +301,7 @@ _start:
> >>   # Part 2 of the header, from the old setup.S
> >>
> >>   .ascii  "HdrS"  # header signature
> >> - .word   0x020d

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-06-30 Thread joeyli
Hi Ard,

On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
> On 1 June 2017 at 08:11, Gary Lin  wrote:
> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> >> A new section, secdata, in the setup header is introduced to store the
> >> distro-specific security version which is designed to help the
> >> bootloader to warn the user when loading a less secure or vulnerable
> >> kernel. The secdata section can be presented as the following:
> >>
> >> struct sec_hdr {
> >>   __u16 header_length;
> >>   __u32 distro_version;
> >>   __u16 security_version;
> >> } __attribute__((packed));
> >> char *signer;
> >>
> >> It consists of a fixed size structure and a null-terminated string.
> >> "header_length" is the size of "struct sec_hdr" and can be used as the
> >> offset to "signer". It also can be a kind of the "header version" to
> >> detect if any new member is introduced.
> >>
> >> The kernel packager of the distribution can put the distro name in
> >> "signer" and the distro version in "distro_version". When a severe
> >> vulnerability is fixed, the packager increases "security_version" in
> >> the kernel build afterward. The bootloader can maintain a list of the
> >> security versions of the current kernels and only allows the kernel with
> >> a higher or equal security version to boot. If the user is going to boot
> >> a kernel with a lower security version, a warning should show to prevent
> >> the user from loading a vulnerable kernel accidentally.
> >>
> >> Enabling UEFI Secure Boot is recommended when using the security version
> >> or the attacker may alter the security version stealthily.
> >>
> > Any comment?
> >
> 
> This is now entirely x86-specific. My preference would be to have a
> generic solution instead.
> 
> -- 
> Ard.

On x86 platform with secure boot, UEFI boot loader (e.g. shim) keeps the
kernel security version in boot variable for comparing to prevent replay
attack.

Will ARM platform also apply this approach? Does ARM platform have
secure boot knob in firmware?

Thanks a lot!
Joey Lee
 
> 
> >> 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: Ard Biesheuvel 
> >> Cc: "H. Peter Anvin" 
> >> Cc: Thomas Gleixner 
> >> Cc: Ingo Molnar 
> >> Cc: Joey Lee 
> >> Signed-off-by: Gary Lin 
> >> ---
> >>  arch/x86/Kconfig  | 28 
> >>  arch/x86/boot/header.S| 14 +-
> >>  arch/x86/boot/setup.ld|  1 +
> >>  arch/x86/boot/tools/build.c   |  1 -
> >>  arch/x86/include/uapi/asm/bootparam.h |  1 +
> >>  5 files changed, 43 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> index 5bbdef151805..2c5539518ce0 100644
> >> --- a/arch/x86/Kconfig
> >> +++ b/arch/x86/Kconfig
> >> @@ -1817,6 +1817,34 @@ config EFI_MIXED
> >>
> >>  If unsure, say N.
> >>
> >> +config SIGNER_NAME
> >> + string "Signer name"
> >> + default ""
> >> + ---help---
> >> +This option specifies who signs or releases this kernel.
> >> +
> >> +config DISTRO_VERSION
> >> + int "Distribution version"
> >> + default 0
> >> + range 0 4294967295
> >> + ---help---
> >> +   This option specifies the distribution version which this
> >> +   kernel belongs to.
> >> +
> >> +config SECURITY_VERSION
> >> + int "Security version"
> >> + default 0
> >> + range 0 65535
> >> + ---help---
> >> +The security version is the version defined by the distribution
> >> +to indicate the severe security fixes. The bootloader can maintain
> >> +a list of the security versions of the current kernels. After
> >> +fixing a severe vulnerability in the kernel, the distribution can
> >> +increase the security version to notify the bootloader to update
> >> +the list. When booting a kernel with a lower security version,
> >> +the bootloader warns the user to avoid loading a vulnerable kernel
> >> +accidentally.
> >> +
> >>  config SECCOMP
> >>   def_bool y
> >>   prompt "Enable seccomp to safely compute untrusted bytecode"
> >> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> >> index 3dd5be33aaa7..37683caf1668 100644
> >> --- a/arch/x86/boot/header.S
> >> +++ b/arch/x86/boot/header.S
> >> @@ -301,7 +301,7 @@ _start:
> >>   # Part 2 of the header, from the old setup.S
> >>
> >>   .ascii  "HdrS"  # header signature
> >> - .word   0x020d  # header version number (>= 0x0105)
> >> + .word   0x020e  # header version number (>= 0x0105)
> >> 

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-06-01 Thread Gary Lin
On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
> On 1 June 2017 at 08:11, Gary Lin  wrote:
> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> >> A new section, secdata, in the setup header is introduced to store the
> >> distro-specific security version which is designed to help the
> >> bootloader to warn the user when loading a less secure or vulnerable
> >> kernel. The secdata section can be presented as the following:
> >>
> >> struct sec_hdr {
> >>   __u16 header_length;
> >>   __u32 distro_version;
> >>   __u16 security_version;
> >> } __attribute__((packed));
> >> char *signer;
> >>
> >> It consists of a fixed size structure and a null-terminated string.
> >> "header_length" is the size of "struct sec_hdr" and can be used as the
> >> offset to "signer". It also can be a kind of the "header version" to
> >> detect if any new member is introduced.
> >>
> >> The kernel packager of the distribution can put the distro name in
> >> "signer" and the distro version in "distro_version". When a severe
> >> vulnerability is fixed, the packager increases "security_version" in
> >> the kernel build afterward. The bootloader can maintain a list of the
> >> security versions of the current kernels and only allows the kernel with
> >> a higher or equal security version to boot. If the user is going to boot
> >> a kernel with a lower security version, a warning should show to prevent
> >> the user from loading a vulnerable kernel accidentally.
> >>
> >> Enabling UEFI Secure Boot is recommended when using the security version
> >> or the attacker may alter the security version stealthily.
> >>
> > Any comment?
> >
> 
> This is now entirely x86-specific. My preference would be to have a
> generic solution instead.
> 
That's why I proposed to use the PE/COFF header in the beginning, but
it's hard to clear the concern about the potential change in the PE/COFF
header. So far, I'm not aware of other generic solution to put those fields,
so I'm planning to work on x86 and arm64 separately.

Gary Lin

> -- 
> Ard.
> 
> 
> >> 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: Ard Biesheuvel 
> >> Cc: "H. Peter Anvin" 
> >> Cc: Thomas Gleixner 
> >> Cc: Ingo Molnar 
> >> Cc: Joey Lee 
> >> Signed-off-by: Gary Lin 
> >> ---
> >>  arch/x86/Kconfig  | 28 
> >>  arch/x86/boot/header.S| 14 +-
> >>  arch/x86/boot/setup.ld|  1 +
> >>  arch/x86/boot/tools/build.c   |  1 -
> >>  arch/x86/include/uapi/asm/bootparam.h |  1 +
> >>  5 files changed, 43 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> index 5bbdef151805..2c5539518ce0 100644
> >> --- a/arch/x86/Kconfig
> >> +++ b/arch/x86/Kconfig
> >> @@ -1817,6 +1817,34 @@ config EFI_MIXED
> >>
> >>  If unsure, say N.
> >>
> >> +config SIGNER_NAME
> >> + string "Signer name"
> >> + default ""
> >> + ---help---
> >> +This option specifies who signs or releases this kernel.
> >> +
> >> +config DISTRO_VERSION
> >> + int "Distribution version"
> >> + default 0
> >> + range 0 4294967295
> >> + ---help---
> >> +   This option specifies the distribution version which this
> >> +   kernel belongs to.
> >> +
> >> +config SECURITY_VERSION
> >> + int "Security version"
> >> + default 0
> >> + range 0 65535
> >> + ---help---
> >> +The security version is the version defined by the distribution
> >> +to indicate the severe security fixes. The bootloader can maintain
> >> +a list of the security versions of the current kernels. After
> >> +fixing a severe vulnerability in the kernel, the distribution can
> >> +increase the security version to notify the bootloader to update
> >> +the list. When booting a kernel with a lower security version,
> >> +the bootloader warns the user to avoid loading a vulnerable kernel
> >> +accidentally.
> >> +
> >>  config SECCOMP
> >>   def_bool y
> >>   prompt "Enable seccomp to safely compute untrusted bytecode"
> >> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> >> index 3dd5be33aaa7..37683caf1668 100644
> >> --- a/arch/x86/boot/header.S
> >> +++ b/arch/x86/boot/header.S
> >> @@ -301,7 +301,7 @@ _start:
> >>   # Part 2 of the header, from the old setup.S
> >>
> >>   .ascii  "HdrS"  # header signature
> >> - .word   0x020d 

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-06-01 Thread Gary Lin
On Thu, Jun 01, 2017 at 08:46:26AM +, Ard Biesheuvel wrote:
> On 1 June 2017 at 08:11, Gary Lin  wrote:
> > On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> >> A new section, secdata, in the setup header is introduced to store the
> >> distro-specific security version which is designed to help the
> >> bootloader to warn the user when loading a less secure or vulnerable
> >> kernel. The secdata section can be presented as the following:
> >>
> >> struct sec_hdr {
> >>   __u16 header_length;
> >>   __u32 distro_version;
> >>   __u16 security_version;
> >> } __attribute__((packed));
> >> char *signer;
> >>
> >> It consists of a fixed size structure and a null-terminated string.
> >> "header_length" is the size of "struct sec_hdr" and can be used as the
> >> offset to "signer". It also can be a kind of the "header version" to
> >> detect if any new member is introduced.
> >>
> >> The kernel packager of the distribution can put the distro name in
> >> "signer" and the distro version in "distro_version". When a severe
> >> vulnerability is fixed, the packager increases "security_version" in
> >> the kernel build afterward. The bootloader can maintain a list of the
> >> security versions of the current kernels and only allows the kernel with
> >> a higher or equal security version to boot. If the user is going to boot
> >> a kernel with a lower security version, a warning should show to prevent
> >> the user from loading a vulnerable kernel accidentally.
> >>
> >> Enabling UEFI Secure Boot is recommended when using the security version
> >> or the attacker may alter the security version stealthily.
> >>
> > Any comment?
> >
> 
> This is now entirely x86-specific. My preference would be to have a
> generic solution instead.
> 
That's why I proposed to use the PE/COFF header in the beginning, but
it's hard to clear the concern about the potential change in the PE/COFF
header. So far, I'm not aware of other generic solution to put those fields,
so I'm planning to work on x86 and arm64 separately.

Gary Lin

> -- 
> Ard.
> 
> 
> >> 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: Ard Biesheuvel 
> >> Cc: "H. Peter Anvin" 
> >> Cc: Thomas Gleixner 
> >> Cc: Ingo Molnar 
> >> Cc: Joey Lee 
> >> Signed-off-by: Gary Lin 
> >> ---
> >>  arch/x86/Kconfig  | 28 
> >>  arch/x86/boot/header.S| 14 +-
> >>  arch/x86/boot/setup.ld|  1 +
> >>  arch/x86/boot/tools/build.c   |  1 -
> >>  arch/x86/include/uapi/asm/bootparam.h |  1 +
> >>  5 files changed, 43 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> index 5bbdef151805..2c5539518ce0 100644
> >> --- a/arch/x86/Kconfig
> >> +++ b/arch/x86/Kconfig
> >> @@ -1817,6 +1817,34 @@ config EFI_MIXED
> >>
> >>  If unsure, say N.
> >>
> >> +config SIGNER_NAME
> >> + string "Signer name"
> >> + default ""
> >> + ---help---
> >> +This option specifies who signs or releases this kernel.
> >> +
> >> +config DISTRO_VERSION
> >> + int "Distribution version"
> >> + default 0
> >> + range 0 4294967295
> >> + ---help---
> >> +   This option specifies the distribution version which this
> >> +   kernel belongs to.
> >> +
> >> +config SECURITY_VERSION
> >> + int "Security version"
> >> + default 0
> >> + range 0 65535
> >> + ---help---
> >> +The security version is the version defined by the distribution
> >> +to indicate the severe security fixes. The bootloader can maintain
> >> +a list of the security versions of the current kernels. After
> >> +fixing a severe vulnerability in the kernel, the distribution can
> >> +increase the security version to notify the bootloader to update
> >> +the list. When booting a kernel with a lower security version,
> >> +the bootloader warns the user to avoid loading a vulnerable kernel
> >> +accidentally.
> >> +
> >>  config SECCOMP
> >>   def_bool y
> >>   prompt "Enable seccomp to safely compute untrusted bytecode"
> >> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> >> index 3dd5be33aaa7..37683caf1668 100644
> >> --- a/arch/x86/boot/header.S
> >> +++ b/arch/x86/boot/header.S
> >> @@ -301,7 +301,7 @@ _start:
> >>   # Part 2 of the header, from the old setup.S
> >>
> >>   .ascii  "HdrS"  # header signature
> >> - .word   0x020d  # header version number (>= 0x0105)
> >> + .word   0x020e  # header version number (>= 0x0105)
> >>  

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-06-01 Thread Ard Biesheuvel
On 1 June 2017 at 08:11, Gary Lin  wrote:
> On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
>> A new section, secdata, in the setup header is introduced to store the
>> distro-specific security version which is designed to help the
>> bootloader to warn the user when loading a less secure or vulnerable
>> kernel. The secdata section can be presented as the following:
>>
>> struct sec_hdr {
>>   __u16 header_length;
>>   __u32 distro_version;
>>   __u16 security_version;
>> } __attribute__((packed));
>> char *signer;
>>
>> It consists of a fixed size structure and a null-terminated string.
>> "header_length" is the size of "struct sec_hdr" and can be used as the
>> offset to "signer". It also can be a kind of the "header version" to
>> detect if any new member is introduced.
>>
>> The kernel packager of the distribution can put the distro name in
>> "signer" and the distro version in "distro_version". When a severe
>> vulnerability is fixed, the packager increases "security_version" in
>> the kernel build afterward. The bootloader can maintain a list of the
>> security versions of the current kernels and only allows the kernel with
>> a higher or equal security version to boot. If the user is going to boot
>> a kernel with a lower security version, a warning should show to prevent
>> the user from loading a vulnerable kernel accidentally.
>>
>> Enabling UEFI Secure Boot is recommended when using the security version
>> or the attacker may alter the security version stealthily.
>>
> Any comment?
>

This is now entirely x86-specific. My preference would be to have a
generic solution instead.

-- 
Ard.


>> 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: Ard Biesheuvel 
>> Cc: "H. Peter Anvin" 
>> Cc: Thomas Gleixner 
>> Cc: Ingo Molnar 
>> Cc: Joey Lee 
>> Signed-off-by: Gary Lin 
>> ---
>>  arch/x86/Kconfig  | 28 
>>  arch/x86/boot/header.S| 14 +-
>>  arch/x86/boot/setup.ld|  1 +
>>  arch/x86/boot/tools/build.c   |  1 -
>>  arch/x86/include/uapi/asm/bootparam.h |  1 +
>>  5 files changed, 43 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 5bbdef151805..2c5539518ce0 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1817,6 +1817,34 @@ config EFI_MIXED
>>
>>  If unsure, say N.
>>
>> +config SIGNER_NAME
>> + string "Signer name"
>> + default ""
>> + ---help---
>> +This option specifies who signs or releases this kernel.
>> +
>> +config DISTRO_VERSION
>> + int "Distribution version"
>> + default 0
>> + range 0 4294967295
>> + ---help---
>> +   This option specifies the distribution version which this
>> +   kernel belongs to.
>> +
>> +config SECURITY_VERSION
>> + int "Security version"
>> + default 0
>> + range 0 65535
>> + ---help---
>> +The security version is the version defined by the distribution
>> +to indicate the severe security fixes. The bootloader can maintain
>> +a list of the security versions of the current kernels. After
>> +fixing a severe vulnerability in the kernel, the distribution can
>> +increase the security version to notify the bootloader to update
>> +the list. When booting a kernel with a lower security version,
>> +the bootloader warns the user to avoid loading a vulnerable kernel
>> +accidentally.
>> +
>>  config SECCOMP
>>   def_bool y
>>   prompt "Enable seccomp to safely compute untrusted bytecode"
>> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
>> index 3dd5be33aaa7..37683caf1668 100644
>> --- a/arch/x86/boot/header.S
>> +++ b/arch/x86/boot/header.S
>> @@ -301,7 +301,7 @@ _start:
>>   # Part 2 of the header, from the old setup.S
>>
>>   .ascii  "HdrS"  # header signature
>> - .word   0x020d  # header version number (>= 0x0105)
>> + .word   0x020e  # header version number (>= 0x0105)
>>   # or else old loadlin-1.5 will fail)
>>   .globl realmode_swtch
>>  realmode_swtch:  .word   0, 0# default_switch, SETUPSEG
>> @@ -552,6 +552,7 @@ pref_address: .quad LOAD_PHYSICAL_ADDR   
>>  # preferred load addr
>>
>>  init_size:   .long INIT_SIZE # kernel initialization size
>>  handover_offset: .long 0 # Filled in by build.c
>> 

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-06-01 Thread Ard Biesheuvel
On 1 June 2017 at 08:11, Gary Lin  wrote:
> On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
>> A new section, secdata, in the setup header is introduced to store the
>> distro-specific security version which is designed to help the
>> bootloader to warn the user when loading a less secure or vulnerable
>> kernel. The secdata section can be presented as the following:
>>
>> struct sec_hdr {
>>   __u16 header_length;
>>   __u32 distro_version;
>>   __u16 security_version;
>> } __attribute__((packed));
>> char *signer;
>>
>> It consists of a fixed size structure and a null-terminated string.
>> "header_length" is the size of "struct sec_hdr" and can be used as the
>> offset to "signer". It also can be a kind of the "header version" to
>> detect if any new member is introduced.
>>
>> The kernel packager of the distribution can put the distro name in
>> "signer" and the distro version in "distro_version". When a severe
>> vulnerability is fixed, the packager increases "security_version" in
>> the kernel build afterward. The bootloader can maintain a list of the
>> security versions of the current kernels and only allows the kernel with
>> a higher or equal security version to boot. If the user is going to boot
>> a kernel with a lower security version, a warning should show to prevent
>> the user from loading a vulnerable kernel accidentally.
>>
>> Enabling UEFI Secure Boot is recommended when using the security version
>> or the attacker may alter the security version stealthily.
>>
> Any comment?
>

This is now entirely x86-specific. My preference would be to have a
generic solution instead.

-- 
Ard.


>> 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: Ard Biesheuvel 
>> Cc: "H. Peter Anvin" 
>> Cc: Thomas Gleixner 
>> Cc: Ingo Molnar 
>> Cc: Joey Lee 
>> Signed-off-by: Gary Lin 
>> ---
>>  arch/x86/Kconfig  | 28 
>>  arch/x86/boot/header.S| 14 +-
>>  arch/x86/boot/setup.ld|  1 +
>>  arch/x86/boot/tools/build.c   |  1 -
>>  arch/x86/include/uapi/asm/bootparam.h |  1 +
>>  5 files changed, 43 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 5bbdef151805..2c5539518ce0 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1817,6 +1817,34 @@ config EFI_MIXED
>>
>>  If unsure, say N.
>>
>> +config SIGNER_NAME
>> + string "Signer name"
>> + default ""
>> + ---help---
>> +This option specifies who signs or releases this kernel.
>> +
>> +config DISTRO_VERSION
>> + int "Distribution version"
>> + default 0
>> + range 0 4294967295
>> + ---help---
>> +   This option specifies the distribution version which this
>> +   kernel belongs to.
>> +
>> +config SECURITY_VERSION
>> + int "Security version"
>> + default 0
>> + range 0 65535
>> + ---help---
>> +The security version is the version defined by the distribution
>> +to indicate the severe security fixes. The bootloader can maintain
>> +a list of the security versions of the current kernels. After
>> +fixing a severe vulnerability in the kernel, the distribution can
>> +increase the security version to notify the bootloader to update
>> +the list. When booting a kernel with a lower security version,
>> +the bootloader warns the user to avoid loading a vulnerable kernel
>> +accidentally.
>> +
>>  config SECCOMP
>>   def_bool y
>>   prompt "Enable seccomp to safely compute untrusted bytecode"
>> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
>> index 3dd5be33aaa7..37683caf1668 100644
>> --- a/arch/x86/boot/header.S
>> +++ b/arch/x86/boot/header.S
>> @@ -301,7 +301,7 @@ _start:
>>   # Part 2 of the header, from the old setup.S
>>
>>   .ascii  "HdrS"  # header signature
>> - .word   0x020d  # header version number (>= 0x0105)
>> + .word   0x020e  # header version number (>= 0x0105)
>>   # or else old loadlin-1.5 will fail)
>>   .globl realmode_swtch
>>  realmode_swtch:  .word   0, 0# default_switch, SETUPSEG
>> @@ -552,6 +552,7 @@ pref_address: .quad LOAD_PHYSICAL_ADDR   
>>  # preferred load addr
>>
>>  init_size:   .long INIT_SIZE # kernel initialization size
>>  handover_offset: .long 0 # Filled in by build.c
>> +secdata_offset:  .word secdata_start
>>
>>  # End of setup header 

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-06-01 Thread Gary Lin
On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> A new section, secdata, in the setup header is introduced to store the
> distro-specific security version which is designed to help the
> bootloader to warn the user when loading a less secure or vulnerable
> kernel. The secdata section can be presented as the following:
> 
> struct sec_hdr {
>   __u16 header_length;
>   __u32 distro_version;
>   __u16 security_version;
> } __attribute__((packed));
> char *signer;
> 
> It consists of a fixed size structure and a null-terminated string.
> "header_length" is the size of "struct sec_hdr" and can be used as the
> offset to "signer". It also can be a kind of the "header version" to
> detect if any new member is introduced.
> 
> The kernel packager of the distribution can put the distro name in
> "signer" and the distro version in "distro_version". When a severe
> vulnerability is fixed, the packager increases "security_version" in
> the kernel build afterward. The bootloader can maintain a list of the
> security versions of the current kernels and only allows the kernel with
> a higher or equal security version to boot. If the user is going to boot
> a kernel with a lower security version, a warning should show to prevent
> the user from loading a vulnerable kernel accidentally.
> 
> Enabling UEFI Secure Boot is recommended when using the security version
> or the attacker may alter the security version stealthily.
> 
Any comment?

Gary Lin

> 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: Ard Biesheuvel 
> Cc: "H. Peter Anvin" 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Joey Lee 
> Signed-off-by: Gary Lin 
> ---
>  arch/x86/Kconfig  | 28 
>  arch/x86/boot/header.S| 14 +-
>  arch/x86/boot/setup.ld|  1 +
>  arch/x86/boot/tools/build.c   |  1 -
>  arch/x86/include/uapi/asm/bootparam.h |  1 +
>  5 files changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 5bbdef151805..2c5539518ce0 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1817,6 +1817,34 @@ config EFI_MIXED
>  
>  If unsure, say N.
>  
> +config SIGNER_NAME
> + string "Signer name"
> + default ""
> + ---help---
> +This option specifies who signs or releases this kernel.
> +
> +config DISTRO_VERSION
> + int "Distribution version"
> + default 0
> + range 0 4294967295
> + ---help---
> +   This option specifies the distribution version which this
> +   kernel belongs to.
> +
> +config SECURITY_VERSION
> + int "Security version"
> + default 0
> + range 0 65535
> + ---help---
> +The security version is the version defined by the distribution
> +to indicate the severe security fixes. The bootloader can maintain
> +a list of the security versions of the current kernels. After
> +fixing a severe vulnerability in the kernel, the distribution can
> +increase the security version to notify the bootloader to update
> +the list. When booting a kernel with a lower security version,
> +the bootloader warns the user to avoid loading a vulnerable kernel
> +accidentally.
> +
>  config SECCOMP
>   def_bool y
>   prompt "Enable seccomp to safely compute untrusted bytecode"
> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> index 3dd5be33aaa7..37683caf1668 100644
> --- a/arch/x86/boot/header.S
> +++ b/arch/x86/boot/header.S
> @@ -301,7 +301,7 @@ _start:
>   # Part 2 of the header, from the old setup.S
>  
>   .ascii  "HdrS"  # header signature
> - .word   0x020d  # header version number (>= 0x0105)
> + .word   0x020e  # header version number (>= 0x0105)
>   # or else old loadlin-1.5 will fail)
>   .globl realmode_swtch
>  realmode_swtch:  .word   0, 0# default_switch, SETUPSEG
> @@ -552,6 +552,7 @@ pref_address: .quad LOAD_PHYSICAL_ADDR
> # preferred load addr
>  
>  init_size:   .long INIT_SIZE # kernel initialization size
>  handover_offset: .long 0 # Filled in by build.c
> +secdata_offset:  .word secdata_start
>  
>  # End of setup header #
>  
> @@ -629,3 +630,14 @@ die:
>  setup_corrupt:
>   .byte   7
>   .string "No setup signature found...\n"
> +
> 

Re: [RFC v2 PATCH] x86/boot: Add the secdata section to the setup header

2017-06-01 Thread Gary Lin
On Fri, May 12, 2017 at 04:05:34PM +0800, Gary Lin wrote:
> A new section, secdata, in the setup header is introduced to store the
> distro-specific security version which is designed to help the
> bootloader to warn the user when loading a less secure or vulnerable
> kernel. The secdata section can be presented as the following:
> 
> struct sec_hdr {
>   __u16 header_length;
>   __u32 distro_version;
>   __u16 security_version;
> } __attribute__((packed));
> char *signer;
> 
> It consists of a fixed size structure and a null-terminated string.
> "header_length" is the size of "struct sec_hdr" and can be used as the
> offset to "signer". It also can be a kind of the "header version" to
> detect if any new member is introduced.
> 
> The kernel packager of the distribution can put the distro name in
> "signer" and the distro version in "distro_version". When a severe
> vulnerability is fixed, the packager increases "security_version" in
> the kernel build afterward. The bootloader can maintain a list of the
> security versions of the current kernels and only allows the kernel with
> a higher or equal security version to boot. If the user is going to boot
> a kernel with a lower security version, a warning should show to prevent
> the user from loading a vulnerable kernel accidentally.
> 
> Enabling UEFI Secure Boot is recommended when using the security version
> or the attacker may alter the security version stealthily.
> 
Any comment?

Gary Lin

> 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: Ard Biesheuvel 
> Cc: "H. Peter Anvin" 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Joey Lee 
> Signed-off-by: Gary Lin 
> ---
>  arch/x86/Kconfig  | 28 
>  arch/x86/boot/header.S| 14 +-
>  arch/x86/boot/setup.ld|  1 +
>  arch/x86/boot/tools/build.c   |  1 -
>  arch/x86/include/uapi/asm/bootparam.h |  1 +
>  5 files changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 5bbdef151805..2c5539518ce0 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1817,6 +1817,34 @@ config EFI_MIXED
>  
>  If unsure, say N.
>  
> +config SIGNER_NAME
> + string "Signer name"
> + default ""
> + ---help---
> +This option specifies who signs or releases this kernel.
> +
> +config DISTRO_VERSION
> + int "Distribution version"
> + default 0
> + range 0 4294967295
> + ---help---
> +   This option specifies the distribution version which this
> +   kernel belongs to.
> +
> +config SECURITY_VERSION
> + int "Security version"
> + default 0
> + range 0 65535
> + ---help---
> +The security version is the version defined by the distribution
> +to indicate the severe security fixes. The bootloader can maintain
> +a list of the security versions of the current kernels. After
> +fixing a severe vulnerability in the kernel, the distribution can
> +increase the security version to notify the bootloader to update
> +the list. When booting a kernel with a lower security version,
> +the bootloader warns the user to avoid loading a vulnerable kernel
> +accidentally.
> +
>  config SECCOMP
>   def_bool y
>   prompt "Enable seccomp to safely compute untrusted bytecode"
> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> index 3dd5be33aaa7..37683caf1668 100644
> --- a/arch/x86/boot/header.S
> +++ b/arch/x86/boot/header.S
> @@ -301,7 +301,7 @@ _start:
>   # Part 2 of the header, from the old setup.S
>  
>   .ascii  "HdrS"  # header signature
> - .word   0x020d  # header version number (>= 0x0105)
> + .word   0x020e  # header version number (>= 0x0105)
>   # or else old loadlin-1.5 will fail)
>   .globl realmode_swtch
>  realmode_swtch:  .word   0, 0# default_switch, SETUPSEG
> @@ -552,6 +552,7 @@ pref_address: .quad LOAD_PHYSICAL_ADDR
> # preferred load addr
>  
>  init_size:   .long INIT_SIZE # kernel initialization size
>  handover_offset: .long 0 # Filled in by build.c
> +secdata_offset:  .word secdata_start
>  
>  # End of setup header #
>  
> @@ -629,3 +630,14 @@ die:
>  setup_corrupt:
>   .byte   7
>   .string "No setup signature found...\n"
> +
> + .section ".secdata", "a"
> +secdata_start:
> +header_length:
> + .word   signer - secdata_start
>