Re: Verified boot and filesystem choices

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2288 bytes --]

On 6/15/25 05:13, Alyssa Ross wrote:
> Demi Marie Obenour <demiobenour@gmail.com> writes:
> 
>> On 6/14/25 04:23, Alyssa Ross wrote:
>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>>
>>>> Bcachefs is not very stable right now,
>>>
>>> Neither is Spectrum!  Given that changing filesystem later if it doesn't
>>> work out will be a very easy change to make (up to a point), we can
>>> afford to wait.  It's an approach that has served us well so far —
>>> sometimes focusing on other things means that by the time we have to
>>> look at something, the problem has been solved by somebody else.
>>>
>>> Filesystems are always going to have bugs, so in my opinion the most
>>> important thing is to make having good backups easy, so that recovery is
>>> possible when something goes wrong, regardless of choice of filesystem.
>>> I am very keen for Spectrum to have an integrated backup solution,
>>> ideally as easy to use as Time Machine.
>>
>> To clarify, I'm not referring to bugs that cause data loss, but to bugs
>> that allow kernel code execution when a maliciously crafted filesystem
>> is mounted.  Backups don't protect against this.  This attack is mostly
>> relevant for kiosks, mobile devices, and other cases where being able
>> to restore trust after a device compromise is critical.
> 
> So are you saying that bcachefs's lack of stability means that it's
> uniquely vulnerable to this sort of vulnerability?  I'd be surprised,
> given that as you say Kent is actually interested in preventing them.

bcachefs isn't hardened against these vulnerabilities *yet*, but BTRFS
is probably not hardened at all.  Also, bcachefs will be rewritten in
Rust, hopefully reducing the impact to denial of service (kernel panic).
This post was about BTRFS, not bcachefs, but I should have been clearer
about this.

One area where bcachefs *does* have a problem is its native encryption,
which is vulnerable to catastrophic nonce reuse due to the limited
96-bit nonce size of ChaCha20.  They need to use XChaCha20-Poly1305,
which has a 192-bit nonce.  Also, truncating the authentication tag is
usually a bad idea, though not *always*.  However, this problem with
bcachefs can be fixed.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]