linux-kernel - Re: [RFC PATCH v2 0/6] SEAMCALL Wrappers

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: <c8d4bae2834555474c4c709642f86d2ec86a276e.camel@intel.com>
Date: Wed, 4 Dec 2024 01:57:57 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "Hansen, Dave" <dave.hansen@...el.com>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "Huang, Kai" <kai.huang@...el.com>
CC: "Li, Xiaoyao" <xiaoyao.li@...el.com>, "tony.lindgren@...ux.intel.com"
	<tony.lindgren@...ux.intel.com>, "Hunter, Adrian" <adrian.hunter@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>, "x86@...nel.org"
	<x86@...nel.org>, "Zhao, Yan Y" <yan.y.zhao@...el.com>
Subject: Re: [RFC PATCH v2 0/6] SEAMCALL Wrappers

On Wed, 2024-12-04 at 01:24 +0000, Huang, Kai wrote:
> Currently the global metadata reading script generates the struct member based
> on the "field name" of the JSON file.  The JSON file stores them as "size":
> 
>   "TDR_BASE_SIZE", "TDCS_BASE_SIZE", "TDVPS_BASE_SIZE"
> 
> We will need to tweak the script to map "metadata field name" to "kernel
> structure member name", and more "special handling for specific fields" when
> auto generating the code.
> 
> It's feasible but I am not sure whether it's worth to do, since we are basically
> talking about converting size to page count.

Ah, right. So given that this is generated code, we should probably just add the
wrappers like you suggest. In any case, we should remove the counts from the new
arch/x86 structs.

> 
> Also, from global metadata's point of view, perhaps it is also good to just
> provide a metadata which is consistent with what module reports.  How kernel
> uses the metadata is another layer on top of it.

I'm not sure I buy this one though. The exported arch/x86 interface shouldn't
have to match the HW directly.

> 
> Btw, perhaps we don't need to keep 'tdcs_nr_pages' and 'tdcx_nr_pages' in
> 'struct tdx_td', i.e., as per-TD variables.  They are constants for all TDX
> guests.
> 
> E.g., assuming KVM is still going to use them, it can just access them using the
> metadata structure:
> 
> 	static inline int tdx_tdcs_nr_pages(void)
> 	{
> 		return tdx_sysinfo->td_ctrl.tdcx_base_size >> PAGE_SHIFT;
> 	}
> 
> AFAICT they are only used when creating/destroying TD for a couple of times, so
> I assume doing ">> PAGE_SHIFT" a couple of times won't really matter.

None of the users are in fast paths. Using page count directly would be more
about reducing wrapper clutter.