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: <20181204123355.GD11803@zn.tnic>
Date:   Tue, 4 Dec 2018 13:33:55 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        the arch/x86 maintainers <x86@...nel.org>, nstange@...e.de,
        Rik van Riel <riel@...riel.com>,
        KVM devel mailing list <kvm@...r.kernel.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Radim Krčmář <rkrcmar@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...e.de>,
        linux-efi <linux-efi@...r.kernel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/fpu] x86/fpu: Don't export __kernel_fpu_{begin,end}()

On Tue, Dec 04, 2018 at 01:15:10PM +0100, Sebastian Andrzej Siewior wrote:
> Do you refer to
> | *   - by IRQ context code to potentially use the FPU
> | *     if it's unused.
>   
> ? It is possible to use the FPU in IRQ context.

I mean interrupted_user_mode() where we apparently can use the FPU when
handling an IRQ from user mode.

> The FPU could be used in user-context surrounded by kernel_fpu_begin().

Right, that.

> This only disables preemption so an IRQ could interrupt it. This IRQ
> could then use the FPU or raise a SoftIRQ which would use it.
> Therefore on x86 it is required to check with irq_fpu_usable() if the

Yes, and the check that thing does is:

        return !in_interrupt() ||
                interrupted_user_mode() || ...

so you're either *not* in interrupt, or you've gotten the IRQ while in
user mode.

> FPU can be used. If the FPU can not be used, you have to implement
> fallback code.
> 
> With the "restore FPU on return to userland" series we need to modify
> the FPU in a few places. The softirq and preemption is disabled. I
> didn't find any in-IRQ users.
> Going forward I would like to remove the in-IRQ part and
> irq_fpu_usable() and disable softirq as part of kernel_fpu_begin().

Right, and we should document all those new conditions prominently so
that people are aware.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ