261–270 of 406 posts
If you create a ZFS filesystem on a non-macOS, you have to be careful about Unicode mapping in order to use it safely on MacOS. I have no idea if Unicode is an issue for Apple File System. Emoji file names, you guys.
But are they 3x bigger?
Earlier quoted context omitted.
Why would you need encryption for the Secure Boot chain? Would you not rather sign the base system image for that purpose?
You'd have to sit there and read the entire base system image before booting to verify that signature. But only have to decrypt a block when it comes time to read that block—with the ability to kernel-abort right then during the boot process if the block doesn't decrypt. (Or were you suggesting individually signing every block?)
There's no such thing as "the block doesn't decrypt" absent MACs/MICs or AEAD schemes -- encryption and decryption are just maps from N bytes to N bytes.
Earlier quoted context omitted.
The point of encrypting the base system image is mostly to make it part of the Secure Boot chain. rootless is a policy control to stop processes from modifying the OS from inside. An encrypted system image stops things with hardware access (but not the unlock key) from modifying the OS from the outside . You can trust any disk whose blocks you can decrypt with key X, to have been only written to by someone with key X…
thanks for mansplaining rootless and encryption (/s). Encryption is not authentication, so it does not prevent unnoticed modification. And secure boot only really depends on authentication and not on encryption, so you are conflating two different concepts. No you cant just trust the data, replay attacks over time and space are still an issue.
It's certainly more secure (indeed, it prevents replay attacks) to just keep a big block-hash table, update it when blocks change, and then hash that table and sign it on fsync—but it's costly in a few ways over just trusting unauthenticated encryption, and was even moreso five-to-eight years ago when Secure Boot was being formulated.
These days, you see a lot of wholly-signed read only OS images—the OSX recovery partition is signed; CoreOS signs its OS images; most firmware is signed; etc. But I don't expect the unauthenticated-encryption on most computers' read-write rootfs will be replaced by a signed-but-unencrypted filesystem any time soon—if just for the fact that consumers really seem to hate the idea of separate OS and data partitions, especially when the OS partition is "stealing space" they could be using for data. (The only thing I can think of that might finally kill this making the default install on some consumer-OS create a thin pool, such that an OS partition that only contains 5G of data only "steals" 5G of their "space.")
Or, y'know, authenticated encryption. Do any block-device cryptosystems support an AEAD mode yet? LUKS maybe?
Earlier quoted context omitted.
"FileVault: APFS volumes cannot currently be encrypted using FileVault. " This one is confusing, because this is a logical volume feature. Not sure how or why APFS would ever care that some layer above it is encrypting stuff.
Err, per [1] > APFS supports encryption natively. You can choose one of the following encryption models for each volume in a container: no encryption, single-key encryption, or multi-key encryption with per-file keys for file data and a separate key for sensitive metadata. APFS encryption uses AES-XTS or AES-CBC, depending on hardware. Multi-key encryption ensures the integrity of user data even when its physical sec…
Most apple volumes are already logical volumes (check diskutil list).
FileVault itself is, right now, implemented as part of corestorage (see diskutil cs for the encryption/decryption commands).
I assume they decided they just wanted to go the entire ZFS route and get rid of core storage in favor of a pool model, but still ...
Earlier quoted context omitted.
Between the ZFS-like features and the advertised "novel copy-on-write metadata" scheme, I would not be surprised if it was partially based on DragonFly's HAMMER/HAMMER2 filesystem.
If you poke around in the the APFS kernel extension, it's not a very big binary, given the feature set. (It's a 550K extension, compared to the 2.5MB zfs.ko on FreeBSD.) I haven't disassembled it yet, but I'd wager that APFS is layered atop Core Storage btrees/CoW. Since that code's been shipping since 2011, maybe APFS stabilizes faster than a true greenfield filesystem? (That does leave me wondering how interesting…
hammer.ko is 494KB in the latest DFBSD, for those wondering the obvious.
The spartan description of APFS certainly sounds like the (partial) feature list for ZFS--the comparisons made in the comments here are on-point. ZFS though took around 5 years to ship and, arguably, another 5-10 to get right. I say this having shipped multiple products based on ZFS, writing code in ZFS, and diagnosing production problems with it. On-disk consistency ("crash protection"), snapshots, encryption, and t…
It's impossible to know how long they have been working on it. As I recall, Swift had been in development for 3+ years before it saw the light of day.
Earlier quoted context omitted.
(raw) flash and spinning rust are fundamentally different, because spinning rust drives provide a READ SECTOR and WRITE SECTOR primitive, while raw flash provides READ SECTOR, ERASE (large) BLOCK, WRITE (small) SECTOR primitives. Stuff like UBIFS do try to move the wear leveling code into the OS. But the big players like Windows' NTFS and Mac's HFS were originally designed for the spinning rust primitive, so I guess…
They have their secret sauce so that legacy software can pretend the SSD is spinning rust. Let them. Why shouldn't we also demand standard low level primitives so that every OS can do the thing you're describing?