Re: [Fastboot] Re: Announce: dumpfs v0.01 - common RAS output API

[Eric W. Biederman]

Gerrit Huizenga <gh@xxxxxxxxxx> writes:

> On Thu, 29 Jul 2004 22:20:13 BST, Alan Cox wrote:
> > 
> > On Iau, 2004-07-29 at 19:17, Andrew Morton wrote:
> > > Of course, there's an assumption here that the dead kernel doesn't scribble
> > > on pages which were never available to its page allocator.  If DMA somehow
> > > goes off and scribbles on the dump kernel we lose.
> > 
> > If the new kernel image starts with an SHA hash check including the
> > SHA hash check code that can be pretty robust as a sanity check.
> > 
> > > See above.  We assume that network RX DMA won't be scribbling in the 16MB
> > > which was pre-reserved.  That's reasonable.  We _have_ to assume that.
> > 
> > Ok
> 
> Okay, I may be confused a bit but I *thought* kexec was going to
> load the thin, new kernel (e.g. read from disk operations, which is
> better than write to disk operations from the sick kernel).

/sbin/kexec will load it with sys_kexec_load, before the kernel becomes
sick.
 
> This concept of having it pre-loaded sounds interesting, protecting
> it from being written on doesn't bother me much, but why *not* read
> it from disk/filesystem and then use the SHA hash in the newly
> loaded & exec'd kernel to make sure that what we loaded was sane?

Exactly.  That is where the SHA hash and all of the features will
go in the new ``kernel''.  What we are exec is an arbitrary
stand-alone program.  I suspect a SHA hash generator and checker
is something we can easily add as a wrapper. 

> That sounds simpler than changing the kernel load process around,
> ensuring you have the new kexec'd kernel build and loaded, etc.
> At least it sounds simpler and more in line with using kexec for
> fastboot as well.

The only process that is going to be changed around is where
we store the kernel before we transfer control to it, and when/and
how that transfer of control happens.

The beauty of kexec is all of these fun things become user 
problems from the point of the view of the sick kernel so
it does not need to worry about them.

I will be happy to see a SHA patch for /sbin/kexec.  

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/