What you are saying makes no sense.
So then the compiler runs to link these binaries, and you trust it?
Also, it is using various libraries, including libc.so, and you have
to trust those files? But those library routines in there trust all sorts
of other files also, to not be corrupted.
By extension, I guess you are saying you don't trust any file on the system.
And going only a tiny step further --- Who will sha256 the sha256 file?
Did you think about how you solve that?
I wish you luck designing your own system which overcomes all this vague
trusting trust "my root owned files might be corrupt"
OpenBSD is not that system.
"Schech, C. W. (\"Connor\")" <sch...@gmail.com> wrote:
> 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).
> >
>
