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: <66b2744ad5b48_4fc7294f4@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 6 Aug 2024 12:06:50 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: "Huang, Kai" <kai.huang@...el.com>, "Hansen, Dave"
	<dave.hansen@...el.com>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"bp@...en8.de" <bp@...en8.de>, "peterz@...radead.org" <peterz@...radead.org>,
	"hpa@...or.com" <hpa@...or.com>, "mingo@...hat.com" <mingo@...hat.com>,
	"Williams, Dan J" <dan.j.williams@...el.com>,
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "tglx@...utronix.de"
	<tglx@...utronix.de>
CC: "Gao, Chao" <chao.gao@...el.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "binbin.wu@...ux.intel.com"
	<binbin.wu@...ux.intel.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "Edgecombe, Rick P"
	<rick.p.edgecombe@...el.com>, "x86@...nel.org" <x86@...nel.org>, "Yamahata,
 Isaku" <isaku.yamahata@...el.com>
Subject: Re: [PATCH v2 06/10] x86/virt/tdx: Refine a comment to reflect the
 latest TDX spec

Huang, Kai wrote:
[..]
> > Given this is JSON any plan to just check-in "global_metadata.json"
> > somewhere in tools/ with a script that queries for a set of fields and
> > spits them out into a Linux data structure + set of TD_SYSINFO_*_MAP()
> > calls? Then no future review bandwidth needs to be spent on manually
> > checking offsets names and values, they will just be pulled from the
> > script.
> 
> This seems a good idea.  I'll add this to my TODO list and evaluate it
> first.
> 
> One minor issue is some metadata fields may need special handling.  E.g.,
> MAX_VCPUS_PER_TD (which is u16) may not be supported by some old TDX
> modules, but this isn't an error because we can just treats it as
> U16_MAX.

TDX Module had better not be breaking us when they remove metadata
fields. So if you know of fields that get removed the module absolutely
cannot cause existing code paths. Linux could maybe grant that some
values start returning an explicit "deprecated" error code in the future
and Linux adds handling for that common case. Outside of that metadata
fields are forever and the module needs to ship placeholder values that
fail gracefully on older kernels.

OS software should not be expected to keep up with the whims of metadata
field removals without an explicit plan to make those future removals
benign to legacy kernels.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ