Date:   Fri, 16 Jun 2023 14:21:33 -0400
From:   "Daniel P. Smith" <dpsmith@...rtussolutions.com>
To:     Matthew Garrett <mjg59@...f.ucam.org>
Cc:     Ross Philipson <ross.philipson@...cle.com>,
        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,
        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 02/14] Documentation/x86: Secure Launch kernel
 documentation

On 6/16/23 12:54, Matthew Garrett wrote:
> On Fri, Jun 16, 2023 at 12:44:27PM -0400, Daniel P. Smith wrote:
>>
>> On 5/12/23 06:47, Matthew Garrett wrote:
>>> On Thu, May 04, 2023 at 02:50:11PM +0000, Ross Philipson wrote:
>>>> +Secure Launch does not interoperate with KASLR. If possible, the MLE should be
>>>> +built with KASLR disabled::
>>>
>>> Why does Secure Launch not interoperate with KASLR?
>>>
>>> Re: IOMMUs
>>
>> Until the IOMMU driver comes online, memory is protected by the PMRs regions
>> requested by the Preamble (pre-launch code) in accordance with Intel TXT
>> specifications and configured by the ACM. The KASLR randomizer will run
>> before the IOMMU driver is able to come online and ensure frames used by the
>> kernel are protected as well as frames that a driver may registered in a BAR
>> are not blocked.
> 
> This seems unfortunate. Presumably we're not able to modify the PMRs at
> this point? This also seems like a potential issue for IOMMU config in
> general - the presumption is that the firmware should be configuring the
> IOMMU in such a way that DMA-capable devices can't attack the firmware
> while we're in the boot environment, and if KASLR is leaving a window
> there then it seems like we'd need to fix that?

While unfortunate, it is a bit of the nature of the problem KASLR is 
attempting to address. If you know in advance where kernel pages are 
going to live and the frames that will be used for DMA, then have you 
not defeated the purpose of the randomization? As for the firmware use 
of the IOMMU, I am fairly certain those tables will get invalidated by 
the ACM when it is setting up the PMRs.

>>>> +It is recommended that no other command line options should be set to override
>>>> +the defaults above.
>>>
>>> What happens if they are? Does doing so change the security posture of
>>> the system? If so, will the measurements be different in a way that
>>> demonstrates the system is in an insecure state?
>>>
>>
>> In an early version of the patch series this was enforced when turning on
>> Secure Launch, but concerns were raised over this approach and was asked to
>> allow the user to be able to shoot themselves in the foot. Overriding these
>> values could render either an insecure state and/or an unstable system.
> 
> If we're in an insecure state, is that something that would show up in
> the form of different measurements?

Yes, you would get a different measurement for the commandline. If you 
are thinking in terms of attestation, I would expect that the 
attestation measurement db would have a record for an acceptable 
commandline and would determine the system to be in an unknown state if 
it did not match.

While the idea could be explored to create measurements based on 
configurations of kernel subsystems, this would likely entail 
instrumentation in those subsystems to assert a measurement to their 
configuration. Maybe IMA could cover something like this? It would 
definitely enable the ability to make deeper assessments about the state 
of a system, but I think this is out of the scope of what Secure Launch 
is attempting to do.

Powered by blists - more mailing lists