linux-kernel - Re: [3.1 patch] x86: default to vsyscall=native

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 10 Oct 2011 08:31:13 -0700
From:	Andrew Lutomirski <luto@....edu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	richard -rw- weinberger <richard.weinberger@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Adrian Bunk <bunk@...sta.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [3.1 patch] x86: default to vsyscall=native

On Mon, Oct 10, 2011 at 4:48 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * richard -rw- weinberger <richard.weinberger@...il.com> wrote:
>
>> From UML's point of view the current situation is odd. UML will no
>> longer run on top of a default 3.1 kernel.
>
> This needs to be fixed (perhaps worked around in UML if that's
> possible and if you agree with that) - or barring a real obvious fix
> needs to be reverted to the last-known-working state. We are in -rc9
> so nothing but really, really obvious patches can be applied.
>
>> Why is this odd? One of the major reasons why people are still
>> using UML is because you can run it as non-privileged user on any
>> x86 Linux host. An user which has root privileges can setup and use
>> KVM which is much nicer than UML...
>
> No, your complaint is entirely justified.
>
> Andrew?

I think I know what the root cause is and I have most of a patch to
fix it.  It doesn't compile (yet), it's a little less trivial than I'd
like for something this late in the -rc cycle, and it adds 16 bytes to
thread_struct (ugh!).

I think I can make a follow-up patch that removes 32 bytes of
per-thread state to restore my karma, though, but that will definitely
not be 3.1 material.

The issue is that the existing trap_no, error_code, and cr2 fields are
used in ways that appear rather broken and extremely fragile to report
detailed exception info to user space when SIGSEGV, SIGBUS, and
SIGTRAP happen.  Touching them from the failed uaccess paths might
have unfortunate side effects like breaking vm86.  I suspect that
nothing other than UML and vm86 users care because they're only used
for the old sigcontext data and not for modern siginfo.  The tricky
case for vsyscall emulation is if gettimeofday is called with a buffer
that crosses a page boundary and the second page causes the fault.

I'll email something out in a day or two (maybe today).

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/