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] [day] [month] [year] [list]
Message-ID: <8aa96131-c719-411b-92c2-1c3b121d89e6@intel.com>
Date: Thu, 29 Jan 2026 08:59:14 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Chao Gao <chao.gao@...el.com>
Cc: linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org,
 kvm@...r.kernel.org, x86@...nel.org, reinette.chatre@...el.com,
 ira.weiny@...el.com, kai.huang@...el.com, dan.j.williams@...el.com,
 yilun.xu@...ux.intel.com, sagis@...gle.com, vannapurve@...gle.com,
 paulmck@...nel.org, nik.borisov@...e.com, zhenzhong.duan@...el.com,
 seanjc@...gle.com, rick.p.edgecombe@...el.com, kas@...nel.org,
 dave.hansen@...ux.intel.com, vishal.l.verma@...el.com,
 Farrah Chen <farrah.chen@...el.com>, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v3 06/26] x86/virt/tdx: Prepare to support P-SEAMLDR
 SEAMCALLs

On 1/29/26 06:55, Chao Gao wrote:
> On Wed, Jan 28, 2026 at 03:03:14PM -0800, Dave Hansen wrote:
...
> Thanks. This is much clearer than my version.
> 
> One tiny nit: NP-SEAMLDR isn't SEAM mode software. It is an authenticated code
> module (ACM).

Ahhh, thanks for the correction!

>> Then do this part:
>>
>>> P-SEAMLDR SEAMCALLs differ from SEAMCALLs of the TDX module in terms of
>>> error codes and the handling of the current VMCS.
>> Except I don't even know how the TDX module handles the current VMCS.
>> That probably needs to be in there. Or, it should be brought up in the
>> patch itself that implements this. Or, uplifted to the cover letter.
> 
> My logic was:
> 
> 1. The kernel communicates with P-SEAMLDR via SEAMCALL, just like with the TDX
>    Module.
> 2. But P-SEAMLDR SEAMCALLs and TDX Module SEAMCALLs are slightly different.
> 
> So we need some tweaks to the low-level helpers to add separate wrappers for
> P-SEAMLDR SEAMCALLs.
> 
> To me, without mentioning #2, these tweaks in this patch (for separate wrappers
> in the next patch) aren't justified.

My objection is that you talk about the VMCS handling in here but
there's no actual VMCS handling. This is the changelog for patch 06/26,
not 07/26.

Don't talk about the VMCS handling here. When you do, make sure you give
enough background.

>>>  static __always_inline u64 sc_retry(sc_func_t func, u64 fn,
>>>  			   struct tdx_module_args *args)
>>>  {
>>> +	u64 retry_code = TDX_RND_NO_ENTROPY;
>>>  	int retry = RDRAND_RETRY_LOOPS;
>>>  	u64 ret;
>>>  
>>> +	if (unlikely(is_seamldr_call(fn)))
>>> +		retry_code = SEAMLDR_RND_NO_ENTROPY;
>>
>> (un)likey() has two uses:
>>
>> 1. It's in performance critical code and compilers have been
>>   demonstrated to be generating bad code.
>> 2. It's in code where it's not obvious what the fast path is
>>   and (un)likey() makes the code more readable.
>>
>> Which one is this?
> 
> I think #2 although I am happy to drop "unlikely".

But why does it *MATTER*? Is it important to understand that SEAMLDR
calls are rarer than TDX module calls?


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ