EFI GELI support ready for testers

[Karl Denninger]

On 6/1/2016 10:14, Allan Jude wrote:
> On 2016-06-01 10:47, Joerg Sonnenberger wrote:
>> On Wed, Jun 01, 2016 at 04:29:16PM +0200, Wojciech Puchar wrote:
>>>> It's undesirable because the whole point of ZFS is to have one ZFS
>>>> volume for the whole system.
>>> This sounds more like a religious dogma than anything else.
>>
>> If "ZFS volume" means "ZFS pool" here, it is also blatant bullshit.
>> There are a lot of reasons for having more than one ZFS pool, the
>> easiest being separating SSDs and HDDs for fast vs cheap storage.
>>
>> Joerg
>> _______________________________________________
>> freebsd-hackers at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to
>> "freebsd-hackers-unsubscribe at freebsd.org"
>>
>
> Again, my only motivation for adding GELI encryption support to
> gptzfsboot was to allow ZFS Boot Environments, one of the biggest
> selling features of ZFS-on-root, to work with GELI encrypted disks.
>
> For boot environments to work, your kernel must reside in the / (root)
> ZFS dataset, so it can be snapshotted and cloned along with the rest
> of the base system.
>
> You can still use multiple pools.
>
> But for this useful feature to work, you need to be able to use a
> single pool, so I made it so. I added support for UFS, because it was
> only ~10 more lines of code.
>
> In my geliboot work, no new crypto code is introduced. It just reuses
> GELI and OpenCrypto.
>
> The entire geliboot codebase is only 450 lines including license and
> comments, mostly of boilerplate, and 100 lines of .h file to bridge
> the gap between the kernel and the boot2/loader environments.
>

I just want to add to this -- using Geli-encrypted volumes is fine as
things sit now, _*but*_ you cannot do so _*and*_ have BEADM (boot
environments) work properly which is a huge problem from a standpoint of
deployment and maintainability for complex installations /where//kernel
and system updates are made from time to time to either fix bugs or roll
forward new versions.

/This becomes a quite-material issue as security problems are found and
fixed.  With BE you clone the running environment, install the patch
onto the cloned copy and reboot.  Further, the previous (unpatched) copy
remains available until you wish to dump it should there prove to be a
problem with the patch or update you deployed.
/
/BE is a big deal in this regard, as it makes reverting such a change a
near-instant operation if it goes sideways on you and sometimes these
sorts of things *do* go sideways.  Without root-on-boot for the booting
pool, however, you have to manually sync things back and forth and the
risk of a mistake is quite high -- and a mistake can cost you data on a
production system.

Reducing the attack surface (somewhat) is a (convenient) side effect;
the real benefit is in maintainability as patches and new versions are
released.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20160601/57b25b47/attachment.bin>