Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux