Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3)
From: Andrea Arcangeli (andrea_at_suse.de)
Date: 03/04/04
- Previous message: Aneesh Kumar KV: "Re: [PATCH] Alpha ptrace.c"
- In reply to: Jakub Jelinek: "Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3)"
- Next in thread: Jamie Lokier: "Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 4 Mar 2004 17:45:45 +0100 To: Jakub Jelinek <jakub@redhat.com>
On Thu, Mar 04, 2004 at 03:57:36AM -0500, Jakub Jelinek wrote:
> On Wed, Mar 03, 2004 at 06:54:49PM -0800, john stultz wrote:
> > On Wed, 2004-03-03 at 18:47, Andrea Arcangeli wrote:
> > > And sysenter is at a fixed address in 2.6 x86 too (it doesn't even
> > > change between different kernel compiles).
> >
> > Actually, the 4G patch pushes vsysenter down a page, and glibc seems to
> > handle this properly.
>
> But the 4G/4G patch relinks the vDSO to the address it uses, this is no
> big problem for glibc which of course doesn't use hardcoded address but
> reads AT_SYSINFO{,_EHDR} values kernel passes to it.
>
> But the fixed vDSO location is a problem, exploits certainly appreciate
> a fixed address at which they with high probability can enter the kernel.
>
> Ingo Molnar recently wrote a patch to randomize the vDSO address on
> IA-32. Unfortunately it revealed some bugs in glibc where ld.so did not
do you have a link to the patch? (I don't see it in his homepage) just
curious to see how much precious address space you're throwing at this
randomization and in turn how many tries are needed to brute force.
if you really care so much about randomization vs performance, it would
been a lot better if you implemented vsysenter in a completely different
way: by exporting some position indipendent bytecode to userspace via a
syscall, and have glibc loadup this code somewhere in the address space
(truly random thing making it trivial to do the intra-page offsets with
byte granularity) and have kernel exporting only data, not exeuctables
in the address space. The executable bytecode would be returned by a
syscall. That is something slower at startup but fairly secure, and it
doesn't waste kernel or user address space. The max-performance way of
x86 vsysenter and x86-64 vgettimeofday simply don't fit for your
security object best IMHO, it wasn't designed for that and it's an hack
to try to randomize it with page-offsets. Keeping a local copy of the
vsyscall bytecode at different intra-page offsets is something sanely
doable in userspace, doing it in kernel is hairy and non-natural thing
to do for kernel (involve copies, replacation of the vsyscall page etc.,
so one can as well do the copy in a load_usyscall syscall when the
dynamic linker is asked to run gettimeofday, so this page can also be
swapped out). What kernel can do more or less naturally is to share the
same _physical_ vsyscall "page" (w/o intra page offset differences
making it trivial to brut), and export it at a different addresses for
each task, that is what Ingo implemented I guess, but it's 4096 times *
3.5G faster to crack.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Aneesh Kumar KV: "Re: [PATCH] Alpha ptrace.c"
- In reply to: Jakub Jelinek: "Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3)"
- Next in thread: Jamie Lokier: "Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
