Yes, I understand that OpenBSD is self-hosting, and it seems like an
infinite recursion with no base case. The base case is actually the
last version with GCC support that's no longer in the CDN archive. And
the Computer Store stopped carrying the CDs.
Do you really trust that there is enough entropy when the system is
idle during boot from the install media to generate a reordered kernel
that's sufficiently random? Why doesn't it reorder on first boot after
collecting sufficient entropy, and allow the user to skip? or allow
the user to skip in the install script? Decoupling the components
makes it easier to reason about.
Additionally reordering the kernel N times between boots doesn't add
to security if the components are tamper-proof. it's a ring structure
like in a simple substitution cipher where multiple applications
yields just another simple substitution. This is just concerning a
simple safeguard for unsophisticated tampering or cross-build
contamination, or local configuration errors. If the components on the
system aren't tamper-proof (it's optimistic to assume they are, "No
remote holes ever again!", etc.) an attacker can deduce the link
structure by finding strings from inside each object in the link kit
and matching segments within the /bsd binary to find the entry points
like a really boring game of Battleship. So one mitigation opens up a
system integrity aspect that didn't exist before the concept of link
kits was added. Also, knowing the initial ordering and the size of
each object is enough to extract the information that reorder_kernel
needs to execute indefinitely, the link kit can be discarded just like
the objects traditionally were in the build. This new system is a
strange kind of single-level store implemented in userspace, so the
same considerations about it being transactional and tagged that
Multics or IBM dealt and deal with apply. IBM would do what
"reorder_kernel" does in microcode.
So now you need to add a "sanitize_objects" routine as well as a
"reorder_kernel" routine, why not just move the reordering into
kernel-space where it belongs, or does IBM still hold patent(s) on
that? Surely they are from the 1970s and have expired.
On Wed, Jun 14, 2023 at 9:56 PM Theo de Raadt <dera...@openbsd.org> wrote:
>
> 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).
> > >
> >
