From: Brijesh Singh <brijesh.singh@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: brijesh.singh@amd.com, x86@kernel.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org,
linux-coco@lists.linux.dev, linux-mm@kvack.org,
linux-crypto@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Joerg Roedel <jroedel@suse.de>,
Tom Lendacky <thomas.lendacky@amd.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Ard Biesheuvel <ardb@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>,
Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Sergio Lopez <slp@redhat.com>, Peter Gonda <pgonda@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
David Rientjes <rientjes@google.com>,
tony.luck@intel.com, npmccallum@redhat.com,
Dov Murik <dovmurik@linux.ibm.com>
Subject: Re: [PATCH Part1 RFC v3 22/22] virt: Add SEV-SNP guest driver
Date: Mon, 5 Jul 2021 05:39:04 -0500 [thread overview]
Message-ID: <9c5037b6-d9a7-78e3-f2e4-bf8bebc12da7@amd.com> (raw)
In-Reply-To: <YOCOIy1AW5RUfbx4@zn.tnic>
On 7/3/21 11:19 AM, Borislav Petkov wrote:
> On Thu, Jul 01, 2021 at 04:32:25PM -0500, Brijesh Singh wrote:
>> The spec definition is present in include/linux/psp-sev.h but sometime
>> we don't expose the spec defs as-is to userspace.
> Why?
>
> Having such undocumented and maybe unwarranted differences - I still
> don't see a clear reason why - is calling for additional and unnecessary
> confusion.
Because some of fields don't make any sense for the userspace interfaces.
>
>> Several SEV/SEV-SNP does not need to be exposed to the userspace,
>> those which need to be expose we provide a bit modified Linux uapi for
>> it, and for SEV drivers we choose "_user" prefix.
> Is that documented somewhere?
>
> Because "user" doesn't tell me it is a modified structure which is
> different from the spec.
We have good documentation for the SEV ioctl and structure provided
through the KVM interface.
Unfortunately the the documentation for the ioctl and structure provided
through /dev/sev does not exist. We could look into adding this
documentation outside this series. The structure provided through
/dev/sev is identical to the structure documented in the spec with minor
changes such as not exposing reserved fields or rename from paddr to
uaddr etc.
>> e.g
>> a spec definition for the PEK import in include/linux/psp-sev.h is:
>> struct sev_data_pek_cert_import {
>> u64 pdh_cert_address; /* system physical address */
>> u32 pdh_cert_len;
>> u32 reserved;
>> ...
>> };
>>
>> But its corresponding userspace structure def in include/uapi/linux/psp-sev.h is:
>> struct sev_user_data_pek_cert_import {
>> __u64 pek_cert_uaddr; /* userspace address */
>> __u32 pek_cert_len;
>> ...
>> };
> And the difference is a single "u32 reserved"?
Mostly yes.
>
> Dunno, from where I'm standing this looks like unnecessary confusion to
> me.
>> The ioctl handling takes care of mapping from uaddr to pa and other
>> things as required. So, I took similar approach for the SEV-SNP guest
>> ioctl. In this particular case the guest request structure defined in
>> the spec contains multiple field but many of those fields are managed
>> internally by the kernel (e.g seqno, IV, etc etc).
> Ok, multiple fields sounds like you wanna save on the data that is
> shovelled between kernel and user space and then some of the fields
> don't mean a thing for the user API. Ok.
>
> But again, where is this documented and stated clear so that people are
> aware?
>
> Or are you assuming that since the user counterparts are in
>
> include/uapi/linux/psp-sev.h
> ^^^^
>
> and it being an uapi header, then that should state that?
>
Yes, the assumption is user wanting to communicate to PSP through
/dev/sev will need to include include psp-sev.h from
uapi/linux/psp-sev.h. The header file itself document the fields
definition, and then user need to refer to SEV SPEC for the further
details. I could start documenting the SNP specific ioctl in
Documentation/virt/coco/sevguest.rst and it can be later expanded to
cover SEV and SEV-ES.
-Brijesh
next prev parent reply other threads:[~2021-07-05 10:39 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-02 14:03 [PATCH Part1 RFC v3 00/22] Add AMD Secure Nested Paging (SEV-SNP) Guest Support Brijesh Singh
2021-06-02 14:03 ` [PATCH Part1 RFC v3 01/22] x86/sev: shorten GHCB terminate macro names Brijesh Singh
2021-06-08 15:54 ` Venu Busireddy
2021-06-02 14:03 ` [PATCH Part1 RFC v3 02/22] x86/sev: Define the Linux specific guest termination reasons Brijesh Singh
2021-06-08 15:59 ` Venu Busireddy
2021-06-08 16:51 ` Brijesh Singh
2021-06-02 14:03 ` [PATCH Part1 RFC v3 03/22] x86/sev: Save the negotiated GHCB version Brijesh Singh
2021-06-03 19:57 ` Borislav Petkov
2021-06-08 17:35 ` Venu Busireddy
2021-06-02 14:03 ` [PATCH Part1 RFC v3 04/22] x86/mm: Add sev_feature_enabled() helper Brijesh Singh
2021-06-05 10:50 ` Borislav Petkov
2021-06-02 14:03 ` [PATCH Part1 RFC v3 05/22] x86/sev: Add support for hypervisor feature VMGEXIT Brijesh Singh
2021-06-07 14:19 ` Borislav Petkov
2021-06-07 14:58 ` Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 06/22] x86/sev: check SEV-SNP features support Brijesh Singh
2021-06-07 14:54 ` Borislav Petkov
2021-06-07 16:01 ` Brijesh Singh
2021-06-17 18:46 ` Brijesh Singh
2021-06-18 5:46 ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 07/22] x86/sev: Add a helper for the PVALIDATE instruction Brijesh Singh
2021-06-07 15:35 ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 08/22] x86/compressed: Add helper for validating pages in the decompression stage Brijesh Singh
2021-06-08 11:12 ` Borislav Petkov
2021-06-08 15:58 ` Brijesh Singh
2021-06-16 10:21 ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 09/22] x86/compressed: Register GHCB memory when SEV-SNP is active Brijesh Singh
2021-06-09 17:47 ` Borislav Petkov
2021-06-14 12:28 ` Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 10/22] x86/sev: " Brijesh Singh
2021-06-10 5:49 ` Borislav Petkov
2021-06-14 12:29 ` Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 11/22] x86/sev: Add helper for validating pages in early enc attribute changes Brijesh Singh
2021-06-10 15:50 ` Borislav Petkov
2021-06-14 12:45 ` Brijesh Singh
2021-06-14 19:03 ` Borislav Petkov
2021-06-14 21:01 ` Brijesh Singh
2021-06-16 10:07 ` Borislav Petkov
2021-06-16 11:00 ` Brijesh Singh
2021-06-16 12:03 ` Borislav Petkov
2021-06-16 12:49 ` Brijesh Singh
2021-06-16 13:02 ` Borislav Petkov
2021-06-16 13:10 ` Brijesh Singh
2021-06-16 14:36 ` Brijesh Singh
2021-06-16 14:37 ` Brijesh Singh
2021-06-16 13:06 ` Dr. David Alan Gilbert
2021-06-02 14:04 ` [PATCH Part1 RFC v3 12/22] x86/kernel: Make the bss.decrypted section shared in RMP table Brijesh Singh
2021-06-10 16:06 ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 13/22] x86/kernel: Validate rom memory before accessing when SEV-SNP is active Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 14/22] x86/mm: Add support to validate memory when changing C-bit Brijesh Singh
2021-06-11 9:44 ` Borislav Petkov
2021-06-14 13:05 ` Brijesh Singh
2021-06-14 19:27 ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 15/22] KVM: SVM: define new SEV_FEATURES field in the VMCB Save State Area Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 16/22] KVM: SVM: Create a separate mapping for the SEV-ES save area Brijesh Singh
2021-06-14 10:58 ` Borislav Petkov
2021-06-14 19:34 ` Tom Lendacky
2021-06-14 19:50 ` Borislav Petkov
2021-06-02 14:04 ` [PATCH Part1 RFC v3 17/22] KVM: SVM: Create a separate mapping for the GHCB " Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 18/22] KVM: SVM: Update the SEV-ES save area mapping Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 19/22] x86/sev-snp: SEV-SNP AP creation support Brijesh Singh
2021-06-16 13:07 ` Borislav Petkov
2021-06-16 16:13 ` Tom Lendacky
2021-06-02 14:04 ` [PATCH Part1 RFC v3 20/22] x86/boot: Add Confidential Computing address to setup_header Brijesh Singh
2021-06-18 6:08 ` Borislav Petkov
2021-06-18 13:57 ` Brijesh Singh
2021-06-18 15:05 ` Borislav Petkov
[not found] ` <162442264313.98837.16983159316116149849@amd.com>
2021-06-23 10:22 ` Borislav Petkov
2021-06-24 3:19 ` Michael Roth
2021-06-24 7:27 ` Borislav Petkov
2021-06-24 12:26 ` Michael Roth
2021-06-24 12:34 ` Michael Roth
2021-06-24 12:54 ` Borislav Petkov
2021-06-24 14:11 ` Michael Roth
2021-06-25 14:48 ` Borislav Petkov
2021-06-25 15:24 ` Brijesh Singh
2021-06-25 17:01 ` Borislav Petkov
2021-06-25 18:14 ` Michael Roth
2021-06-28 13:43 ` Borislav Petkov
2021-06-24 13:09 ` Kuppuswamy, Sathyanarayanan
2021-06-02 14:04 ` [PATCH Part1 RFC v3 21/22] x86/sev: Register SNP guest request platform device Brijesh Singh
2021-06-04 11:28 ` Sergio Lopez
2021-06-09 19:24 ` Dr. David Alan Gilbert
2021-06-11 13:16 ` Tom Lendacky
2021-06-14 17:15 ` Dr. David Alan Gilbert
2021-06-14 18:24 ` Brijesh Singh
2021-06-14 13:20 ` Brijesh Singh
2021-06-14 17:23 ` Dr. David Alan Gilbert
2021-06-14 20:50 ` Brijesh Singh
2021-06-18 9:46 ` Borislav Petkov
2021-06-18 13:59 ` Brijesh Singh
2021-06-02 14:04 ` [PATCH Part1 RFC v3 22/22] virt: Add SEV-SNP guest driver Brijesh Singh
2021-06-30 13:35 ` Borislav Petkov
2021-06-30 16:26 ` Brijesh Singh
2021-07-01 18:03 ` Borislav Petkov
2021-07-01 21:32 ` Brijesh Singh
2021-07-03 16:19 ` Borislav Petkov
2021-07-05 10:39 ` Brijesh Singh [this message]
2021-06-07 19:15 ` [PATCH Part1 RFC v3 00/22] Add AMD Secure Nested Paging (SEV-SNP) Guest Support Venu Busireddy
2021-06-07 19:17 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9c5037b6-d9a7-78e3-f2e4-bf8bebc12da7@amd.com \
--to=brijesh.singh@amd.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=dovmurik@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=jroedel@suse.de \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=npmccallum@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=pgonda@google.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rientjes@google.com \
--cc=seanjc@google.com \
--cc=slp@redhat.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tony.luck@intel.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).