On Sat, 14 Aug 2021 at 00:39, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > Am 13. August 2021 22:22:49 MESZ schrieb Daniel Kiper <dki...@net-space.pl>: > >On Fri, Aug 13, 2021 at 06:22:49PM +0200, Heinrich Schuchardt wrote: > >> On 8/2/21 5:18 PM, Daniel Kiper wrote: > >> > Hi Heinrich, > >> > > >> > On Mon, Aug 02, 2021 at 03:00:55PM +0200, Heinrich Schuchardt wrote: > >> > > Hello Daniel, > >> > > > >> > > I sent this series when you were in the middle of getting GRUB-2.06 > >> > > out. > >> > > Unfortunately I did not see any feedback yet. Could you, please, share > >> > > your > >> > > thoughts. > >> > > >> > Sure, I will try to do that next week. > >> > > >> > Daniel > >> > > >> > >> The series conflicts with the RISC-V series patch > >> "linux: ignore FDT unless we need to modify it" > >> https://lists.gnu.org/archive/html/grub-devel/2021-06/msg00010.html > >> > >> My priority would be to have the RISC-V series merged first. Then I can > >> rebase my series upon it. > > > >OK... > > > >> But anyhow feedback for the concept of devicetree fixups will be helpful. > > > >At first sight it looks good to me. Though it would be nice if somebody > >more familiar with DT than I would check the patches too. Leif? > > > >Heinrich, are you aware that devicetree command is disabled when UEFI > >Secure Boot is enabled? I think you should take into account that > >somehow in the next version of the patches. > > I wonder why the devicetree command is disabled while the initrd command is > not. For an attacker the initrd is much more attractive. >
The initrd is user space, whereas the DT affects the internal plumbing of the kernel. > For both the initrd and the dt it would be good to introduce signatures. > How the kernel authenticates the initrd is out of scope for secure boot. > A devicetree before fixups is invariant and could be signed together with the > kernel and checked against shims certificate database. > > Best regards > > Heinrich > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
