linux-kernel - Re: [PATCH v6 07/14] x86: Secure Launch kernel early boot stub

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]

Message-ID: <98decbe9-846a-6d36-aa7a-f906a19fa6cf@oracle.com>
Date:   Fri, 12 May 2023 12:17:50 -0400
From:   Ross Philipson <ross.philipson@...cle.com>
To:     Matthew Garrett <mjg59@...f.ucam.org>
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,
        Ross Philipson <ross.philipson@...cle.com>
Subject: Re: [PATCH v6 07/14] x86: Secure Launch kernel early boot stub

On 5/12/23 07:26, Matthew Garrett wrote:
> On Thu, May 04, 2023 at 02:50:16PM +0000, Ross Philipson wrote:
> 
>> +static void sl_find_event_log(struct slr_table *slrt)
> 
> If this is called after the EFI stub then we're presumably
> post-ExitBootServices and we're copied the TPM event log into a
> configuration table so it's available to the runtime kernel. That also
> means that we should be adding all further measurements to the Final
> Events Table rather than the initial event log. How's that handled here,
> both in terms of ensuring further events (generated by firmware or by
> us) get added to the right place, and in terms of ensuring the event
> logs the kernel has later on were covered appropriately? Or is the SL
> event log an entirely different thing that can be merged in later
> because it only covers the DRTM PCRs?

This is a good point. At this point it is really something we 
overlooked. We will have to revisit this and figure out the best way to 
find the final event log depending on how things booted.

> 
>> +static void sl_extend_setup_data(struct slr_policy_entry *entry)
>> +{
>> +	struct setup_data *data;
>> +
>> +	/*
>> +	 * Measuring the boot params measured the fixed e820 memory map.
>> +	 * Measure any setup_data entries including e820 extended entries.
>> +	 */
>> +	data = (struct setup_data *)(unsigned long)entry->entity;
>> +	while (data)
>> +		data = sl_handle_setup_data(data, entry);
>> +}
> 
> Is e820 sufficient here? There are cases where we use the EFI memory map
> directly (sorry), but I don't know if any of them are relevant to DRTM
> outcomes.

I am not 100% sure what you are asking but we also measure the EFI 
memory map. This comment is just to note that if the e820 exceeded the 
space in the fixed map in boot parameters, we would pick up any extra 
entries when measuring the setup_data list.

Thanks
Ross