linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rich Felker <dalias@libc.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Linux MIPS Mailing List <linux-mips@linux-mips.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Paul Burton <paul.burton@imgtec.com>,
	David Daney <david.daney@cavium.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Paul Burton <paul.burton@mips.com>,
	James Hogan <jhogan@kernel.org>
Subject: Re: Fixing MIPS delay slot emulation weakness?
Date: Sat, 15 Dec 2018 17:50:10 -0500	[thread overview]
Message-ID: <20181215225009.GB23599@brightrain.aerifal.cx> (raw)
In-Reply-To: <CALCETrWaWTupSp6V=XXhvExtFdS6ewx_0A7hiGfStqpeuqZn8g@mail.gmail.com>

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@imgtec.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

  parent reply	other threads:[~2018-12-15 22:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-15 19:19 Fixing MIPS delay slot emulation weakness? Andy Lutomirski
2018-12-15 21:26 ` Paul Burton
2018-12-16 18:11   ` Rich Felker
2018-12-16 18:55   ` Andy Lutomirski
2018-12-15 22:50 ` Rich Felker [this message]
2018-12-16  2:15   ` Maciej W. Rozycki
2018-12-16  2:32     ` Rich Felker
2018-12-16 13:50       ` Maciej W. Rozycki
2018-12-16 18:13         ` Rich Felker
2018-12-16 18:59           ` Andy Lutomirski
2018-12-16 19:45             ` Maciej W. Rozycki
2018-12-17  0:59             ` Rich Felker
2018-12-17  1:55               ` Maciej W. Rozycki
2018-12-18  1:13                 ` Aaro Koskinen
2018-12-19  4:32 ` Paul Burton
2018-12-19 21:12   ` Hugh Dickins
2018-12-20 17:56     ` Paul Burton
2018-12-20 17:45 ` [PATCH] MIPS: math-emu: Write-protect delay slot emulation pages Paul Burton
     [not found]   ` <20181220192616.42976218FE@mail.kernel.org>
2018-12-21 21:16     ` Paul Burton
2018-12-22 19:16       ` Sasha Levin
2018-12-23 16:16   ` Paul Burton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181215225009.GB23599@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=david.daney@cavium.com \
    --cc=jhogan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=luto@kernel.org \
    --cc=paul.burton@imgtec.com \
    --cc=paul.burton@mips.com \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).