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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 17 Oct 2021 18:34:56 -0400 From: "Michael S. Tsirkin" <mst@...hat.com> To: Andi Kleen <ak@...ux.intel.com> Cc: linux-kernel@...r.kernel.org, Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com> Subject: Re: [PATCH v5 16/16] x86/tdx: Add cmdline option to force use of ioremap_host_shared On Fri, Oct 15, 2021 at 06:34:17AM -0700, Andi Kleen wrote: > cutting down the insane cc list. > > On 10/14/2021 11:57 PM, Michael S. Tsirkin wrote: > > On Thu, Oct 14, 2021 at 10:50:59PM -0700, Andi Kleen wrote: > > > > I thought you basically create an OperationRegion of SystemMemory type, > > > > and off you go. Maybe the OSPM in Linux is clever and protects > > > > some memory, I wouldn't know. > > > > > > I investigated this now, and it looks like acpi is using ioremap_cache(). We > > > can hook into that and force non sharing. It's probably safe to assume that > > > this is not used on real IO devices. > > > > > > I think there are still some other BIOS mappings that use just plain > > > ioremap() though. > > > > > > > > > -Andi > > Hmm don't you mean the reverse? If you make ioremap shared then OS is > > protected from malicious ACPI? > > > Nope > > > If you don't make it shared then > > malicious ACPI can poke at arbitrary OS memory. > > > When it's private it's protected and when it's shared it can be attacked > > > > > > For BIOS I suspect there's no way around it, it needs to be > > audited since it's executable. > > > The guest BIOS is attested and trusted. The original ACPI tables by the BIOS > are attested and trusted too. > > Just if we map the ACPI tables temporarily shared then an evil hypervisor > could modify them during that time window. > > -Andi I thought some more about it. Fundamentally, ACPI has these types of OperationRegions: SystemIO | SystemMemory | PCI_Config | EmbeddedControl | SMBus | SystemCMOS | PciBarTarget | IPMI | GeneralPurposeIO | GenericSerialBus | PCC Now, SystemMemory can be used to talk to either BIOS (should be encrypted) or hypervisor (should not be encrypted). I think it's not a great idea to commit to either, or teach users to hack around it with command line flags. Instead there should be a new SystemMemoryUnencrypted API for interface with the hypervisor. Can you guys propose this at the ACPI spec? If not but at least we are in agreement I guess I can try to do it, have a bit of experience with the ACPI spec. And I assume PciBarTarget should be unencrypted so it can work. -- MST
Powered by blists - more mailing lists