Re: [Fastboot] Re: [announce] kexec for linux 2.6.6

From: Eric W. Biederman
Date: Fri May 14 2004 - 00:24:28 EST


"Randy.Dunlap" <rddunlap@xxxxxxxx> writes:

> On 12 May 2004 10:57:27 -0600 Eric W. Biederman wrote:
>
> | Ulrich Drepper <drepper@xxxxxxxxxx> writes:
> |
> | > Eric W. Biederman wrote:
> | >
> | > > As a first draft we should be able to use the standard ELF mechanisms
> | > > for this. It is not like PIC shared libraries were new. Or is
> | > > there some specific problem you are thinking of with respect to
> | > > randomization?
> | >
> | > The official kernel does not have vdso randomization. Ingo has a patch
> | > for the Red Hat kernel which is used in the FC2 kernel. The patch
> | > effectively only changes the location at which the vdso is mapped. It
> | > does not change the vdso content. So the __kernel_vsyscall symbol in
> | > the vdso's symbol table is not changed.
>
> [1:]
> | > AT_SYSINFO is the right way to go forward but it is not directly
> | > accessible to userlevel code. And it is no pointer which will make
> | > architectures with function descriptors unhappy.
> |
> | It sounds like the vdso just needs to be treated as a prelinked
> | vdso. You can find everything you need with AT_SYSINFO_EHDR.
> |
> | In the case of function descriptors they should be in a data segment
> | that can get copied to another page, and corrected. Leaving the code
> | segment at it's randomized location.
>
> Andrew tells me that he is OK with reserving a syscall number for
> kexec, which is easy & quick. I don't know when vdso will be available
> (for non-x86[2]) or when the AT_SYSINFO data will work for userlevel
> code[1. above].
>
> So is there any reason not to reserve the syscall number for kexec
> for now? (patch is below)
>
> --
> ~Randy
>
>
> [2] kexec is currently only available for x86, but there is interest
> in it for ia64 and ppc64 at least.

Also been work on x86-64 and ppc32. So if we are going to reserve
syscall numbers it would also be nice to have those reserved as well.

Eric
-
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/