Re: Question regarding crunchgen(1) binaries

On Mon, Apr 15, 2024, 8:07 AM Shawn Webb <shawn.webb@hardenedbsd.org> wrote:

> On Mon, Apr 15, 2024 at 02:05:31AM +0100, Jamie Landeg-Jones wrote:
> > Shawn Webb <shawn.webb@hardenedbsd.org> wrote:
> >
> > > 1. Enhance crunchgen(1) to support libc built with LTO.
> > > 2. Kick crunchgen(1) to the curb.
> > > 3. Other ideas from the community are possible.
> > >
> > > Does anyone find crunchgen(1) to be truly useful in 2024? If we kick
> > > crunchgen(1) to the curb, we need to modify the build system for
> > > /rescue binaries.
> >
> > Please note, my response is not considering the security aspects you
> raise,
> > and is only based on the usefulness of /rescue itself.
> >
> > Do you mean get rid of /rescue, or just getting rid of crunchgen
> producing
> > it?
>
> I recognize now that the way I phrased things left room for ambiguity.
> I apologize for the ambiguity.
>
> We do indeed want to keep /rescue around. I still have the occasional
> use for it, as do many others.
>
> The only thing that would change would be that the applications in
> /rescue would be regular statically-linked executables. We would
> stop using crunchgen(1) to produce those executables.
>

I'm going to say what others have said privately: this is a non-starter and
has no support at all. We are not going to stop using crunchgen unless
there is a viable alternative to do the same thing.


>
> > I've been "rescued" by rescue on more than one location - usually systems
> > that won't mount /usr and also have a screwed up lib.
> >
> > I wouldn't want to see a static /rescue disappear, and the size would
> probably
> > be too large for individual binaries.
>
> There are around 148 files in my 15-CURRENT/amd64 /rescue. The size
> would likely baloon quite drastically.
>
> I think I will likely determine the level of effort to fix
> crunchgen(1) to work with LTO-ified libc. I might base my decision off
> that.
>
> Meanwhile, if anyone else has any info to pass along that could help
> in this journey, I would very much appreciate it. This touches bits
> that have a lot of history, and this is definitely a blind spot of
> mine.
>

So far all you've said is they appear not to work. Sounts like an LTO bug
in llvm.

My advice: start with a crunchgen'd cat or hello world and see if you can
at least produce a test case that's small and manageable. You can submit
that upstream to see if they can fix it. Or you can chase down in gdb where
this goes off the rails.

At a wild guess, though, you are talking about adding a security package
that makes things safe somehow. That's typically with symbol redirection.
Maybe start there to understand what "LTO" the security thing is doing and
why it's either wrong or violates an assumption in crunchgen that can be
fixed.

Warner


Thanks,
>
> --
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
>
> Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
>
> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
>