linux-kernel - Re: [PATCH 08/13] x86/virt/tdx: Add SEAMCALL wrappers to add TD private pages

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: <be581731-07e0-4d5c-bee6-1eb653b7b72d@redhat.com>
Date: Wed, 15 Jan 2025 00:32:24 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Yan Zhao <yan.y.zhao@...el.com>,
 "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "Huang, Kai" <kai.huang@...el.com>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "Yamahata, Isaku" <isaku.yamahata@...el.com>
Subject: Re: [PATCH 08/13] x86/virt/tdx: Add SEAMCALL wrappers to add TD
 private pages

On 1/6/25 06:50, Yan Zhao wrote:
> Yeah.
> So, do you think we need to have tdh_mem_page_aug() to support 4K level page
> only and ask for Dave's review again for huge page?

You're right that TDH.MEM.PAGE.AUG is basically the only case in which a 
struct folio is involved; on the other hand that also means that the 
arch/x86/virt part of large page support will be tiny and I don't think 
it will be a problem to review it again (for either Dave or myself).

> Do we need to add param "level" ?
> - if yes, "struct page" looks not fit.

Maybe, but I think adding folio knowledge now would be a bit too 
hypothetical.

> - if not, hardcode it as 0 in the wrapper and convert "pfn" to "struct page"?

I think it makes sense to add "int level" now everywhere, even if it is 
just to match the SEPT API and to have the same style for computing the 
SEAMCALL arguments.  I'd rather keep the arguments simple with just "gpa 
| level" (i.e. gpa/level instead of gfn/level) as the computation: 
that's because gpa is more obviously a u64.

I've pushed to kvm-coco-queue; if you have some time to double check 
what I did that's great, otherwise if I don't hear from you I'll post 
around noon European time the v3 of this series.

I have also asked Amazon, since they use KVM without struct page, 
whether it is a problem to have struct page pervasively in the API and 
they don't care.

Paolo