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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 15 Oct 2021 06:34:17 -0700 From: Andi Kleen <ak@...ux.intel.com> To: "Michael S. Tsirkin" <mst@...hat.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 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
Powered by blists - more mailing lists