linux-kernel - Re: [PATCH v8 05/21] x86/cea: Export API for per-CPU exception stacks for KVM

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: <20251023141552.GA3245006@noisy.programming.kicks-ass.net>
Date: Thu, 23 Oct 2025 16:15:52 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Xin Li <xin@...or.com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, linux-doc@...r.kernel.org, pbonzini@...hat.com,
	corbet@....net, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
	dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
	luto@...nel.org, andrew.cooper3@...rix.com, chao.gao@...el.com,
	hch@...radead.org
Subject: Re: [PATCH v8 05/21] x86/cea: Export API for per-CPU exception
 stacks for KVM

On Thu, Oct 23, 2025 at 07:08:06AM -0700, Sean Christopherson wrote:
> On Thu, Oct 23, 2025, Xin Li wrote:
> > 
> > >> FRED introduced new fields in the host-state area of the VMCS for stack
> > >> levels 1->3 (HOST_IA32_FRED_RSP[123]), each respectively corresponding to
> > >> per-CPU exception stacks for #DB, NMI and #DF.  KVM must populate these
> > >> fields each time a vCPU is loaded onto a CPU.
> > > 
> > >> +noinstr unsigned long __this_cpu_ist_top_va(enum exception_stack_ordering stack)
> > >> +{
> > >> +    return __this_cpu_ist_bottom_va(stack) + EXCEPTION_STKSZ;
> > >> +}
> > >> +EXPORT_SYMBOL(__this_cpu_ist_top_va);
> > > 
> > > This has no business being a !GPL export. But please use:
> > > 
> > > EXPORT_SYMBOL_FOR_MODULES(__this_cpu_ist_top_val, "kvm");
> > > 
> > > (or "kvm-intel", depending on which actual module ends up needing this
> > > symbol).
> > 
> > Will do “kvm-intel” because that is the only module uses the APIs.
> 
> Alternatively, what about a slightly more automated approach, at the cost of some
> precision?  The below adds EXPORT_SYMBOL_FOR_KVM and only generates exports for
> pieces of KVM that will be build as a module.  The loss of precision is that a
> symbol that's used by one KVM module would get exported for all KVM modules, but
> IMO the ease of maintenance would be worth a few "unnecessary" exports.  We could
> also add e.g. EXPORT_SYMBOL_FOR_KVM_{AMD,INTEL}, but I don't think that adds much
> value over having just EXPORT_SYMBOL_FOR_KVM().

Works for me.