Date: Sat, 28 May 2016 09:37:29 -0400 From: Eric McCorkle <eric@metricspace.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: EFI GELI support ready for testers Message-ID: <10841E12-488A-4B96-BD1D-832A5B3F7471@metricspace.net> In-Reply-To: <20160528083656.GT38613@kib.kiev.ua> References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Full-disk encryption is a powerful security feature, and one which is availa= ble in one form or another in every major competing OS. It is a requirement= for data protection in many organizations, and something that many individu= als desire to help protect their data. In EFI, there is an EFI System Partition (ESP) which is expected to be forma= tted with msdosfs. This contains the boot1 program. This must be unencrypt= ed in order for EFI to be able to read it (unless you do something fancy wit= h coreboot or whatever). That is the only thing that needs to live on the E= SP, and the only thing that needs to be stored as plaintext. The rest of th= e system past that point can reside on encrypted partitions. Without suppor= t for GELI in the boot1/loader code, you have to keep part of the system une= ncrypted. Making it so that only boot1 has to be stored as plaintext dramatically redu= ces the attack surface. It can also be combined with EFI secure boot to cre= ate a powerful tamper-resistance scheme, wherein a per-machine private key i= s stored on the encrypted disk and used to sign boot1. This prevents an att= acker from modifying boot1, as they would need the signing key to do that, b= ut they can't get it without decrypting the disk. I'll also mention that my changes actually delete quite a bit of code and re= move the boot1-specific filesystem backends, so that boot1 and loader now us= e the same filesystem and backend code. > On May 28, 2016, at 04:36, Konstantin Belousov <kostikbel@gmail.com> wrote= : >=20 >> On Fri, May 27, 2016 at 07:39:57PM -0400, Eric McCorkle wrote: >> I am pleased to announce that my work to add support for GELI in the EFI b= oot loader (as well as perform more general refactoring) is now ready for te= sting. I am able to successfully detect multiple GELI partitions in boot1 a= nd pass the keys into the kernel. >=20 > Can somebody explain in which way this is useful ? > Same question for the GELI code for non-EFI loader. >=20 > BIOS cannot read raw data from the encrypted partition, so you need > either old boot or the loader and some additional data on EFI boot > partition anyway. >=20 > Features adds significant amount of code, which must be maintained in > parallel with the kernel code. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10841E12-488A-4B96-BD1D-832A5B3F7471>