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

> 
> This is because it will not vary between vCPUs. Doing it that way 
> basically preserves the existing data duplication, but these counts are 
> basically "global metadata". The global metadata patches export them as a 
> size, but KVM wants to use them as a page count. So we should not be 
> including these counts in each TD scoped structure as is currently done. To
> address the duplication we need to change the "global metadata patches"
> to export the count instead of size.
> 

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.

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.

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.