Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #54741 > unrolled thread

Bug#831827: linux: arm64 support for securelevel and Secure Boot

Started byLinn Crosetto <linn@hpe.com>
First post2016-07-20 00:40 +0200
Last post2016-08-27 23:40 +0200
Articles 8 — 3 participants

Back to article view | Back to linux.debian.kernel

Contents

  Bug#831827: linux: arm64 support for securelevel and Secure Boot Linn Crosetto <linn@hpe.com> - 2016-07-20 00:40 +0200
    Bug#831827: linux: arm64 support for securelevel and Secure Boot Ben Hutchings <ben@decadent.org.uk> - 2016-08-27 23:30 +0200
      Bug#831827: linux: arm64 support for securelevel and Secure Boot Linn Crosetto <linn@hpe.com> - 2016-08-29 22:40 +0200
        Bug#831827: linux: arm64 support for securelevel and Secure Boot Linn Crosetto <linn@hpe.com> - 2016-08-30 20:20 +0200
          Bug#831827: linux: arm64 support for securelevel and Secure Boot Ben Hutchings <ben@decadent.org.uk> - 2016-09-04 03:30 +0200
    Processed: Re: Bug#831827: linux: arm64 support for securelevel  and Secure Boot owner@bugs.debian.org (Debian Bug Tracking System) - 2016-08-27 23:30 +0200
    Processed: Re: Bug#831827: linux: arm64 support for securelevel  and Secure Boot owner@bugs.debian.org (Debian Bug Tracking System) - 2016-08-27 23:40 +0200
    Bug#831827: linux: arm64 support for securelevel and Secure Boot Ben Hutchings <ben@decadent.org.uk> - 2016-08-27 23:40 +0200

#54741 — Bug#831827: linux: arm64 support for securelevel and Secure Boot

FromLinn Crosetto <linn@hpe.com>
Date2016-07-20 00:40 +0200
SubjectBug#831827: linux: arm64 support for securelevel and Secure Boot
Message-ID<rWLQd-1rn-9@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Package: linux
Version: 4.7~rc7-1~exp1
Severity: normal
Tags: patch

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Support for securelevel on amd64 was added in Bug#820008. Additional changes
are needed to enable securelevel on arm64 when UEFI Secure Boot is enabled.

I have included two patches implementing adding this support. 

The current version of qemu-efi in Stretch is enabled to test with Secure
Boot. Instructions for enabling persistent UEFI variables with QEMU:
https://wiki.linaro.org/LEG/UEFIforQEMU

If testing with a certificate of significant size, the patch referenced in
Bug#830488 is needed.

Thanks.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXjqtNAAoJEF/3aG7d/FTWsskP/0x1k/i4vA9GVmreQI8oHfXx
q0w7LHvoGODb9Dsa0lQrejqrFLpWh6hh7yoOJ+xkrAqYqGG+apXaXvUN+HQmGUk6
n4sSkZERLiUMoJnEqzUG6BorUnuYXWLLuC4iLLzqBt2DeQtvqWAxw6pt5SBcrCqG
6Jw+3ntEhvCci76H9WrFMVjYN/JiM8Cv/2MUuMf8tNkaYAzWhGrFIdQL9JhHBrTU
dSdLJyEdUA5KIMvNdsg+R69gKDipXFNHPKjEmE8QYjneih0Y+9+25se1LeKDOB8l
xW6mbxNgPCOVU7ABvyTEHoi1eMi/SOuNx+a6OH+Vn9wRadbjGpjN5sYSgwFJidkG
5u48rU9AES+8MiapQguF0c+w6gmLXWLSZ6doyZ3NQlGORwJvwarPZgnkMWyRvoiJ
zsBdbSBJeCY4maqFnUX67MLKzv1oWGTklHh0wtFqLyLZrvLRfcsvU9xnkEeObgIH
++Xx5ov59LWzU7QYXwZ5k9szj0hmDoZfPMEEtK/wyH77j6kI3t43Eor+0ccZLUBc
wddDZDeV5foGE4Eb+/me4sVVW469GOlOCN0IR876SxprU/A5bQZILiPRLH0/W1g2
rFyutwMQbtBANibpfeh1+v91meOkoXvTQt486d+BFvnVUqatSVIIlklaUGnO8K8x
ssbcjVywf6ZhvkN+3vU+
=C/wf
-----END PGP SIGNATURE-----

[toc] | [next] | [standalone]

#54942

FromBen Hutchings <ben@decadent.org.uk>
Date2016-08-27 23:30 +0200
Message-ID<saTkR-1fy-5@gated-at.bofh.it>
In reply to#54741

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 pending

Applied, but:

> 
> --- a/drivers/firmware/efi/libstub/fdt.c
> +++ b/drivers/firmware/efi/libstub/fdt.c
> @@ -139,6 +139,13 @@ efi_status_t update_fdt(efi_system_table_t
> *sys_table, void *orig_fdt,
>  			return efi_status;
>  		}
>  	}
> +
> +	fdt_val32 = efi_get_secureboot(sys_table);

Shouldn't there be a cpu_to_fdt32() conversion here?

> 
> +	status = fdt_setprop(fdt, node, "linux,uefi-secure-boot",
> +			     &amp;fdt_val32, sizeof(fdt_val32));
> +	if (status)
> +		goto fdt_set_fail;
> +
>  	return EFI_SUCCESS;
>  
>  fdt_set_fail:

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought.
... I realized that a large part of my life from then on was going to
be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949
-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought.
... I realized that a large part of my life from then on was going to
be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949

[toc] | [prev] | [next] | [standalone]

#54961

FromLinn Crosetto <linn@hpe.com>
Date2016-08-29 22:40 +0200
Message-ID<sbBvz-3DB-9@gated-at.bofh.it>
In reply to#54942

[Multipart message — attachments visible in raw view] — view raw

On Sat, Aug 27, 2016 at 10:22:52PM +0100, Ben Hutchings wrote:
> Control: tag -1 pending
> 
> Applied, but:
> 
> > 
> > --- a/drivers/firmware/efi/libstub/fdt.c
> > +++ b/drivers/firmware/efi/libstub/fdt.c
> > @@ -139,6 +139,13 @@ efi_status_t update_fdt(efi_system_table_t
> > *sys_table, void *orig_fdt,
> >  			return efi_status;
> >  		}
> >  	}
> > +
> > +	fdt_val32 = efi_get_secureboot(sys_table);
> 
> Shouldn't there be a cpu_to_fdt32() conversion here?

Yes. When setting securelevel the check to see if secure_boot is
greater-than-zero behaves the same, but it should be byte-swapped to preserve
the value returned by efi_get_secureboot(). I tested and validated the
following change:

@@ -140,7 +140,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
                }
        }
 
-       fdt_val32 = efi_get_secureboot(sys_table);
+       fdt_val32 = cpu_to_fdt32(efi_get_secureboot(sys_table));
        status = fdt_setprop(fdt, node, "linux,uefi-secure-boot",
                             &fdt_val32, sizeof(fdt_val32));
        if (status)

[toc] | [prev] | [next] | [standalone]

#54970

FromLinn Crosetto <linn@hpe.com>
Date2016-08-30 20:20 +0200
Message-ID<sbVND-8n7-1@gated-at.bofh.it>
In reply to#54961

[Multipart message — attachments visible in raw view] — view raw

On Mon, Aug 29, 2016 at 01:30:44PM -0700, Linn Crosetto wrote:
> On Sat, Aug 27, 2016 at 10:22:52PM +0100, Ben Hutchings wrote:
> > Control: tag -1 pending
> > 
> > Applied, but:
> > 
> > > 
> > > --- a/drivers/firmware/efi/libstub/fdt.c
> > > +++ b/drivers/firmware/efi/libstub/fdt.c
> > > @@ -139,6 +139,13 @@ efi_status_t update_fdt(efi_system_table_t
> > > *sys_table, void *orig_fdt,
> > >  			return efi_status;
> > >  		}
> > >  	}
> > > +
> > > +	fdt_val32 = efi_get_secureboot(sys_table);
> > 
> > Shouldn't there be a cpu_to_fdt32() conversion here?
> 
> Yes. When setting securelevel the check to see if secure_boot is
> greater-than-zero behaves the same, but it should be byte-swapped to preserve
> the value returned by efi_get_secureboot(). I tested and validated the
> following change:
> 
> @@ -140,7 +140,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
>                 }
>         }
>  
> -       fdt_val32 = efi_get_secureboot(sys_table);
> +       fdt_val32 = cpu_to_fdt32(efi_get_secureboot(sys_table));
>         status = fdt_setprop(fdt, node, "linux,uefi-secure-boot",
>                              &fdt_val32, sizeof(fdt_val32));
>         if (status)

Attaching version 2 of the patches with the change.

[toc] | [prev] | [next] | [standalone]

#55012

FromBen Hutchings <ben@decadent.org.uk>
Date2016-09-04 03:30 +0200
Message-ID<sdupX-4nR-1@gated-at.bofh.it>
In reply to#54970

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2016-08-30 at 11:15 -0700, Linn Crosetto wrote:
> On Mon, Aug 29, 2016 at 01:30:44PM -0700, Linn Crosetto wrote:
> > 
> > On Sat, Aug 27, 2016 at 10:22:52PM +0100, Ben Hutchings wrote:
> > > 
> > > Control: tag -1 pending
> > > 
> > > Applied, but:
> > > 
> > > > 
> > > > 
> > > > --- a/drivers/firmware/efi/libstub/fdt.c
> > > > +++ b/drivers/firmware/efi/libstub/fdt.c
> > > > @@ -139,6 +139,13 @@ efi_status_t update_fdt(efi_system_table_t
> > > > *sys_table, void *orig_fdt,
> > > >  			return efi_status;
> > > >  		}
> > > >  	}
> > > > +
> > > > +	fdt_val32 = efi_get_secureboot(sys_table);
> > > 
> > > Shouldn't there be a cpu_to_fdt32() conversion here?
> > 
> > Yes. When setting securelevel the check to see if secure_boot is
> > greater-than-zero behaves the same, but it should be byte-swapped
> > to preserve
> > the value returned by efi_get_secureboot(). I tested and validated
> > the
> > following change:
> > 
> > @@ -140,7 +140,7 @@ efi_status_t update_fdt(efi_system_table_t
> > *sys_table, void *orig_fdt,
> >                 }
> >         }
> >  
> > -       fdt_val32 = efi_get_secureboot(sys_table);
> > +       fdt_val32 = cpu_to_fdt32(efi_get_secureboot(sys_table));
> >         status = fdt_setprop(fdt, node, "linux,uefi-secure-boot",
> >                              &fdt_val32, sizeof(fdt_val32));
> >         if (status)
> 
> Attaching version 2 of the patches with the change.

This change is pending for the next unstable upload.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[toc] | [prev] | [next] | [standalone]

#54943 — Processed: Re: Bug#831827: linux: arm64 support for securelevel and Secure Boot

Fromowner@bugs.debian.org (Debian Bug Tracking System)
Date2016-08-27 23:30 +0200
SubjectProcessed: Re: Bug#831827: linux: arm64 support for securelevel and Secure Boot
Message-ID<saTkS-1fy-7@gated-at.bofh.it>
In reply to#54741
Processing control commands:

> tag -1 pending
Bug #831827 [linux] linux: arm64 support for securelevel and Secure Boot
Added tag(s) pending.

-- 
831827: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831827
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#54944 — Processed: Re: Bug#831827: linux: arm64 support for securelevel and Secure Boot

Fromowner@bugs.debian.org (Debian Bug Tracking System)
Date2016-08-27 23:40 +0200
SubjectProcessed: Re: Bug#831827: linux: arm64 support for securelevel and Secure Boot
Message-ID<saTux-1iW-3@gated-at.bofh.it>
In reply to#54741
Processing control commands:

> tag -1 pending
Bug #831827 [linux] linux: arm64 support for securelevel and Secure Boot
Ignoring request to alter tags of bug #831827 to the same tags previously set

-- 
831827: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831827
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#54945

FromBen Hutchings <ben@decadent.org.uk>
Date2016-08-27 23:40 +0200
Message-ID<saTux-1iW-5@gated-at.bofh.it>
In reply to#54741

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 pending

Applied, but:

> --- a/drivers/firmware/efi/libstub/fdt.c
> +++ b/drivers/firmware/efi/libstub/fdt.c
> @@ -139,6 +139,13 @@ efi_status_t update_fdt(efi_system_table_t
> *sys_table, void *orig_fdt,
>  			return efi_status;
>  		}
>  	}
> +
> +	fdt_val32 = efi_get_secureboot(sys_table);

Shouldn't there be a cpu_to_fdt32() conversion here?

> +	status = fdt_setprop(fdt, node, "linux,uefi-secure-boot",
> +			     &amp;fdt_val32, sizeof(fdt_val32));
> +	if (status)
> +		goto fdt_set_fail;
> +
>  	return EFI_SUCCESS;
>  
>  fdt_set_fail:

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought.
... I realized that a large part of my life from then on was going to
be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web