On Fri, Dec 12, 2014 at 3:16 PM, Dave Hansen <d...@sr71.net> wrote: > 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 insn decoder should probably use user_64bit_mode, not TIF_IA32. It's actually quite easy to far jump/call/ret or sigreturn to a different bitness. > > 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. Paranoia is fun! The only thing I'd really be worried about is if the code that turns va into bounds table offset generates some absurdly large offset as a result and causes a problem. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
