boot1-compatible GELI and GPT code?

[Eric McCorkle]

On Mar 20, 2016, at 14:43, Allan Jude <allanjude at freebsd.org> wrote:
> 
> I presented a paper on my work in this area (booting from a GELI
> encrypted partition, it does not GELI encrypt the GPT table) at
> AsiaBSDCon last weekend, and committed it this week.
> 
> Here is the paper: http://allanjude.com/bsd/AsiaBSDCon2016_geliboot.pdf
> 
> The commit was: r296963 https://svnweb.freebsd.org/changeset/base/296963

Thanks, I'll check it out.

> I am interested in applying this work to UEFI as well.

I've got a branch going on my github.  I've pushed some initial code that adds "provider modules" to boot, which basically consume a device and produce more devices.  I haven't actually written any provider modules yet though.

https://github.com/emc2/freebsd/tree/geli_efi

> Is there much advantage to encrypted the GPT table as well? Currently my
> setup leaves the partition table, and the code up to boot2 unencrypted.
> Only encrypting the actual OS partition (/boot/{zfs,}loader,
> /boot/kernel, etc). Swap is encrypted separately with a unique
> throw-away key per reboot.

Generally speaking, the less knowledge an attacker has, the better.  If they know the filesystems types (obtainable from the GPT), then they know the locations of the superblocks and likely can guess at least some of the contents.  They also may be able to glean information from which sectors changed of they can observe the disk multiple times over time.  By contrast, if all they have is a big encrypted block, it's harder to infer anything about what's inside.