linux-kernel - Re: [PATCH 23/27] x86/fpu: Defer FPU state load until return to userspace

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: <20190412171955.npe2pbomc6np326v@linutronix.de>
Date:   Fri, 12 Apr 2019 19:19:55 +0200
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        Andy Lutomirski <luto@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        kvm@...r.kernel.org, "Jason A. Donenfeld" <Jason@...c4.com>,
        Rik van Riel <riel@...riel.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH 23/27] x86/fpu: Defer FPU state load until return to
 userspace

On 2019-04-12 18:48:28 [+0200], Borislav Petkov wrote:
> On Fri, Apr 12, 2019 at 06:37:41PM +0200, Sebastian Andrzej Siewior wrote:
> > (as you mentioned) so we would always record both trace points.
> > Therefore I would suggest to remove it.
> 
> Remove which one?

remove x86_fpu_activate_state.

> Recording both TPs seems to make sense unless it doesn't make a whole
> lotta sense to have:
> 
> fpregs_mark_activate
> |-> trace_x86_fpu_activate_state		<-- TP1
> |-> fpregs_activate
>     |-> trace_x86_fpu_regs_activated		<-- TP2

> Yeah, looks like the two are too much and too close for no good
> reason. There's nothing particularly spectacular in-between in
> fpregs_activate().

correct.

> > Maybe we could add a new one to __fpregs_load_activate() one in case we
> > avoid loading registers because of fpregs_state_valid(). This might make
> > sense.
> 
> But that's only the switch_fpu_return() path. Is fpregs_mark_activate()
> is going to use only the trace_x86_fpu_regs_activated() one? Note the
> "d" at the end.

You could have a trace-point in case we return to userland and we don't
load FPU registers because it looks like they are valid.
It was just an idea.

We could also rip all trcepoints out, rethink the situation and add new
ones based on current code.
- on schedule out, we may need to save registers (depending on
  TIF_NEED_FPU_LOAD) which is new. Before the series we always did.

- on schedule in do nothing but set that TIF bit. This is probably
  boring.

- on return to userland we should load the registers but can avoid it if
  we assume that they are valid for the current task
  (fpregs_state_valid())

- in kernel_fpu_begin() we may trash the task's FPU state (by saving its
  registers or by resetting fpu_fpregs_owner_ctx).

Those might be interesting.

Currently we have:
  "x86/fpu: %p load: %d xfeatures: %llx xcomp_bv: %llx"

and we have to find out what happens based on where that TP was
recorded. Also I'm not sure if the recorded xfeatures change over time.
I think they do not…

>   [ Btw, those two names need adjusting too: who came up with such close,
>      confusing names?!
>      ]

you mean trace_x86_fpu_activate_state and trace_x86_fpu_regs_activated?
They were added in d1898b733619b ("x86/fpu: Add tracepoints to dump FPU
state at key points") and we wouldn't have any otherwise.

Sebastian