On Tue, Dec 1, 2015 at 7:30 PM, Steve Langasek
<email address hidden> wrote:
> This change is self-evidently correct, but is there a bug task somewhere
> for MAAS to not generate kitchen-sink .efi images that are exercising
> non-default configurations?
Not specifically. We've submitted hacks to MAAS to exclude "bad"
modules temporarily in the past - it currently omits setjmp & progress
on arm64.
> This seems like something that we should
> abstract at a different layer. E.g., we already have to build grub
> netboot images in both d-i and grub2 (the grub2 ones in order to get
> EFI-signed netboot images). It seems preferable for MAAS to be able to
> use a "stock" netboot image config provided by grub2 instead.
Agreed. Ultimately I'd like to see MAAS boot resources provide these
images via signed simplestream metadata, like it does for other boot
files/images.
> Longer term, this may be by virtue of MAAS using EFI-signed images for
> arm64, the way it does already on x86_64. So maybe that's the solution
> here.
It solves part of the problem, but it'd actually make things more
insecure today (LP: #1457982).
On Tue, Dec 1, 2015 at 7:30 PM, Steve Langasek
<email address hidden> wrote:
> This change is self-evidently correct, but is there a bug task somewhere
> for MAAS to not generate kitchen-sink .efi images that are exercising
> non-default configurations?
Not specifically. We've submitted hacks to MAAS to exclude "bad"
modules temporarily in the past - it currently omits setjmp & progress
on arm64.
> This seems like something that we should
> abstract at a different layer. E.g., we already have to build grub
> netboot images in both d-i and grub2 (the grub2 ones in order to get
> EFI-signed netboot images). It seems preferable for MAAS to be able to
> use a "stock" netboot image config provided by grub2 instead.
Agreed. Ultimately I'd like to see MAAS boot resources provide these
images via signed simplestream metadata, like it does for other boot
files/images.
> Longer term, this may be by virtue of MAAS using EFI-signed images for
> arm64, the way it does already on x86_64. So maybe that's the solution
> here.
It solves part of the problem, but it'd actually make things more
insecure today (LP: #1457982).
-dann