linux-kernel - RE: [PATCH] MIPS: Use __copy_{to,from}_user() for emulated FP loads/stores

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: <e220ba9a19da41abba599b5873afa494@AcuMS.aculab.com>
Date:   Wed, 4 Dec 2019 16:18:52 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Paul Burton' <paulburton@...nel.org>
CC:     "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH] MIPS: Use __copy_{to,from}_user() for emulated FP
 loads/stores

From: Paul Burton
> Sent: 04 December 2019 15:41
> On Wed, Dec 04, 2019 at 11:14:08AM +0000, David Laight wrote:
> > From: Paul Burton
> > > Sent: 03 December 2019 20:50
> > > Our FPU emulator currently uses __get_user() & __put_user() to perform
> > > emulated loads & stores. This is problematic because __get_user() &
> > > __put_user() are only suitable for naturally aligned memory accesses,
> > > and the address we're accessing is entirely under the control of
> > > userland.
> > >
> > > This allows userland to cause a kernel panic by simply performing an
> > > unaligned floating point load or store - the kernel will handle the
> > > address error exception by attempting to emulate the instruction, and in
> > > the process it may generate another address error exception itself.
> > > This time the exception is taken with EPC pointing at the kernels FPU
> > > emulation code, and we hit a die_if_kernel() in
> > > emulate_load_store_insn().
> >
> > Won't this be true of almost all code that uses get_user() and put_user()
> > (with or without the leading __).
> 
> Only if the address being accessed is under the control of userland to
> the extent that it can create an unaligned address. You're right that
> may be more widespread though; it needs checking...

Look at (for example) the recvmmsg() code or epoll_wait().

I'd expect all get/put_user() to be potentially unaligned.
The user might have to try hard (to avoid all the faults in userspace)
but any buffer passed to the kernel can potentially be misaligned and
nothing (I've seen) is documented as returning EFAULT/SIGSEGV
for such unaligned buffers.

In 'days of yore...' SPARC systems would have done a SIGSEGV for
any misaligned access in userspace.
Not sure why Linux ever thought it was necessary to 'fixup' such faults.
OTOH it is too late to change that behaviour (at least for existing ports).

> We used to have separate get_user_unaligned() & put_user_unaligned()
> which would suggest that it's expected that get_user() & put_user()
> require their accesses be aligned, but they were removed by commit
> 3170d8d226c2 ("kill {__,}{get,put}_user_unaligned()") in v4.13.
> 
> But perhaps we should just take the second AdEL exception & recover via
> the fixups table. We definitely don't right now... Needs further
> investigation...

get/put_user can fault because the user page is absent (etc).
So there must be code to 'expect' a fault on those instructions.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)