All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "Hector Marco" <hecmargi@upv.es>,
	"Pavel Emelyanov" <xemul@parallels.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Heiko Carstens" <heiko.carstens@de.ibm.com>,
	"Oleg Nesterov" <oleg@redhat.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Anton Blanchard" <anton@samba.org>,
	"Jiri Kosina" <jkosina@suse.cz>,
	"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"David Daney" <ddaney.cavm@gmail.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Arun Chandran" <achandran@mvista.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Martin Schwidefsky" <schwidefsky@de.ibm.com>,
	"Ismael Ripoll" <iripoll@disca.upv.es>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Hanno Böck" <hanno@hboeck.de>,
	"Will Deacon" <will.deacon@arm.com>,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Reno Robert" <renorobert@gmail.com>
Subject: Re: [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack
Date: Sat, 20 Dec 2014 01:19:32 +0300	[thread overview]
Message-ID: <20141219221932.GH6810@moon> (raw)
In-Reply-To: <CALCETrWB_T9ui=_JSQRLrtbNDx=sJ22im1XujhxptfZRtedeeg@mail.gmail.com>

On Fri, Dec 19, 2014 at 02:11:37PM -0800, Andy Lutomirski wrote:
...
> >
> > Therefore, I can fix the current implementation (maintaining the
> > randomize_va_space=2) by moving the PIE executable from the mmap base
> > area to another one for x86*, ARM* and MIPS (as s390 and PowerPC do).
> > But we shall agree that this increment in the page table is not a
> > issue. Otherwise, the randomize_va_space=3 shall be considered.
> 
> Wrt the vdso itself, though, there is an extra consideration: CRIU.  I
> *think* that the CRIU vdso proxying scheme will work even if the vdso
> changes sizes and is adjacent to other mappings.  Cyrill and/or Pavel,
> am I right?

At least that was the idea. I've been testing old vdso from rhel5 proxified
to 3.x series where vvar segment is present, worked well.

> I'm not fundamentally opposed to mapping the vdso just like any other
> shared library.  I still think that we should have an extra-strong
> randomization mode in which all the libraries are randomized wrt each
> other, though.  For many applications, the extra page table cost will
> be negligible.

  reply	other threads:[~2014-12-19 22:19 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5489E6D2.2060200@upv.es>
2014-12-11 20:12 ` [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack Hector Marco
2014-12-11 22:11   ` Kees Cook
2014-12-12 16:32     ` Hector Marco
2014-12-12 17:17       ` Andy Lutomirski
2014-12-19 22:04         ` Hector Marco
2014-12-19 22:11           ` Andy Lutomirski
2014-12-19 22:19             ` Cyrill Gorcunov [this message]
2014-12-19 23:53             ` Andy Lutomirski
2014-12-20  0:29               ` [PATCH] x86_64, vdso: Fix the vdso address randomization algorithm Andy Lutomirski
2014-12-20 17:40               ` [PATCH v2] " Andy Lutomirski
2014-12-20 21:13                 ` Kees Cook
2014-12-22 17:36               ` [PATCH] ASLRv3: randomize_va_space=3 preventing offset2lib attack Hector Marco Gisbert
2014-12-22 17:56                 ` Andy Lutomirski
2014-12-22 19:49                   ` Jiri Kosina
2014-12-22 20:00                     ` Andy Lutomirski
2014-12-22 20:03                       ` Jiri Kosina
2014-12-22 20:13                         ` Andy Lutomirski
2014-12-22 23:23                   ` Hector Marco Gisbert
2014-12-22 23:38                     ` Andy Lutomirski
     [not found]                       ` <CAH4rwTKeN0P84FJnocoKV4t9rc2Ox_EYc+LEibD+Y83n7C8aVA@mail.gmail.com>
2014-12-23  8:15                         ` Andy Lutomirski
2014-12-23 20:06                           ` Hector Marco Gisbert
2014-12-23 20:53                             ` Andy Lutomirski
2015-01-07 17:26     ` Hector Marco Gisbert
2014-12-05  0:07 Hector Marco
2014-12-05 20:08 ` Kees Cook
2014-12-08 22:15   ` Hector Marco Gisbert
2014-12-05 22:00 ` Andy Lutomirski
2014-12-08 20:09 ` Christian Borntraeger
2014-12-09 17:37   ` Kees Cook

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=20141219221932.GH6810@moon \
    --to=gorcunov@gmail.com \
    --cc=achandran@mvista.com \
    --cc=akpm@linux-foundation.org \
    --cc=anton@samba.org \
    --cc=benh@kernel.crashing.org \
    --cc=borntraeger@de.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=ddaney.cavm@gmail.com \
    --cc=hanno@hboeck.de \
    --cc=hecmargi@upv.es \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=iripoll@disca.upv.es \
    --cc=jkosina@suse.cz \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=renorobert@gmail.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    --cc=xemul@parallels.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.