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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 2 Nov 2017 00:10:09 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        moritz.lipp@...k.tugraz.at,
        Daniel Gruss <daniel.gruss@...k.tugraz.at>,
        michael.schwarz@...k.tugraz.at, Kees Cook <keescook@...gle.com>,
        Hugh Dickins <hughd@...gle.com>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH 02/23] x86, kaiser: do not set _PAGE_USER for init_mm page tables

On Wed, Nov 1, 2017 at 3:20 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Wed, 1 Nov 2017, Linus Torvalds wrote:
>> On Wed, Nov 1, 2017 at 2:52 PM, Dave Hansen <dave.hansen@...ux.intel.com> wrote:
>> > On 11/01/2017 02:28 PM, Thomas Gleixner wrote:
>> >> On Wed, 1 Nov 2017, Andy Lutomirski wrote:
>> >>> The vsyscall page is _PAGE_USER and lives in init_mm via the fixmap.
>> >>
>> >> Groan, forgot about that abomination, but still there is no point in having
>> >> it marked PAGE_USER in the init_mm at all, kaiser or not.
>> >
>> > So shouldn't this patch effectively make the vsyscall page unusable?
>> > Any idea why that didn't show up in any of the x86 selftests?
>>
>> I actually think there may be two issues here:
>>
>>  - vsyscall isn't even used much - if any - any more
>
> Only legacy user space uses it.
>
>>  - the vsyscall emulation works fine without _PAGE_USER, since the
>> whole point is that we take a fault on it and then emulate.
>>
>> We do expose the vsyscall page read-only to user space in the
>> emulation case, but I'm not convinced that's even required.
>
> I don't see a reason why it needs to be mapped at all for emulation.

At least a couple years ago, the maintainers of some userspace tracing
tools complained very loudly at the early versions of the patches.
There are programs like pin (semi-open-source IIRC) that parse
instructions, make an instrumented copy, and run it.  This means that
the vsyscall page needs to contain text that is semantically
equivalent to what calling it actually does.

So yes, read access needs to work.  I should add a selftest for this.

This is needed in emulation mode as well as native mode, so removing
native mode is totally orthogonal.

Powered by blists - more mailing lists