There's no check of the checksums for all the object files that the
/rc task consumes
This can be trivially fixed by generating them in, say
In /sys/conf/newvars.sh, add the line:
+sha512 -h /var/db/obj.${id}.sha512 *.o lorder
above the segment starting with:
cat >vers.c <<eof
[...]
then the right checksums always persist in /var/db on release or
between builds, labelled with the {id}
in /etc/rc or kernel_reorder, before invoking the kernel reordering
routine, make a guard statement that checks that all the object
checksums are OK, i.e.,
IN /usr/share/relink/kernel/GENERIC..:
IF:
sha512 -c /var/db/obj.${id}.sha512
Does not return zero, skip reordering, print out details of failed
hash checks, etc
before reordering anything.
Broken kernels will get to at least the next reordering/network
startup phase. I had a nice test harness for the guard not being there
except the entire filesystem got clobbered except a few items.
Also consider moving the relinking to "only at shutdown", so no other
jobs are running concurrently in case that causes a random kernel
fault due to extreme load on faulty hardware, and to make the boot
time as fast as possible, since the relinked kernel isn't used until
the boot after AFAIK.
Also conside not using a link kit and just scrambling kernel A with
lorder C into kernel B with lorder D without carrying around any
object code (by default) in the environment that persists anywhere.
The initial offsets are computable and any rearrangements too with
just a perl script or a clever tiny C utility. Saves lots of CPU time
and 300 MB of very sensitive binary blobs gone..
I have tested a prototype of this solution and it works, the exit
status of the sha512 program detects bad or missing components. make
doesn't get caught in a loop and always generates after a fresh build
that got all the way to linking.
Hope someone can help/feedback/comments.. Sorry I don't have an exact
two or three line commit for the fence that stops the bad/mismatched
kernel < - > link kit reordering.
My solution takes care of the fact that the install media doesn't
include checksums for the install sets embedded in it, and also it
allows them to always be guaranteed to be up-to-date with whoever
provided the upstream kernel, which immediately writes its sha256 at
the end of the build process also to /var/db.
Hope this is not off-topic.
