Date: Thu, 15 Dec 2022 16:46:10 -0500 From: "David E. Cross" <david@crossfamilyweb.com> To: Andreas Kempe <kempe@lysator.liu.se> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available Message-ID: <30730b82-9c37-3e12-0bc5-78b02df269a4@crossfamilyweb.com> In-Reply-To: <B73C5CBC-57B8-415F-BA2F-659657F6F728@crossfamilyweb.com> References: <Y5otAxXCMcmxBBYZ@claptrap.lysator.liu.se> <B73C5CBC-57B8-415F-BA2F-659657F6F728@crossfamilyweb.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On 12/14/22 20:10, David Cross wrote:
> The drafts never made it out, doesn’t seem there is a distinction there
>
>> On Dec 14, 2022, at 3:08 PM, Andreas Kempe <kempe@lysator.liu.se> wrote:
>>
>> On Wed, Dec 14, 2022 at 02:51:51PM -0500, David Cross wrote:
>>>>> On Dec 14, 2022, at 12:11 PM, Andreas Kempe <kempe@lysator.liu.se> wrote:
>>>> On Sun, Dec 11, 2022 at 08:29:18PM -0700, Warner Losh wrote:
>>>>>> On Sun, Dec 11, 2022, 8:10 PM David Cross <david@crossfamilyweb.com> wrote:
>>>>>>
>>>>>> One would hope. This is now the third time this has been reported. At
>>>>>> least. I even personally wrote a draft en for it (for 13.1). And 2 other
>>>>>> ENs yet to see a release, also with bugs and patches and fixes committed to
>>>>>> -CURRENT
>>>>>>
>>>>>
>>>>> EN s are hard to do as a developer. We do very few of them. Since they are
>>>>> hard, I just don't bother. That needs to change...
>>>>>
>>>> If ENs are difficult to do, would it at least be possible to add a
>>>> notice under Late-Breaking News with a warning? To me, having a system
>>>> that won't boot is a quite nasty surprise.
>>>>
>>> I wrote draft ENs for these already. Give me a few and I’ll send them on again
>>>
>> Thank you! I misinterpreted you as your drafts having been rejected.
>>
>> Best regards,
>> Andreas Kempe
>>
>
Sorry for the previous top-posting. I will get better.
Anyway, here are the 3 draft ENs I wrote earlier, submitted 8/30/2022.
All 3 were actually reported by other people (I just happened to hit
them independently), all 3 had patches submitted and were in GIT in
-CURRENT.
While all 3 affect 'nonstandard' options (geli root disk isn't standard,
compiling with other options isn't standard), all of these things are
supposed to work, and the patches involved are trivial. The geli one
itself is such a HUGE problem it has to be addressed IMO. When I wrote
these drafts 12.4 wasn't a thing, so they need to be updated. Also
there are sections that need to be corrected also, I was trying to do
the heavy lift of describing the problem, workarounds, impact, etc.
Things like the specific patches need to come from git after merges/etc.
[-- Attachment #2 --]
=============================================================================
FreeBSD-EN-ERRATA_TEMPLATE Errata Notice
The FreeBSD Project
Topic:
Category: core
Module: loader
Announced: 2022-XX-XX
Credits:
Affects: FreeBSD 13.1
Corrected: ????
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:https://security.FreeBSD.org/>.
I. Background
geli is an encrpytion component of the GEOM subsystem of FreeBSD that
allows partitions or disks to be encrypted. Both the kernel and loader(8)
have support to allow booting from encrypted disks and prompting for a
password at boot time.
II. Problem Description
A change to libstand(3) sometime between 13.0 and 13.1 prevents loader from
recognizing the partition after the built in geli driver has attached the
partition , preventing auto booting of encrypted root partitions.
This bug was tracked at:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282
III. Impact
Systems running 13.1 with encrypted root disks will not autoboot.
IV. Workaround
Systems affected may revert to loader(8) from 13.0. Additionally
setting currdev and rootdev to the correct partition manually will
allow booting of the system.
Systems without geli root disk encryption are unaffected.
V. Solution
PATCH
Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date.
[XX Needs reboot? Mention please]
Perform one of the following:
1) To update your system via a binary patch:
Systems running a RELEASE version of FreeBSD on the amd64, i386, or
(on FreeBSD 13 and later) arm64 platforms can be updated via the
freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
*** Reboot needed to validate fix ***
2) To update your system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 13.1]
# fetch https://security.FreeBSD.org/patches/EN-XX:XX/XXXX.patch
# fetch https://security.FreeBSD.org/patches/EN-XX:XX/XXXX.patch.asc
# gpg --verify XXXX.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
<for a userland utility:>
c) Recompile the operating system using buildworld and installworld as
described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>.
VI. Correction details
This issue is corrected by the corresponding Git commit hash or Subversion
revision number in the following stable and release branches:
Branch/path Hash Revision
-------------------------------------------------------------------------
stable/13/ XXXXXXXXXXXX stable/13-nXXXXXX
releng/13.1/ XXXXXXXXXXXX releng/13.1-nXXXXXX
-------------------------------------------------------------------------
For FreeBSD 13 and later:
Run the following command to see which files were modified by a
particular commit:
# git show --stat <commit hash>
Or visit the following URL, replacing NNNNNN with the hash:
<URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN>;
To determine the commit count in a working tree (for comparison against
nNNNNNN in the table above), run:
# git rev-list --count --first-parent HEAD
VII. References
<other info on the problem>
<URL:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=XXXXXX>;
The latest revision of this advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-XX:XX.XXXXX.asc>;
[-- Attachment #3 --]
=============================================================================
FreeBSD-EN-ERRATA_TEMPLATE Errata Notice
The FreeBSD Project
Topic:
Category: core
Module: LLVM
Announced: 2022-XX-XX
Credits:
Affects: Unsure? 13.1 definitely, bug report references 12.x
but unsure if that made it to a -RELEASE
Corrected: 2022-XX-XX XX:XX:XX UTC (stable/13, 13.1-STABLE)
2022-XX-XX XX:XX:XX UTC (releng/13.1, 13.1-RELEASE-pXX)
2022-XX-XX XX:XX:XX UTC (releng/13.0, 13.0-RELEASE-pXX)
2022-XX-XX XX:XX:XX UTC (stable/12, 12.3-STABLE)
2022-XX-XX XX:XX:XX UTC (releng/12.3, 12.3-RELEASE)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:https://security.FreeBSD.org/>.
I. Background
LLVM is a third party compiler that is distributed as part of base.
FreeBSD uses this compiler to convert source code to system object code
for the kernel, libraries, system utilities, and ports.
AVX is a set of instructions on Intel processors that speed certain
vector computing operations. AVX-512 is a specific version of these
instructions available on specific CPUs.
II. Problem Description
FreeBSD and LLVM allow various options to be set to tailor the system
to specific environments by setting build parameters that affect linking,
optimization, and target CPU. The version of LLVM included with
FreeBSD 13.1 (and maybe 12.x?) includes a bug with certain target CPUs
using AVX-512 instructions that causes the compiler to enter an infinite
loop, eventually terminating when it has used all available memory.
III. Impact
When compiling certain libraries or applications with the system LLVM
in 13.1 (and maybe 12.x?) the compiler will hang.
IV. Workaround
Removing the CPUTYPE option from /etc/make.conf, or by setting it to a
CPUTYPE that does not have AVX512 will prevent the infinite loop.
Settin the CPUTYPE is a non-default setting, systems using default
configurations are unaffected.
V. Solution
Patch from : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264394
Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date.
[XX Needs reboot? Mention please]
Perform one of the following:
1) To update your system via a binary patch:
Systems running a RELEASE version of FreeBSD on the amd64, i386, or
(on FreeBSD 13 and later) arm64 platforms can be updated via the
freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
[XX Needs reboot? Mention please]
2) To update your system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 13.1]
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
<for a userland utility:>
c) Recompile the operating system using buildworld and installworld as
described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>.
VI. Correction details
This issue is corrected by the corresponding Git commit hash or Subversion
revision number in the following stable and release branches:
Branch/path Hash Revision
-------------------------------------------------------------------------
stable/13/ XXXXXXXXXXXX stable/13-nXXXXXX
releng/13.1/ XXXXXXXXXXXX releng/13.1-nXXXXXX
releng/13.0/ XXXXXXXXXXXX releng/13.0-nXXXXXX
stable/12/ rXXXXXX
releng/12.3/ rXXXXXX
-------------------------------------------------------------------------
For FreeBSD 13 and later:
Run the following command to see which files were modified by a
particular commit:
# git show --stat <commit hash>
Or visit the following URL, replacing NNNNNN with the hash:
<URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN>;
To determine the commit count in a working tree (for comparison against
nNNNNNN in the table above), run:
# git rev-list --count --first-parent HEAD
For FreeBSD 12 and earlier:
Run the following command to see which files were modified by a particular
revision, replacing NNNNNN with the revision number:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>;
VII. References
<other info on the problem>
<URL:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=XXXXXX>;
The latest revision of this advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-XX:XX.XXXXX.asc>;
[-- Attachment #4 --]
=============================================================================
FreeBSD-EN-ERRATA_TEMPLATE Errata Notice
The FreeBSD Project
Topic:
Category: core
Module: bhyve
Announced: 2022-XX-XX
Credits:
Affects: 13.1
Corrected: 2022-XX-XX XX:XX:XX UTC (stable/13, 13.1-STABLE)
2022-XX-XX XX:XX:XX UTC (releng/13.1, 13.1-RELEASE-pXX)
For general information regarding FreeBSD Errata Notices and Security
Advisories, including descriptions of the fields above, security
branches, and the following sections, please visit
<URL:https://security.FreeBSD.org/>.
I. Background
bhyve is the FreeBSD hypervisor, loader is the FreeBSD boot loader,
userboot.so is a version of loader that runs in userland as part of the
bhyveload process to setup the bhyve environemnt for executing a FreeBSD
guest operating system under bhyve.
BIND_NOW is a system hardening setting that makes certain types of
memory corruption more difficult.
II. Problem Description
Compiling the world with BIND_NOW (a non-default option) results in a
version of userboot.so that will not link with bhyveload, preventing
setup and execution of FreeBSD based guest operating systems with the
bhyve VM.
III. Impact
Systems that choose this hardening option are unable to run the default
type of FreeBSD VM under bhyve.
IV. Workaround
Multiple workarounds exist.
a) Removing BIND_NOW from system build options in src.conf and rebuilding
b) using UEFI based bhyve VMs (not available on all hardware)
c) using a different version of userboot.so via the -l option to
bhyveload. For example one saved in an alternate location after a build
without BIND_NOW
V. Solution
Apply patch from:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262920
Upgrade your system to a supported FreeBSD stable or release / security
branch (releng) dated after the correction date.
Does not need reboot.
Perform one of the following:
1) To update your system via a binary patch:
Systems running a RELEASE version of FreeBSD on the amd64, i386, or
(on FreeBSD 13 and later) arm64 platforms can be updated via the
freebsd-update(8) utility:
# freebsd-update fetch
# freebsd-update install
[XX Needs reboot? Mention please]
2) To update your system via a source code patch:
The following patches have been verified to apply to the applicable
FreeBSD release branches.
a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.
[FreeBSD 13.1]
# fetch https://security.FreeBSD.org/patches/EN-XX:XX/XXXX.patch
# fetch https://security.FreeBSD.org/patches/EN-XX:XX/XXXX.patch.asc
# gpg --verify XXXX.patch.asc
b) Apply the patch. Execute the following commands as root:
# cd /usr/src
# patch < /path/to/patch
<for a userland utility:>
c) Recompile the operating system using buildworld and installworld as
described in <URL:https://www.FreeBSD.org/handbook/makeworld.html>.
VI. Correction details
This issue is corrected by the corresponding Git commit hash or Subversion
revision number in the following stable and release branches:
Branch/path Hash Revision
-------------------------------------------------------------------------
stable/13/ XXXXXXXXXXXX stable/13-nXXXXXX
releng/13.1/ XXXXXXXXXXXX releng/13.1-nXXXXXX
releng/13.0/ XXXXXXXXXXXX releng/13.0-nXXXXXX
stable/12/ rXXXXXX
releng/12.3/ rXXXXXX
-------------------------------------------------------------------------
For FreeBSD 13 and later:
Run the following command to see which files were modified by a
particular commit:
# git show --stat <commit hash>
Or visit the following URL, replacing NNNNNN with the hash:
<URL:https://cgit.freebsd.org/src/commit/?id=NNNNNN>;
To determine the commit count in a working tree (for comparison against
nNNNNNN in the table above), run:
# git rev-list --count --first-parent HEAD
For FreeBSD 12 and earlier:
Run the following command to see which files were modified by a particular
revision, replacing NNNNNN with the revision number:
# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
Or visit the following URL, replacing NNNNNN with the revision number:
<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>;
VII. References
<other info on the problem>
<URL:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=XXXXXX>;
The latest revision of this advisory is available at
<URL:https://security.FreeBSD.org/advisories/FreeBSD-EN-XX:XX.XXXXX.asc>;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?30730b82-9c37-3e12-0bc5-78b02df269a4>