linux-kernel - RE: [PATCH 2/5] x86/sgx: Add kernel-doc descriptions for params passed to vDSO user handler

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: <BL1PR11MB5525861CA0EB9AC16FAF4047F7CDA@BL1PR11MB5525.namprd11.prod.outlook.com>
Date: Thu, 13 Nov 2025 19:57:02 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: "tglx@...utronix.de" <tglx@...utronix.de>, "x86@...nel.org"
	<x86@...nel.org>, "mingo@...hat.com" <mingo@...hat.com>, "jarkko@...nel.org"
	<jarkko@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
	"sfr@...b.auug.org.au" <sfr@...b.auug.org.au>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/5] x86/sgx: Add kernel-doc descriptions for params
 passed to vDSO user handler

> > > Call out that except for RSP, the registers are undefined on
> > > asynchronous exits as far as the vDSO ABI is concerned.  E.g. the
> > > vDSO's exception handler clobbers RDX, RDI, and RSI, and the kernel
> > > doesn't guarantee that
> > > R8 or R9 will be zero (the synthetic value loaded by the CPU).
> >
> > Perhaps a nit:
> >
> > I am not that familiar with this part, but AFAICT the kernel always
> > sets RDI/RSI/RDX to exception vector/error code/addr before invoking
> > the user handler, after the vDSO's exception handler clobbers them.
> >
> > Since you are adding description to them, should we somehow call this
> > out in the comment, if I didn't miss anything?
> 
> I don't think we want to commit to that as ABI for the vDSO interface, which is
> why I documented the values as being "undefined".  Maybe were already stuck
> with that ABI, e.g. if some funky userspace is looking at the register params
> instead of its run structure, but IMO we should at least discourage relying on the
> values.
> 
> E.g. if the kernel ever changed its exception fixup to use different registers, then
> RDI/RSI/RDX might not hold the same values.  In hindsight, we probably should
> have scrambled those registers after propagating the exception information to the
> run structure.

Yeah makes sense to me.  Thanks for explaining.