From: Daniel Jacobowitz <dan@debian.org>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Ulrich Drepper <drepper@redhat.com>,
Rik van Riel <riel@redhat.com>,
Jamie Lokier <jamie@shareable.org>, Andi Kleen <ak@suse.de>,
johnstul@us.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch
Date: Fri, 6 Feb 2004 22:37:59 -0500 [thread overview]
Message-ID: <20040207033759.GA8384@nevyn.them.org> (raw)
In-Reply-To: <20040207021954.GD31926@dualathlon.random>
On Sat, Feb 07, 2004 at 03:19:55AM +0100, Andrea Arcangeli wrote:
> > The official kernel might have the vdso at a fixed address part no part
> > of the ABI requires this address and so anybody with some security
> > conscience can change the kernel to randomize the vdso address. It's
> > not my or Ingo's fault that Linus doesn't like the exec-shield code
> > which would introduce the randomization. The important aspect is that
> > we can add vdso randomization and nothing else needs changing. The same
> > libc will run6 on a stock kernel and the one with the randomized vdso.
> > This is not the case on x86-64 where the absolute address for the
> > gettimeofday is used.
>
> I don't know exactly what your "randomization exec-shield" code is doing
> either. the way I understand what you wrote is that you want to relocate
> the vsyscall trasparently without glibc knowledge, so in short you're
> saying that you don't care to randomize everything in the userspace
> executable address space, you only care to relocate the vgettimeofday
> bytecode, not the rest of the vsyscall pieces. So with your solution
> you'll still have "fixed" addresses in the address space that will allow
> an attacker to execute vgettimeofday, just like glibc can execute it
> without noticing the actual function was relocated. As far as glibc
> won't notice that vgettimeofday has been relocated by your
> "exec-shield", it means the attacker as well can execute it just fine.
You might want to stop and take a look at the way this works on i386
before you argue with Ulrich any more about it.
Specifically, the vsyscall DSO is constructed as a normal ELF image,
and its base address is passed to glibc as an AT_SYSINFO tag in the
application's auxv vector. Glibc source code has absolutely no
knowledge of the base address, which in fact has changed at least three
times since it was created.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2004-02-07 3:38 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1075344395.1592.87.camel@cog.beaverton.ibm.com.suse.lists.linux.kernel>
[not found] ` <401894DA.7000609@redhat.com.suse.lists.linux.kernel>
[not found] ` <20040201012803.GN26076@dualathlon.random.suse.lists.linux.kernel>
[not found] ` <401F251C.2090300@redhat.com.suse.lists.linux.kernel>
[not found] ` <20040203085224.GA15738@mail.shareable.org.suse.lists.linux.kernel>
[not found] ` <20040203162515.GY26076@dualathlon.random.suse.lists.linux.kernel>
[not found] ` <20040203173716.GC17895@mail.shareable.org.suse.lists.linux.kernel>
[not found] ` <20040203181001.GA26076@dualathlon.random.suse.lists.linux.kernel>
[not found] ` <20040203182310.GA18326@mail.shareable.org.suse.lists.linux.kernel>
2004-02-04 2:27 ` [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch Andi Kleen
2004-02-04 2:40 ` Andrea Arcangeli
2004-02-04 4:21 ` Jamie Lokier
2004-02-05 21:43 ` Andrea Arcangeli
2004-02-06 4:15 ` Rik van Riel
2004-02-06 4:28 ` Andrea Arcangeli
2004-02-06 9:23 ` Ulrich Drepper
2004-02-06 15:49 ` Andrea Arcangeli
2004-02-07 0:37 ` Ulrich Drepper
2004-02-07 2:19 ` Andrea Arcangeli
2004-02-07 3:37 ` Daniel Jacobowitz [this message]
2004-02-07 4:36 ` Andrea Arcangeli
2004-02-07 4:53 ` Jamie Lokier
2004-01-29 2:46 john stultz
2004-01-29 5:06 ` Ulrich Drepper
2004-01-29 13:26 ` Jamie Lokier
2004-01-29 18:05 ` Ulrich Drepper
2004-01-29 19:15 ` Jamie Lokier
2004-01-29 23:59 ` john stultz
2004-01-30 0:40 ` Ulrich Drepper
2004-01-30 0:31 ` Ulrich Drepper
2004-01-30 4:17 ` Jamie Lokier
2004-01-30 5:09 ` Ulrich Drepper
2004-01-30 9:29 ` Ingo Molnar
2004-02-03 4:38 ` Ulrich Drepper
2004-01-30 17:34 ` Jamie Lokier
2004-01-30 8:33 ` Jakub Jelinek
2004-01-30 17:21 ` Jamie Lokier
2004-01-31 0:10 ` Eric W. Biederman
2004-01-31 2:41 ` Jamie Lokier
2004-01-31 5:54 ` Eric W. Biederman
2004-02-01 1:28 ` Andrea Arcangeli
2004-02-03 4:35 ` Ulrich Drepper
2004-02-03 5:34 ` Andrea Arcangeli
2004-02-03 8:52 ` Jamie Lokier
2004-02-03 16:25 ` Andrea Arcangeli
2004-02-03 17:37 ` Jamie Lokier
2004-02-03 18:10 ` Andrea Arcangeli
2004-02-03 18:23 ` Jamie Lokier
2004-02-03 18:34 ` Andrea Arcangeli
2004-01-31 0:17 ` Eric W. Biederman
2004-01-31 2:20 ` john stultz
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=20040207033759.GA8384@nevyn.them.org \
--to=dan@debian.org \
--cc=ak@suse.de \
--cc=andrea@suse.de \
--cc=drepper@redhat.com \
--cc=jamie@shareable.org \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.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