linux-kernel - Re: [PATCH v6 04/14] x86: Secure Launch Resource Table header file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 12 May 2023 11:55:54 +0100
From:   Matthew Garrett <mjg59@...f.ucam.org>
To:     Ross Philipson <ross.philipson@...cle.com>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-integrity@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-crypto@...r.kernel.org, iommu@...ts.linux-foundation.org,
        kexec@...ts.infradead.org, linux-efi@...r.kernel.org,
        dpsmith@...rtussolutions.com, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, hpa@...or.com, ardb@...nel.org,
        James.Bottomley@...senpartnership.com, luto@...capital.net,
        nivedita@...m.mit.edu, kanth.ghatraju@...cle.com,
        trenchboot-devel@...glegroups.com
Subject: Re: [PATCH v6 04/14] x86: Secure Launch Resource Table header file

On Thu, May 04, 2023 at 02:50:13PM +0000, Ross Philipson wrote:

> +#define SLR_TABLE_MAGIC		0x4452544d

>From convention I'd expect this to be 0x534c5254, but not really an 
issue.

> +/* SLR defined bootloaders */
> +#define SLR_BOOTLOADER_INVALID	0
> +#define SLR_BOOTLOADER_GRUB	1

Oof. Having the kernel know about bootloaders has not worked out super 
well for us in the past. If someone writes a new bootloader, are they 
unable to Secure Launch any existing kernels? The pragmatic thing for 
them to do would be to just pretend they're grub, which kind of defeats 
the point of having this definition...

> +} __packed;

Random nit - why are they all packed? Are there circumstances where two 
pieces of code with different assumptions about alignment will be 
looking at a single instance of a table? It doesn't seem likely we're 
going to be doing DRTM in a 32-bit firmware environment while launching 
a 64-bit kernel?