Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3)

[Andrea Arcangeli]

On Wed, Mar 03, 2004 at 06:43:18PM -0800, john stultz wrote:
> On Wed, 2004-03-03 at 18:16, Ulrich Drepper wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Andrea Arcangeli wrote:
> > 
> > > This is just like the kernel patches people proposes when they get
> > > vmalloc LDT allocation failure, because they run with the i686 glibc
> > > instead of the only possibly supported i586 configuration. It makes no
> > > sense to hide a glibc inefficiency
> > 
> > You apparently still haven't gotten any clue since your whining the last
> > time around.  Absolute addresses are a fatal mistake.
> 
> Before we start up this larger debate again, might there be some short
> term solution for my patch that would satisfy both of you?

For a production release short term solutions like this would be ok, but
the mainline source that will fork off in 2.7 should have the best
design IMHO, and the same for glibc.

> If I understand the earlier arguments, if we're going to have the
> dynamically relocated segments at some point, I agree that absolute
> addresses are going to have problems. However, if I'm not mistaken, this
> problem already exists w/ the vsyscall-sysenter code, correct? 

this is exactly my point, the fixed address trouble mentioned by Ulirch
make little sense to me because of this (especially in reply to the ldt
part).

and in practice the sysenter instruction is already at a fixed address
in any 2.6 kernel out there (yeah, we could change that number without
breaking glibc, but the attacker won't care less).

> What is the plan for avoiding the absolute address issue there? If I
> implemented the vsyscall-gettimeofday code in a similar manner (as
> Andrea suggested), could the planned solution for vsyscall-sysenter be
> applied here as well?

I think yes but thinking twice my preferred way is not to pass another
variable address to userspace (that was the first solution that come to
mind, and I wrote that just to show there's no real "fixed address"
trouble). Fixed _offsets_ (not virtual addresses) are perfectly fine
w.r.t. security. So we can just assume the vgettimeofday is at a fixed
offset after the vsysenter code. This should result in the most
efficient code possible while providing flexiblity to the address like
vsysenter does (vgettimeofday will move together with vsysenter).
However it could be the second value in elf is a cleaner way to pass the
vgettimeofday address, I don't mind either ways.

thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/