linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

  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