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.
