I don't trust anyone upstream to keep the .o files safe - that's the
central problem - the hardware reliability is an aside from the
central problem, which is that you are creating a "virtual compiler"
for arbitrary programs when you reorder the kernel, which shouldn't be
a "general purpose compiler" like, for instance clang or gcc, but only
one that can generate "OpenBSD binaries", so it needs a specification
of what a "OpenBSD binary" is. The checksums just keep that
specification abstract. Sorry if it's too theoretical. What a "OpenBSD
binary" from a given release is modulo a given compiler is the
reference objects that that compiler would generate from the source of
the release. Keeping the compiler abstract, or opaque from the
perspective of someone looking at the system as a whole.
Talking about the compiler's correct properties is the inverse problem
of the surface problem that you are trying to solve by reordering the
kernel, which is on-line attacks against the entry points for each
object that's linked into the final /bsd kernel binary, to do that and
compute the entry points off-line you only need the lorder file (which
contains the names and order of the objects), a sample /bsd binary,
the reference object file names, and the size (in bytes) of each
object.
What I am suggesting is that the hardware only needs to keep safe the
lorder file and the binary and the size and checksum of each object,
and reorder_kernel can compute those without needing the orginal
objects to be kept around, by rearranging opaque segments of the /bsd
binary, purely at the link-level.
What I am trying to express is that the compile and link phases that
should always be separate are being intermixed, because (for now) with
reference to the current generation of compilers and the current
hardware there is a lack of typed assembly language or a typed
intermediate representation (in the compiler) for the intermediate
compilation objects, so anyone can slip things in by attacking the
system at the object level, which is opaque from the linker's
perspective, and should be from reorder_kernel's as well.
As far as syspatch is concerned - that is probably the right
abstraction to look at - what should syspatch and reorder_kernel
support? Because right now it's possible for reorder_kernel to reorder
any old program that you might have clang-output objects for and the
right recipe for reordering them - I want to always ensure
kernel_reorder is only reordering valid kernels with reference to what
syspatch can also patch, in other words a "virtual compiler" for only
syspatch, not arbitrary programs produced by a reference compiler.
Keeping everything the relinker does strictly at the link-level
satisfies that (logical) property, so that it can't be attacked
trivially to patch the kernel surreptitiously, in other words a
sanity-check of its input.
On Wed, Jun 14, 2023 at 6:50 AM Stuart Henderson <s...@spacehopper.org> wrote:
>
> 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).
>
