[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJcbSZEOtx6PMhgmpwkLvcqSgZr1F41PgQRx3yGkZCjRWb8z-Q@mail.gmail.com>
Date: Mon, 2 Oct 2017 13:28:52 -0700
From: Thomas Garnier <thgarnie@...gle.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, "David S . Miller" <davem@...emloft.net>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H . Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...hat.com>,
Arnd Bergmann <arnd@...db.de>, Matthias Kaehlcke <mka@...omium.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>, Juergen Gross <jgross@...e.com>,
Paolo Bonzini <pbonzini@...hat.com>, Radim Krčmář <rkrcmar@...hat.com>,
Joerg Roedel <joro@...tes.org>, Tom Lendacky <thomas.lendacky@....com>,
Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...e.de>, Brian Gerst <brgerst@...il.com>,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, "Rafael J . Wysocki" <rjw@...ysocki.net>,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>, Tejun Heo <tj@...nel.org>,
Christoph Lameter <cl@...ux.com>, Paul Gortmaker <paul.gortmaker@...driver.com>,
Chris Metcalf <cmetcalf@...lanox.com>, Andrew Morton <akpm@...ux-foundation.org>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>, Nicolas Pitre <nicolas.pitre@...aro.org>,
Christopher Li <sparse@...isli.org>, "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
Lukas Wunner <lukas@...ner.de>, Mika Westerberg <mika.westerberg@...ux.intel.com>,
Dou Liyang <douly.fnst@...fujitsu.com>, Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>, Masahiro Yamada <yamada.masahiro@...ionext.com>,
Markus Trippelsdorf <markus@...ppelsdorf.de>, Steven Rostedt <rostedt@...dmis.org>,
Kees Cook <keescook@...omium.org>, Rik van Riel <riel@...hat.com>,
David Howells <dhowells@...hat.com>, Waiman Long <longman@...hat.com>, Kyle Huey <me@...ehuey.com>,
Peter Foley <pefoley2@...oley.com>, Tim Chen <tim.c.chen@...ux.intel.com>,
Catalin Marinas <catalin.marinas@....com>, Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Michal Hocko <mhocko@...e.com>, Matthew Wilcox <mawilcox@...rosoft.com>,
"H . J . Lu" <hjl.tools@...il.com>, Paul Bolle <pebolle@...cali.nl>, Rob Landley <rob@...dley.net>,
Baoquan He <bhe@...hat.com>, Daniel Micay <danielmicay@...il.com>,
"the arch/x86 maintainers" <x86@...nel.org>, Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, xen-devel <xen-devel@...ts.xenproject.org>,
kvm list <kvm@...r.kernel.org>, Linux PM list <linux-pm@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Sparse Mailing-list <linux-sparse@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Linus Torvalds <torvalds@...ux-foundation.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Borislav Petkov <bp@...en8.de>
Subject: Re: x86: PIE support and option to extend KASLR randomization
On Sat, Sep 23, 2017 at 2:43 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Thomas Garnier <thgarnie@...gle.com> wrote:
>
>> > 2) we first implement the additional entropy bits that Linus suggested.
>> >
>> > does this work for you?
>>
>> Sure, I can look at how feasible that is. If it is, can I send
>> everything as part of the same patch set? The additional entropy would
>> be enabled for all KASLR but PIE will be off-by-default of course.
>
> Sure, can all be part of the same series.
I looked deeper in the change Linus proposed (moving the .text section
based on the cacheline). I think the complexity is too high for the
value of this change.
To move only the .text section would require at least the following changes:
- Overall change on how relocations are processed, need to separate
relocations in and outside of the .text section.
- Break assumptions on _text alignment while keeping calculation on
size accurate (for example _end - _text).
With a rough attempt at this, I managed to pass early boot and still
crash later on.
This change would be valuable if you leak the address of a section
other than .text and you want to know where .text is. Meaning the main
bug that you are trying to exploit only allow you to execute code (and
you are trying to ROP in .text). I would argue that a better
mitigation for this type of bugs is moving function pointer to
read-only sections and using stack cookies (for ret address). This
change won't prevent other type of attacks, like data corruption.
I think it would be more valuable to look at something like selfrando
/ pagerando [1] but maybe wait a bit for it to be more mature
(especially on the debugging side).
What do you think?
[1] http://lists.llvm.org/pipermail/llvm-dev/2017-June/113794.html
>
> Thanks,
>
> Ingo
--
Thomas
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
