From nobody Mon Apr 15 15:45:59 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VJBNQ3JLZz5GqRC for ; Mon, 15 Apr 2024 15:46:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJBNQ02Jfz4pwm for ; Mon, 15 Apr 2024 15:46:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-565c6cf4819so7278057a12.1 for ; Mon, 15 Apr 2024 08:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1713195972; x=1713800772; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=f5PqBtXMXyHNFqhdzrIYM8sfOQw5bXkNFLK23tNh464=; b=j0s5sGs0OSyZNM+hLpPoYKPbrZ6D/TzY7+qeogsoMuEYGzE/mKVkXHVKNTroKVK76P zYsQojf7Tr8UqiY3cPkYYUQ9lyY7r13FdIGwSE2jFVO0TCUOgf/SYukYFWNpTaGs4+K7 OLl7sX7R6895x3U6KP79ILnDMUgg+dXPWLs8xIN1qLFb8HKELWibcHFKwh/JS4F79FBJ 64BlhRwty0T1IDomxbP16geyZq+ii0F1mk6Y+Z9buipwv6Nt35T0c36C/Z7qqcprR1+O 35/H301JunyyaJCIfuHe0dLNY/gTwO84oo53KsTlyDOLbeQqvg5nGqvmXbwZqJiYfz9x Au6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713195972; x=1713800772; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=f5PqBtXMXyHNFqhdzrIYM8sfOQw5bXkNFLK23tNh464=; b=jWqMuJ3sDuOiGbgn8XCz7pejm265abd2Ywsp/wr93xk7FfbpVNFEWmGqB38vUXWVrL 8YdDXTilzFNt5cqWq4qBUCEcee1asPQOgVdosHoUyGSP/t5xvwwSMUZhQzLU8JyT/lpn Cp+haf2D/mRYuWYnEFftZ8LZP9xEuDe+F7uj+NLTbNQt+PjJAVpfEcorGDS8OvBiJO4R 8OAFMYd6MuVGmvD3NHHHJUZiw913cukPXNUWdViO83XEk0tS41keAZU9oyTI2sunK5WX nHiQZBbXeiSN9ZpBIC5+dPYfwr/L0EZqtiW0+rfR3uC5fio0H8xVB4wyVmf9yJ8cMGxY v9pA== X-Forwarded-Encrypted: i=1; AJvYcCV1lZ6bvN/VA4RPhESU1cNvUnU3x/GtYzTcLdT58jzVLIp74voJFEcdtz5f8quVFWVogKovfUBEnlPYLk9DxbMYGGhfU1d7qgX+lZU= X-Gm-Message-State: AOJu0YxVtJUq4IPAlikPgHOOcgCQe81/WaxQdJuPQdmghesk4MZGZM1c LhHTKP64c9xeUCST9MC5sElpr3p3Bc3rcgAaBICiaaL24QZeEOXR4m3ZlGCSFYS/L+zRuWHOPNS Z8FtFJjsAsa0CdMWKlK2dY7pBpa0lU3au4VSBF1OR3kGBVeu1ARQ= X-Google-Smtp-Source: AGHT+IEo6UYr16Vi/E69qC5bNGwqPYAdVm3RjxyONQQ4Gclm79/9D1caK79joNeae+8dBNOx5EUThZkEydizekjJDPg= X-Received: by 2002:a17:907:7d8d:b0:a51:f46a:b000 with SMTP id oz13-20020a1709077d8d00b00a51f46ab000mr57066ejc.20.1713195971803; Mon, 15 Apr 2024 08:46:11 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <202404150105.43F15VoL068210@donotpassgo.dyslexicfish.net> <7lmqszm7n35b5jitwvzagmlc2lecl6p3dhu2bnhri4unnjtlow@f5txrntbo7yw> In-Reply-To: <7lmqszm7n35b5jitwvzagmlc2lecl6p3dhu2bnhri4unnjtlow@f5txrntbo7yw> From: Warner Losh Date: Mon, 15 Apr 2024 09:45:59 -0600 Message-ID: Subject: Re: Question regarding crunchgen(1) binaries To: Shawn Webb Cc: Jamie Landeg-Jones , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000005494690616248505" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4VJBNQ02Jfz4pwm --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 wrote: > On Mon, Apr 15, 2024 at 02:05:31AM +0100, Jamie Landeg-Jones wrote: > > Shawn Webb 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


On Mon, Apr 15, 2024, 8:07=E2=80=AFAM Shawn Webb <<= a href=3D"mailto:shawn.webb@hardenedbsd.org">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 k= ick
> > crunchgen(1) to the curb, we need to modify the build system for<= br> > > /rescue binaries.
>
> Please note, my response is not considering the security aspects you r= aise,
> and is only based on the usefulness of /rescue itself.
>
> Do you mean get rid of /rescue, or just getting rid of crunchgen produ= cing
> 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-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.


>
> 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 wo= uld 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 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.

= 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.

Warn= er


Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubk= eys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.as= c
--0000000000005494690616248505--