From: Kees Cook <keescook@google.com>
To: Kostya Serebryany <kcc@google.com>
Cc: Evgenii Stepanov <eugenis@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Daniel Micay <danielmicay@gmail.com>,
Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Rik van Riel <riel@redhat.com>, Reid Kleckner <rnk@google.com>,
Peter Collingbourne <pcc@google.com>
Subject: Re: binfmt_elf: use ELF_ET_DYN_BASE only for PIE breaks asan
Date: Mon, 7 Aug 2017 12:24:28 -0700 [thread overview]
Message-ID: <CAGXu5jJ+eGdpmf9q7Hdt0yxg5US5=3ydB2NeR+3T4ubrDogZPQ@mail.gmail.com> (raw)
In-Reply-To: <CAN=P9pjDDM3QzmO0PEYZKPE3SxYWWrbN0kx6SgF+u2s9BD+-yA@mail.gmail.com>
On Mon, Aug 7, 2017 at 12:03 PM, Kostya Serebryany <kcc@google.com> wrote:
>
>
> On Mon, Aug 7, 2017 at 11:57 AM, Kees Cook <keescook@google.com> wrote:
>>
>> On Mon, Aug 7, 2017 at 11:51 AM, Evgenii Stepanov <eugenis@google.com>
>> wrote:
>> > On Mon, Aug 7, 2017 at 11:40 AM, Kees Cook <keescook@google.com> wrote:
>> >> On Mon, Aug 7, 2017 at 11:36 AM, Evgenii Stepanov <eugenis@google.com>
>> >> wrote:
>> >>> MSan is 64-bit only and does not allow any mappings _outside_ of these
>> >>> regions:
>> >>> 000000000000 - 010000000000 app-1
>> >>> 510000000000 - 600000000000 app-2
>> >>> 700000000000 - 800000000000 app-3
>> >>>
>> >>> https://github.com/google/sanitizers/issues/579
>> >>>
>> >>> It sounds like the ELF_ET_DYN_BASE change should not break MSan.
>> >>
>> >> Hah, so the proposed move to 0x1000 8000 0000 for ASan would break
>> >> MSan. Lovely! :P
>> >
>> > That's unfortunate.
>> > This will not help existing binaries, but going forward the mapping
>> > can be adjusted at runtime to anything like
>> > 000000000000 .. A
>> > 500000000000 + A .. 600000000000
>> > 700000000000 .. 800000000000
>> > i.e. we can look at where the binary is mapped and set A to anything
>> > in the range of [0, 1000 0000 0000). That's still not compatible with
>> > 0x1000 8000 0000 though.
>>
>> So A is considered to be < 0x1000 0000 0000? And a future MSan could
>> handle a PIE base of 0x2000 0000 0000? If ASan an TSan can handle that
>> too, then we could use that as the future PIE base. Existing systems
>> will need some sort of reversion.
>>
>> The primary concerns with the CVEs fixed with the PIE base commit was
>> for 32-bit. While it is possible to collide on 64-bit, it is much more
>> rare. As long as we have no problems with the new 32-bit PIE base, we
>> can revert the 64-bit base default back to 0x5555 5555 4000.
>
>
> Yes, please!!
For the revert, can you clarify which architectures this is a problem
for? And confirm that the current 32-bit PIE base is not bugged? I'd
like to minimize the revert.
-Kees
--
Kees Cook
Pixel Security
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-08-07 19:24 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-07 17:24 Dmitry Vyukov
2017-08-07 17:33 ` Kostya Serebryany
2017-08-07 17:33 ` Kees Cook
2017-08-07 18:26 ` Kostya Serebryany
2017-08-07 18:36 ` Evgenii Stepanov
2017-08-07 18:40 ` Kees Cook
2017-08-07 18:51 ` Evgenii Stepanov
2017-08-07 18:57 ` Kees Cook
2017-08-07 19:03 ` Kostya Serebryany
2017-08-07 19:06 ` Kees Cook
2017-08-07 19:10 ` Kostya Serebryany
2017-08-07 19:24 ` Kees Cook [this message]
2017-08-07 19:32 ` Kostya Serebryany
2017-08-07 19:12 ` Evgenii Stepanov
2017-08-07 18:38 ` Daniel Micay
2017-08-07 18:45 ` Daniel Micay
2017-08-07 18:39 ` Kees Cook
2017-08-07 18:48 ` Daniel Micay
2017-08-07 18:52 ` Kees Cook
2017-08-07 18:56 ` Kostya Serebryany
2017-08-07 18:59 ` Kees Cook
2017-08-07 19:01 ` Daniel Micay
2017-08-07 19:05 ` Kostya Serebryany
2017-08-07 19:12 ` Kees Cook
2017-08-07 19:16 ` Kostya Serebryany
2017-08-07 19:21 ` Kees Cook
2017-08-07 19:26 ` Kostya Serebryany
2017-08-07 19:34 ` Kees Cook
2017-08-07 19:40 ` Kostya Serebryany
2017-08-07 19:42 ` Daniel Micay
2017-08-07 19:46 ` Kees Cook
2017-08-07 18:21 ` Daniel Micay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGXu5jJ+eGdpmf9q7Hdt0yxg5US5=3ydB2NeR+3T4ubrDogZPQ@mail.gmail.com' \
--to=keescook@google.com \
--cc=akpm@linux-foundation.org \
--cc=danielmicay@gmail.com \
--cc=dvyukov@google.com \
--cc=eugenis@google.com \
--cc=kcc@google.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=pcc@google.com \
--cc=riel@redhat.com \
--cc=rnk@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox