On Fri, 2008-08-08 at 11:46 +0200, Arnd Bergmann wrote:> On Friday 08 August 2008, Dave Hansen wrote:> > + hh->magic = 0x00a2d200;> > + hh->major = (LINUX_VERSION_CODE >> 16) & 0xff;> > + hh->minor = (LINUX_VERSION_CODE >> 8) & 0xff;> > + hh->patch = (LINUX_VERSION_CODE) & 0xff;...> > +}> > Do you rely on the kernel version in order to determine the format> of the binary data, or is it just informational?> > If you think the format can change in incompatible ways, you> probably need something more specific than the version number> these days, because there are just so many different trees with> the same numbers.

Yeah, this is very true. My guess is that we'll need something likewhat we do with modversions.

> > +struct cr_hdr_tail {> > + __u32 magic;> > + __u32 cksum[2];> > +};> > This structure has an odd multiple of 32-bit members, which means> that if you put it into a larger structure that also contains> 64-bit members, the larger structure may get different alignment> on x86-32 and x86-64, which you might want to avoid.> I can't tell if this is an actual problem here.

Can't we just declare all these things __packed__ and stop worryingabout aligning them all manually?

I have to wonder if this is just a symptom of us trying to do this thewrong way. We're trying to talk the kernel into writing internal gunkinto a FD. You're right, it is like a splice where one end of the pipeis in the kernel.

Yes, eventually. I think one good point is that we should probablyremove this now so that we *have* to think about security implicationsas we add each individual patch. For instance, what kind of checking dowe do when we restore an mlock()'d VMA?