Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Mar 2026 18:44:54 +0000
From:      Shawn Webb <shawn.webb@hardenedbsd.org>
To:        Charlie Li <vishwin@freebsd.org>
Cc:        Warner Losh <imp@bsdimp.com>, A FreeBSD User <freebsd@walstatt-de.de>,  Martin Matuska <mm@freebsd.org>, src-committers <src-committers@freebsd.org>,  "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>,  "<dev-commits-src-main@freebsd.org>" <dev-commits-src-main@freebsd.org>
Subject:   Re: git: 8a62a2a5659d - main - zfs: merge openzfs/zfs@f8e5af53e
Message-ID:  <flq55iislddq5ydlcxi7ysmbfimvcnye3ka5awdzeugkhlgkle@hobplnwmptcq>
In-Reply-To: <3f1bdb7c-2812-48de-a329-d34c586cad8b@freebsd.org>
References:  <CANCZdfpaKyzMDL0%2BMk3tSEeqsSU_C-OoWo1Dwwjg%2BG%2BrxiV2Eg@mail.gmail.com> <hqup3oiorbdgvtputen566fcajjoucurqpk7je6qchixat3i6c@zmfpxouvy7vs> <wryftbwxvsc3mhm6iglbx3ikzentaoewo3ldiw4knyqkckmhmo@hnmn3nosgawc> <becfc71c-2ea1-4a13-a3b1-3235f056badf@freebsd.org> <20260321090444.6f81da15@thor.sb211.local> <qeang5o4tlutdyxu2zfksbpljrrvf22eebf6r7b62umffzaymn@or5qwqnmbtbx> <CANCZdfq7YQuzgavRWm=DMKEvxQE9cYOFAEMpgk6faQwOL2tC2Q@mail.gmail.com> <5eaaokkdmmkcojky7362jvkandaard6eu26n77f5z5q7lqutu5@kywp5prvxozj> <CANCZdfrEppttf%2Btu%2BvpHKGd8ikSBpPJ=38cpE%2BsRzD1AjRpFhQ@mail.gmail.com> <3f1bdb7c-2812-48de-a329-d34c586cad8b@freebsd.org>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
On Sat, Mar 21, 2026 at 02:40:27PM -0400, Charlie Li wrote:
> Warner Losh wrote:
> > 
> > 
> > On Sat, Mar 21, 2026 at 9:23 AM Shawn Webb <shawn.webb@hardenedbsd.org
> > <mailto:shawn.webb@hardenedbsd.org>> wrote:
> > 
> >     On Sat, Mar 21, 2026 at 09:18:20AM -0600, Warner Losh wrote:
> >      > On Sat, Mar 21, 2026, 9:08 AM Shawn Webb
> >     <shawn.webb@hardenedbsd.org <mailto:shawn.webb@hardenedbsd.org>> wrote:
> >      >
> >      > > On Sat, Mar 21, 2026 at 09:04:17AM +0100, A FreeBSD User wrote:
> >      > > > Am Tage des Herren Fri, 20 Mar 2026 23:27:20 -0400
> >      > > > Charlie Li <vishwin@freebsd.org <mailto:vishwin@freebsd.org>>
> >     schrieb:
> >      > > >
> >      > > > > Shawn Webb wrote:
> >      > > > > > On Tue, Mar 17, 2026 at 04:52:16PM +0000, Shawn Webb wrote:
> >      > > > > >> On Tue, Mar 17, 2026 at 10:44:59AM -0600, Warner Losh wrote:
> >      > > > > >>> On Tue, Mar 17, 2026 at 10:36 AM Shawn Webb <
> >      > > shawn.webb@hardenedbsd.org <mailto:shawn.webb@hardenedbsd.org>>
> >      > > > > >>> wrote:
> >      > > > > >>>
> >      > > > > >>>> Hey Martin,
> >      > > > > >>>>
> >      > > > > >>>> On Sat, Mar 14, 2026 at 01:26:23PM +0000, Martin
> >     Matuska wrote:
> >      > > > > >>>>> The branch main has been updated by mm:
> >      > > > > >>>>>
> >      > > > > >>>>> URL:
> >      > > > > >>>>
> >      > > https://cgit.FreeBSD.org/src/commit/?
> >     id=8a62a2a5659d1839d8799b4274c04469d7f17c78 <https://
> >     cgit.FreeBSD.org/src/commit/?
> >     id=8a62a2a5659d1839d8799b4274c04469d7f17c78>
> >      > >
> >      > > > > >>>>>
> >      > > > > >>>>> commit 8a62a2a5659d1839d8799b4274c04469d7f17c78
> >      > > > > >>>>> Merge: f91464171d61 f8e5af53e92f
> >      > > > > >>>>> Author:     Martin Matuska <mm@FreeBSD.org>
> >      > > > > >>>>> AuthorDate: 2026-03-14 12:14:56 +0000
> >      > > > > >>>>> Commit:     Martin Matuska <mm@FreeBSD.org>
> >      > > > > >>>>> CommitDate: 2026-03-14 12:14:56 +0000
> >      > > > > >>>>>
> >      > > > > >>>>> [snip for brevity]
> >      > > > > >>>>>
> >      > > > > >>>>>      Obtained from:  OpenZFS
> >      > > > > >>>>>      OpenZFS commit:
> >     f8e5af53e92fa7c03393fbd4922cb9c1d0c15920
> >      > > > > >>>>
> >      > > > > >>>> This commit seems to cause issues when building boot
> >     loader
> >      > > related
> >      > > > > >>>> code:
> >      > > > > >>>>
> >      > > > > >>>> ==== BEGIN LOG ====
> >      > > > > >>>> 114232 bytes available
> >      > > > > >>>> btxld -v -f aout -e 0x200000 -o loader_simp -l
> >      > > > > >>>> /usr/obj/usr/src/amd64.amd64/stand/i386/btx/btxldr/
> >     btxldr  -b
> >      > > > > >>>> /usr/obj/usr/src/amd64.amd64/stand/i386/btx/btx/btx
> >      > > loader_simp.bin
> >      > > > > >>>> kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M
> >     pgctl=0:58
> >      > > > > >>>> client: fmt=elf size=5e2e8 text=57930 data=514c
> >     bss=7470 entry=0
> >      > > > > >>>> output: fmt=aout size=61000 text=1000 data=5f000
> >     org=200000
> >      > > entry=200000
> >      > > > > >>>> ===> stand/i386/pxeldr (all)
> >      > > > > >>>> -560 bytes available
> >      > > > > >>>> *** Error code 1
> >      > > > > >>>>
> >      > > > > >>>
> >      > > > > >>> What all do you have enabled? The defaults aren't even
> >     close to
> >      > > running out
> >      > > > > >>> of space (though I've not looked at this).
> >      > > > > >>
> >      > > > > >> Hey Warner,
> >      > > > > >>
> >      > > > > >> Thanks for reaching out! I've uploaded `make showconfig`
> >     here:
> >      > > > > >> https://hardenedbsd.org/~shawn/2026-03-17_srcconf-
> >     r01.txt <https://hardenedbsd.org/~shawn/2026-03-17_srcconf-r01.txt>;
> >      > > > > >>
> >      > > > > >> The following options are specific to HardenedBSD (in no
> >     particular
> >      > > > > >> order):
> >      > > > > >>
> >      > > > > >> 1. MK_HBSD_UPDATE
> >      > > > > >> 2. MK_HBSDCONTROL
> >      > > > > >> 3. MK_PIE
> >      > > > > >> 4. MK_RELRO
> >      > > > > >> 5. MK_SHLIBRANDOM
> >      > > > > >> 6. MK_ZERO_REGS
> >      > > > > >> 7. MK_SPECTREV1_FIX
> >      > > > > >> 8. MK_SAFESTACK
> >      > > > > >> 9. MK_RETPOLINE
> >      > > > > >> 10. MK_LTOLIB
> >      > > > > >> 11. MK_CFI
> >      > > > > >
> >      > > > > > MK_RETPOLINE was the culprit. Something about this ZFS
> >     commit causes
> >      > > > > > LLVM to emit more retpoline entries than before--too many
> >     for a
> >      > > little
> >      > > > > > bootloader. That might be something to investigate later,
> >     but only to
> >      > > > > > satisfy a curious mind, not to actuall fix anything
> >     (since nothing's
> >      > > > > > actually broken.)
> >      > > > > >
> >      > > > > > Since it doesn't really make sense to apply speculative
> >     execution
> >      > > > > > mitigations to a bootloader, I disabled retpoline for a
> >     components
> >      > > > > > in stand/.
> >      > > > > >
> >      > > > > > Good to go.
> >      > > > > >
> >      > > > > Also just got bit by this, albeit during the lua loader,
> >     since I have
> >      > > > > WITH_RETPOLINE in my src.conf.
> >      > > > >
> >      > > >
> >      > > > Hello,
> >      > > >
> >      > > > I do not have WITH_RETPOLINE in my /etc/src.conf, but since I
> >     got this
> >      > > mysterious error about
> >      > > > not enough bytes left, I use WITHOUT_LOADER_PXEBOOT= YES (due
> >     to issues
> >      > > with WITH_BEARSSL=YES
> >      > > > also used).
> >      > > > Despite not using any WITH_RETPOLINE I also catch the error ...
> >      > >
> >      > > Something about this ZFS commit causes the boot laoder to be
> >     too big.
> >      > > I guess the first sign of trouble was with retpolines, but
> >     there seem
> >      > > to now be additional signs.
> >      > >
> >      > > What's the process for filing a bug report against OpenzFS for
> >      > > something like this? (Not asking you directly, just a general
> >     question
> >      > > for the thread.)
> >      > >
> >      >
> >      > That's a good question. We are rapidly aporoaching the day we
> >     will have to
> >      > freeze the set of zfs feature that we can boot with the BIOS
> >     path. There's
> >      > only so much space.
> >      >
> >      > Right now,  there's little to no bootloader testing, let alone
> >     analysis
> >      > done and that will need to change.
> > 
> >     Another question might also be: is it worth the time and effort? Are
> >     people really using a ZFS-enabled traditional MBR BIOS bootloader on
> >     FreeBSD 16-CURRENT (or eventual 16.0-RELEASE)? From my rather naive
> >     (and ignorant, since I don't know FreeBSD's userbase well), it seems
> >     like folks use either loader.efi or u-boot (or both!)
> > 
> > 
> > Nobody uses MBR BIOS bootloader. It's totally unsupported. They all use the
> > GPT one, which is used for all kinds of things, most recently several
> > light-weight
> > VM systems that don't have UEFI. BIOS is what imposes the limit, not MBR.
> > 
> > But there's a huge number of systems that are already in the field that need
> > to be upgradeable, but we will eventually need to draw a line in the
> > sand for
> > that.
> > 
> The machine where I hit this error on building the lua loader is a BIOS-GPT
> system.

I apologize for my incorrect statements. The inclusion of MBR was
erroneous. Warner's got it right. :-)

I've completely forgotten about gptzfsboot. Been so long and memory's
a fuzzy thing.

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Signal Username:  shawn_webb.74
Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmm+5x4ACgkQ/y5nonf4
4fq/9Q/9GnHaL8k8sIx5QhehAo+xgDxxXXDmjBBStiiDpmKeXO59MCjCeSgHi2Rm
o6FxdduPbL2cu62PiiZmS1NFpnnPg7Clnc+zkeuXEAveGDCek4lfTfDOmNdJa90+
CGo+ajjA2Q7n2O5ml0FqcK+veonzc1H+ytS3LH6LXwGac9Qq5sQy3afkDtlYRBkh
eWLzJLHQnGvbJvzOUGREwzE9wzqB3/ZC+q+lJONdrBot54hPsEgVC24EkjxXCt6z
C17QJALW4R1sjHW9FohfzMCvh1V6iI3a+Ah9PeWdSF72mXV7j/6xPtKB+RqXBVWE
vfAB8axCteSx4x2CVxl8oRVNqNJ+VUNzAHpiiYoNvmWb3yLiFC8gklA8FeE2s9Ng
nOt01y3ZTmdDG8IX5ZzGr5cw/WjVvxtUHShaPLFBh1pfCAGebUD+lKV9a290pNUq
QtUJcF6K1S8HhDN5unQy2JaTvbTRIssTYN9UdwQoGQXXWARV8rVIonG16Gq8g4IN
aDgNzYM+ziv2k9YIZz6UNNLVqVZurfB6gmUHtUgZp2vkOKrBiN1cBRgOZ90PSBv1
1eorv+TqTLTqyyn8UMptQ6egE+X5ZEa2Fo/Jm9gYtabppcmqo1lQA5Fq8odC8DCJ
rOTJihnYyapqS7m116Wdq70dGohwp3uCJKVNYZSRwrd0bgMFIHA=
=dFvN
-----END PGP SIGNATURE-----
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?flq55iislddq5ydlcxi7ysmbfimvcnye3ka5awdzeugkhlgkle>