| raw e-mail | index | archive | help
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?>