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
> +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?
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.
>> +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.
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?
> > > +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?
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.