On Fri, Apr 11, 2014 at 2:59 PM, H. Peter Anvin <hpa@xxxxxxxxxxxxxxx> wrote: > On 04/11/2014 02:53 PM, Andy Lutomirski wrote: >> >> How big of a functionality problem is it? Apparently it doesn't break >> 16-bit code on wine. >> > > It breaks *some* 16-bit code. This is actually the reason that 32 bits > has the espfix workaround - it wasn't identified as an infoleak at the time. > >> Since the high bits of esp have been corrupted on x86_64 since the >> beginning, there's no regression issue here if an eventual fix writes >> less meaningful crap to those bits -- I see no real reason to try to put >> the correct values in there. > > It is a regression vs. the 32-bit kernel, and if we're going to support > 16-bit code we should arguably support 16-bit code correctly. > > This is actually how I stumbled onto this problem in the first place: it > broke a compiler test suite for gcc -m16 I was working on. The > workaround for *that* was to run in a VM instead. > >>>> I would have suggested rejecting modify_ldt() entirely, to reduce attack >>>> surface, except that some early versions of 32-bit NPTL glibc use >>>> modify_ldt() to exclusion of all other methods of establishing the >>>> thread pointer, so in order to stay compatible with those we would need >>>> to allow 32-bit segments via modify_ldt() still. >> >> I actually use modify_ldt for amusement: it's the only way I know of to >> issue real 32-bit syscalls from 64-bit userspace. Yes, this isn't >> really a legitimate use case. > > That's actually wrong on no less than two levels: > > 1. You can issue real 32-bit system calls from 64-bit user space simply > by invoking int $0x80; it works in 64-bit mode as well. > > 2. Even if you want to be in 32-bit mode you can simply call via > __USER32_CS, you don't need an LDT entry. I just looked up my hideous code. I was doing this to test the now-deleted int 0xcc vsyscall stuff. I used modify_ldt because either I didn't realize that __USER32_CS was usable or I didn't think it was ABI. Or I was just being silly. But yes, breaking my hack would not matter. :) --Andy -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html