linux-kernel - Re: [patch 01/10] x86/fpu/signal: Clarify exception handling in restore_fpregs_from

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YS1yj+mUtvnCab1g@zeniv-ca.linux.org.uk>
Date:   Tue, 31 Aug 2021 00:06:39 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Dan Williams <dan.j.williams@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        LKML <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [patch 01/10] x86/fpu/signal: Clarify exception handling in
 restore_fpregs_from_user()

On Mon, Aug 30, 2021 at 03:00:06PM -0700, Linus Torvalds wrote:
> On Mon, Aug 30, 2021 at 2:33 PM Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > There's a place where we care about #PF vs. #MC (see upthread)...
> 
> Interestingly (or perhaps not), that case is a problem case in general
> for "fault_in_pages_readable()".

s/a/the one and only/

> I'm not sure what the right model here is. We might need to make
> fault_in_pages_readable() do things a cacheline at a time, at which
> point those repeat loops start working, and the error code thing
> becomes pointless.

	We really don't want to do that to fault_in_pages_readable();
a separate primitive doing that - perhaps, but fault_in_pages_readable()
is used on fairly hot paths and all callers except this one don't need
anything of that sort.

	Similar for fault_in_pages_writeable() - there's exactly one
caller that needs the same kind of warranties, only there it's in
arch-independent code and I'm fairly sure that it (btrfs ioctl) really
is broken on arm64...