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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 15 Oct 2021 06:34:17 -0700
From:   Andi Kleen <>
To:     "Michael S. Tsirkin" <>
        Kuppuswamy Sathyanarayanan 
Subject: Re: [PATCH v5 16/16] x86/tdx: Add cmdline option to force use of

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?


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


Powered by blists - more mailing lists