Date: Mon, 15 Apr 2024 09:45:59 -0600 From: Warner Losh <imp@bsdimp.com> To: Shawn Webb <shawn.webb@hardenedbsd.org> Cc: Jamie Landeg-Jones <jamie@catflap.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Question regarding crunchgen(1) binaries Message-ID: <CANCZdfo-0YPrQhNzi9GVNNAXyayQWJ2etA-VOHmo5do7bSGrsg@mail.gmail.com> In-Reply-To: <7lmqszm7n35b5jitwvzagmlc2lecl6p3dhu2bnhri4unnjtlow@f5txrntbo7yw> References: <erhqcnky6qf4adlupgtszkmrihthbdc2tbwtbhgzyltl3pl42c@gsdzinackzhh> <202404150105.43F15VoL068210@donotpassgo.dyslexicfish.net> <7lmqszm7n35b5jitwvzagmlc2lecl6p3dhu2bnhri4unnjtlow@f5txrntbo7yw>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000005494690616248505 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 15, 2024, 8:07=E2=80=AFAM Shawn Webb <shawn.webb@hardenedbsd.or= g> 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 syste= ms > > 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/0= 3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > --0000000000005494690616248505 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Mon, Apr 15, 2024, 8:07=E2=80=AFAM Shawn Webb <<= a href=3D"mailto:shawn.webb@hardenedbsd.org">shawn.webb@hardenedbsd.org</a>= > wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Apr 15, 2024 at= 02:05:31AM +0100, Jamie Landeg-Jones wrote:<br> > Shawn Webb <<a href=3D"mailto:shawn.webb@hardenedbsd.org" target=3D= "_blank" rel=3D"noreferrer">shawn.webb@hardenedbsd.org</a>> wrote:<br> > <br> > > 1. Enhance crunchgen(1) to support libc built with LTO.<br> > > 2. Kick crunchgen(1) to the curb.<br> > > 3. Other ideas from the community are possible.<br> > ><br> > > Does anyone find crunchgen(1) to be truly useful in 2024? If we k= ick<br> > > crunchgen(1) to the curb, we need to modify the build system for<= br> > > /rescue binaries.<br> > <br> > Please note, my response is not considering the security aspects you r= aise,<br> > and is only based on the usefulness of /rescue itself.<br> > <br> > Do you mean get rid of /rescue, or just getting rid of crunchgen produ= cing<br> > it?<br> <br> I recognize now that the way I phrased things left room for ambiguity.<br> I apologize for the ambiguity.<br> <br> We do indeed want to keep /rescue around. I still have the occasional<br> use for it, as do many others.<br> <br> The only thing that would change would be that the applications in<br> /rescue would be regular statically-linked executables. We would<br> stop using crunchgen(1) to produce those executables.<br></blockquote></div= ></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_qu= ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir=3D"au= to">I'm going to say what others have said privately: this is a non-sta= rter and has no support at all. We are not going to stop using crunchgen un= less there is a viable alternative to do the same thing.</div><div dir=3D"a= uto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"= gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"> > <br> > I've been "rescued" by rescue on more than one location = - usually systems<br> > that won't mount /usr and also have a screwed up lib.<br> > <br> > I wouldn't want to see a static /rescue disappear, and the size wo= uld probably<br> > be too large for individual binaries.<br> <br> There are around 148 files in my 15-CURRENT/amd64 /rescue. The size<br> would likely baloon quite drastically.<br> <br> I think I will likely determine the level of effort to fix<br> crunchgen(1) to work with LTO-ified libc. I might base my decision off<br> that.<br> <br> Meanwhile, if anyone else has any info to pass along that could help<br> in this journey, I would very much appreciate it. This touches bits<br> that have a lot of history, and this is definitely a blind spot of<br> mine.<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"a= uto">So far all you've said is they appear not to work. Sounts like an = LTO bug in llvm.</div><div dir=3D"auto"><br></div><div dir=3D"auto">My advi= ce: start with a crunchgen'd cat or hello world and see if you can at l= east produce a test case that's small and manageable. You can submit th= at upstream to see if they can fix it. Or you can chase down in gdb where t= his goes off the rails.</div><div dir=3D"auto"><br></div><div dir=3D"auto">= At a wild guess, though, you are talking about adding a security package th= at 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.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Warn= er</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D= "auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thanks,<br> <br> -- <br> Shawn Webb<br> Cofounder / Security Engineer<br> HardenedBSD<br> <br> Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50<br> <a href=3D"https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Sha= wn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc" rel=3D"noreferrer= noreferrer" target=3D"_blank">https://git.hardenedbsd.org/hardenedbsd/pubk= eys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.as= c</a><br> </blockquote></div></div></div> --0000000000005494690616248505--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo-0YPrQhNzi9GVNNAXyayQWJ2etA-VOHmo5do7bSGrsg>