[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181215225009.GB23599@brightrain.aerifal.cx>
Date: Sat, 15 Dec 2018 17:50:10 -0500
From: Rich Felker <dalias@...c.org>
To: Andy Lutomirski <luto@...nel.org>
Cc: Linux MIPS Mailing List <linux-mips@...ux-mips.org>,
LKML <linux-kernel@...r.kernel.org>,
Paul Burton <paul.burton@...tec.com>,
David Daney <david.daney@...ium.com>,
Ralf Baechle <ralf@...ux-mips.org>,
Paul Burton <paul.burton@...s.com>,
James Hogan <jhogan@...nel.org>
Subject: Re: Fixing MIPS delay slot emulation weakness?
On Sat, Dec 15, 2018 at 11:19:37AM -0800, Andy Lutomirski wrote:
> Hi all-
>
> Some security researchers pointed out that writing to the delay slot
> emulation page is a great exploit technique on MIPS. It was
> introduced in:
>
> commit 432c6bacbd0c16ec210c43da411ccc3855c4c010
> Author: Paul Burton <paul.burton@...tec.com>
> Date: Fri Jul 8 11:06:19 2016 +0100
>
> MIPS: Use per-mm page to execute branch delay slot instructions
>
> With my vDSO hat on, I hereby offer a couple of straightforward
> suggestions for fixing it. The offending code is:
>
> base = mmap_region(NULL, STACK_TOP, PAGE_SIZE,
> VM_READ|VM_WRITE|VM_EXEC|
> VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC,
> 0, NULL);
>
> VM_WRITE | VM_EXEC is a big no-no, especially at a fixed address.
>
> The really simple but possibly suboptimal fix is to get rid of
> VM_WRITE and to use get_user_pages(..., FOLL_FORCE) to write to it.
>
> A possibly nicer way to accomplish more or less the same thing would
> be to allocate the area with _install_special_mapping() and arrange to
> keep a reference to the struct page around.
>
> The really nice but less compatible fix would be to let processes or
> even the whole system opt out by promising not to put anything in FPU
> branch delay slots, of course.
As I noted on Twitter when Mudge brought this topic back up, there's a
much more compatible, elegant, and safe fix possible that does not
involve any W+X memory. Emulate the delay slot in kernel-space. This
is trivial to do safely for pretty much everything but loads/stores.
For loads/stores, where you want them to execute with user privilege
level, what you do is compute the effective address in kernel-space,
then return to a fixed instruction in the vdso page that performs a
generic load/store using the register the kernel put the effective
address result in, then restores registers off the stack and jumps to
the branch destination.
Rich
Powered by blists - more mailing lists