On 2023/06/14 04:12, Schech, C. W. ("Connor") wrote:
> 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.,
How do you know the .o files from the build are ok in the first place?
If you don't trust your hardware to keep the installed copy safe, why
would the build be any different?
> 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.
Consideration was already made to the timing of when this is run.
Shutdown doesn't always happen. It can sometimes happen triggered by
a UPS running low on battery, in which case writing out a new kernel
is about the worst thing you can be doing at the time. There's no
"one size fits all" and there are problems with the current timing too,
but it's the least worst option for many cases (and can be disabled and
run manually if it's a big problem for your use).
> 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.
reorder_kernel is also there to support syspatch. (even just the hash
check also needs to take syspatch into account).
