On Wed, 2014-10-22 at 21:20 +0200, Ralf Baechle wrote: > On Wed, Oct 22, 2014 at 11:03:01AM -0700, David Daney wrote: > > > There is another reason to have a relocatable kernel: The security people > > are starting to demand it so that they can randomize the load address. > > That may work for some platforms - but in the MIPS world we still have to > deal with very claustrophobic systems which barely leave any space to > move a kernel around. > > > This is the approach I was thinking of taking. There would be a small PIC > > wrapper that applied the relocations, and then passed control to the real > > entry point. > > > > We would have to be careful of the ex_table, as that is now sorted at build > > time. For that, we could go to the scheme used by x86, and have that > > addresses in the ex_table be relative, build time sorting is already working > > for x86 relocatable kernels. > > That's probably more of an implementation detail. I'm more concerned about > the overall bloat. I think many embedded users are so addivted to benchmark > results that this going to make or break the whole scheme. If you can make relocation a configuration option (as on x86), it would allow distributions to build multiplatform kernels without preventing embedded users from building a kernel optimised for their specific system. But I know very little about MIPS or how intrusive the changes for relocation would have to be. Perhaps it would be too much of a maintenance burden to make this an option. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison
Attachment:
signature.asc
Description: This is a digitally signed message part
