![]() | |||||||||||||
Messages in this thread |
On Tue, Feb 03, 2004 at 08:52:24AM +0000, Jamie Lokier wrote: > Ulrich Drepper wrote: > > You got to be kidding. Some object fixed in the address space which can > > perform system calls. Nothing is more welcome to somebody trying to > > exploit some bugs. > Two approaches to randomising the vdso address: > > 1. Selecting a random address at boot time. All tasks have the same > vdso for that run of the kernel. Advantages: no MSR write at > each context switch; could patch libsyscall.so at boot time with > address if we were fanatical about optimisation (i.e. other > libcs, not Glibc :) Disadvantages: the attacker may eventually > learn the address. > > 2. Select a random address for every new task. Advantages: harder > to guess from studying a machine for a long time. Disadvantages: > slower context switches; the gain from randomising each task is > nothing if all the tasks are very long lived anyway. could you please explain what's the point of this randomising thing what this attacker is trying to do? nothing can be randomized, as far as the vsyscall can be executed it means its address in the address space is known and not random. If the address is random you can't execute it. The whole vsyscall space is readonly, the attacker can do nothing on it, no way to touch it with put_user either. on x86-64 whatever is executable is readable too (readable non executable is possible but that's another issue) whatever the API you'll always be able to find the vsyscall address or it means you can't execute it in the first place. so in short, either we have vsyscalls non-randomized, or we don't have them at all, period. especially having a fixed address per-kernel makes no sense at all since it's trivial to find out by all other tasks anyways. the current API was presented around two years ago at UKUUG, and it was developed in the open in the x86-64 mailing list (archives should be online), so if there's really a fundamental problem it would been much better if you would send your complains to those lists at that time, instead of coming out of the blue years later when the code runs in production just fine for years (and it's in glibc for a long time too I think). Still I'm struggling to understand what's your point about randomization, your request makes no sense at all to me and I cannot imagine any remote security issue related to the current API of the vsyscalls, furthmore I cannot remotely imagine any difference in terms of security by using a vsyscall table, the only difference to the end user would be that its userspace would be running slower, while right now it's running as fast as the hardware can. I would appreciate a more detailed explanation rather than "address must randomized and the api must be changed". - 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/ | ||||||||||||
| Last update: 2005-03-22 13:00 [from the cache] ©2003-2008 | |||||||||||||