[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1712081835390.1840@nanos>
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