linux-kernel - Re: [PATCH 17/21] x86/fpu: Use proper mask to replace full instruction mask

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]

Date:   Mon, 22 Jun 2020 11:05:32 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Liang, Kan" <kan.liang@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     mingo@...hat.com, acme@...nel.org, tglx@...utronix.de,
        bp@...en8.de, x86@...nel.org, linux-kernel@...r.kernel.org,
        mark.rutland@....com, alexander.shishkin@...ux.intel.com,
        jolsa@...hat.com, namhyung@...nel.org, yu-cheng.yu@...el.com,
        bigeasy@...utronix.de, gorcunov@...il.com, hpa@...or.com,
        alexey.budankov@...ux.intel.com, eranian@...gle.com,
        ak@...ux.intel.com, like.xu@...ux.intel.com,
        yao.jin@...ux.intel.com
Subject: Re: [PATCH 17/21] x86/fpu: Use proper mask to replace full
 instruction mask

On 6/22/20 10:47 AM, Liang, Kan wrote:
>> I'm wondering if we should just take these copy_*regs_to_*() functions
>> and uninline them.  Yeah, they are basically wrapping one instruction,
>> but it might literally be the most heavyweight instruction in the
>> whole ISA.
> 
> Thanks for the suggestions, but I'm not sure if I follow these methods.
> 
> I don't think simply removing the "inline" key word for the
> copy_xregs_to_kernel() functions would help here.
> Do you mean exporting the copy_*regs_to_*()?

The thing that worries me here is exporting "internal" FPU state like
xfeatures_mask_all.  I'm much happier exporting a function with a much
more defined purpose.

So, yes, I'm suggesting exporting the functions, *not* the data structures.

>> Or, maybe just make an out-of-line version for KVM to call?
> 
> I think the out-of-line version for KVM still needs the
> xfeatures_mask_all. Because the size of vcpu's XSAVE buffer
> (&vcpu->arch.guest_fpu) is the same as other kernel XSAVE buffers, such
> as task->fpu. The xfeatures_mask_all is required for KVM to filter out
> the dynamic supervisor feature as well. I think even if we make an
> out-of-line version for KVM, we still have to export the
> xfeatures_mask_all for KVM.

No.

You do this in a .h file:

extern void notinline_copy_xregs_to_kernel(struct xregs_state *xstate);

And then this in a .c file:

void notinline_copy_xregs_to_kernel(struct xregs_state *xstate)
{
	copy_xregs_to_kernel(xstate);
}
EXPORT_SYMBOL_GPL(notinline_copy_xregs_to_kernel);


KVM now calls notinline_copy_xregs_to_kernel() (not what it should
really be called).  It does *not* need 'xfeatures_mask_all' exported in
this case.  That preserves the inlining for core kernel users.

It's not the prettiest situation, but it is straightforward.