public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave@sr71.net>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>, X86 ML <x86@kernel.org>
Subject: Re: [RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels
Date: Fri, 12 Dec 2014 15:16:52 -0800	[thread overview]
Message-ID: <548B7764.2060608@sr71.net> (raw)
In-Reply-To: <CALCETrVZcED1x+YV4V+c9nnieaz8DMbO4D455h2QYF__jX-DKg@mail.gmail.com>

On 12/12/2014 03:04 PM, Andy Lutomirski wrote:
> Anyway, do your patches handle the case where a 32-bit app maliciously
> executes a 64-bit mpx insn with a very large address?  I think it's
> okay, but I might have missed something.

You mean in the instruction decoder?  I haven't tried that case
explicitly, but I did do a substantial amount of testing throwing random
instruction streams at the decoder to make sure it never fell over.
(Well, mostly random, I made sure to throw the MPX opcodes in there a
bunch so it would get much deeper in to the decoder).

It's not about the instruction size, it's about the mode the CPU is in.
If a 32-bit app manages to switch over to 64-bit mode and doesn't tell
the kernel (TIF_IA32 remains set), then we'll treat it as a 32-bit
instruction.

The kernel might end up going and looking for the bounds tables in some
funky places if the kernel and the hardware disagree about 32 vs. 64-bit
modes, but it's not going to do any harm since we treat all of the data
we get from MPX (instruction decoding, register contents, bounds table
contents, etc...) as completely untrusted.

It's a nice, paranoid thing to ask and I'm glad you brought it up
because I hadn't thought about it, but I don't think any harm can come
of it.

  reply	other threads:[~2014-12-12 23:16 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-12 19:12 [RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels Dave Hansen
2014-12-12 19:12 ` [RFC][PATCH 1/8] x86: make is_64bit_mm() widely available Dave Hansen
2014-12-12 19:12 ` [RFC][PATCH 2/8] x86: make __VIRTUAL_MASK safe to use on 32 bit Dave Hansen
2014-12-12 19:12 ` [RFC][PATCH 3/8] x86, mpx: we do not allocate the bounds directory Dave Hansen
2014-12-12 19:12 ` [RFC][PATCH 4/8] x86, mpx: remove redundant MPX_BNDCFG_ADDR_MASK Dave Hansen
2014-12-12 19:12 ` [RFC][PATCH 5/8] x86, mpx: Add temporary variable to reduce masking Dave Hansen
2014-12-12 19:12 ` [RFC][PATCH 6/8] x86, mpx: new directory entry to addr helper Dave Hansen
2014-12-12 19:12 ` [RFC][PATCH 7/8] x86, mpx: do 32-bit-only cmpxchg for 32-bit apps Dave Hansen
2014-12-12 19:12 ` [RFC][PATCH 8/8] x86, mpx: support 32bit binaries on 64bit kernel Dave Hansen
2014-12-12 20:22 ` [RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels Andy Lutomirski
2014-12-12 20:27   ` Dave Hansen
2014-12-12 20:48     ` Andy Lutomirski
2014-12-12 21:41       ` Dave Hansen
2014-12-12 23:04         ` Andy Lutomirski
2014-12-12 23:16           ` Dave Hansen [this message]
2014-12-13  0:11             ` Andy Lutomirski
2014-12-13  0:23               ` Dave Hansen
2014-12-13  1:45                 ` Andy Lutomirski
2014-12-13 15:50                   ` Dave Hansen
2014-12-12 20:27 ` Andy Lutomirski
2014-12-12 20:35   ` Dave Hansen

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=548B7764.2060608@sr71.net \
    --to=dave@sr71.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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