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:   Fri, 8 Dec 2017 18:37:59 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andy Lutomirski <luto@...nel.org>
cc:     Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
        X86 ML <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Brian Gerst <brgerst@...il.com>,
        David Laight <David.Laight@...lab.com>,
        Kees Cook <keescook@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] LDT improvements

On Fri, 8 Dec 2017, Andy Lutomirski wrote:
> Can we take a step back here?  I think there are four vaguely sane
> ways to make the LDT work:
> 
> 1. The way it is right now -- in vmalloc space.  The only real
> downside is that it requires exposing that part of vmalloc space in
> the user tables, which is a bit gross.
> 
> 2. In some fixmap-like space, which is what my patch does, albeit
> buggily.  This requires a PGD that we treat as per-mm, not per-cpu,
> but that's not so bad.
> 
> 3. In one of the user PGDs but above TASK_SIZE_MAX.  This is
> functionally almost identical to #2, except that there's more concern
> about exploits that write past TASK_SIZE_MAX.
> 
> 4. In an actual vma.  I don't see the benefit of doing this at all --
> it's just like #2 except way more error prone.  Hell, you have to make
> sure that you can't munmap or mremap it, which isn't a consideration
> at all with the other choices.

Why? You can unmap vdso or uprobe or whatever VMAs and you will simply
die. You get what you asked for.

Thanks,

	tglx


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ