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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c8458bfa-0985-f6a5-52a3-ef96c7669fe6@linux.microsoft.com>
Date:   Fri, 24 Mar 2023 18:10:09 +0100
From:   Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>
To:     Borislav Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     linux-kernel@...r.kernel.org,
        Brijesh Singh <brijesh.singh@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        "Kalra, Ashish" <ashish.kalra@....com>,
        linux-crypto@...r.kernel.org,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org
Subject: Re: [PATCH v3 0/8] Support ACPI PSP on Hyper-V

On 3/23/2023 5:34 PM, Borislav Petkov wrote:
> On Thu, Mar 23, 2023 at 05:11:26PM +0100, Jeremi Piotrowski wrote:
>> That same interface is exposed by physical hardware+firmware to the underlying
>> Hyper-V.
> 
> Let me see if I understand it correctly: Hyper-V *baremetal* is using
> the same ASPT spec to to talk to the *physical* PSP device?
> 

Yes

> Is that ASPT interface to talk to the PSP used by the L0 hypervisor?
> 

Yes (unless I am mistaken, this is the same statement as above).

> Or does the L0 HV have a normal driver, similar to the Linux one,
> without the functionality this ASPT spec provides?
> 
The L0 HV relies on the ASPT spec/interface to map registers and setup
interrupts and then uses a protocol driver to handle the PSP command set
(like the Linux one).

>> So it wasn't a matter of Microsoft architects coming up with a
>> guest-host interface but rather exposing the virtual hardware in the same
>> way as on a physical server.
> 
> So if you want to expose the same interface to the L1 guest, why isn't
> Hyper-V emulating an ACPI device just like any other functionality? Why
> does it need to reach into the interrupt handling internals?
> 

The primary stack for nested SNP support is Hyper-V-on-Hyper-V. 
By exposing the PSP device to the L1 guest in the same way (as the L0),
everything can done in the exact same way as on bare-metal.

I just really want nested SNP support to work in KVM-on-Hyper-V as well so
that's why I'm adding support for these things.

Also: if Linux were to run bare-metal on that hardware it would need to be
able to handle the PSP through the ASPT interface as well.

> I'd expect that the L0 HV would emulate a PSP device, the L1 would
> simply load the Linux PSP device driver and everything should just work.
> 
> What's the point of that alternate access at all?
> 

So it's actually great that you made me ask around because I learned something that
will help:

Since the AMD PSP is a privileged device, there is a desire to not have to trust the
ACPI stack, and instead rely fully on static ACPI tables for discovery and configuration.
This also applies to the AMD IOMMU. If you look at iommu_setup_intcapxt() in
drivers/iommu/amd/init.c, it does exactly the things that are needed to setup the
PSP interrupt too. Here's a link to the patch that added that:
https://lore.kernel.org/all/20201111144322.1659970-3-dwmw2@infradead.org/#t

So my plan now is to post a v4 with proper irq_domain handling.
Ok Thomas?

Best wishes,
Jeremi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ