Date: Sat, 28 May 2016 16:02:43 -0400 From: Eric McCorkle <eric@metricspace.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Allan Jude <allanjude@freebsd.org>, freebsd-hackers@freebsd.org Subject: Re: EFI GELI support ready for testers Message-ID: <6A9DADE0-B214-424A-BB14-0B0848F0D08D@metricspace.net> In-Reply-To: <20160528172618.GB38613@kib.kiev.ua> References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> <d6b96a6c-4e92-35a5-e78b-cc674b6d2f25@freebsd.org> <20160528172618.GB38613@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> On May 28, 2016, at 13:26, Konstantin Belousov <kostikbel@gmail.com> wrote= : >=20 >> On Sat, May 28, 2016 at 10:27:40AM -0400, Allan Jude wrote: >>> On 2016-05-28 04:36, Konstantin Belousov wrote: >>>> 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= boot loader (as well as perform more general refactoring) is now ready for t= esting. 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.or= g" >>=20 >> The motivation for my work (GELI in boot2 and loader for non-EFI boot) >> was supporting ZFS boot environments. Previously, when you use GELI you >> needed to have two ZFS pools, one for an unencrypted /boot and one for >> the encrypted / >>=20 >> This breaks ZFS boot environments, since a snapshot of the root file >> system won't include the correct kernel etc. > Why cannot /boot included into the boot environment ? > When I last saw Solaris, somewhere in its 10-th, any amount of > filesystems could be added to the bootenv. But whatever the definition > of bootenv is used, it exists at a level of the shell scripts and selectin= g > the actual partition for loader. Throw thousand lines of code into > the unstable and very hard to debug environment of loader looks somewhat > unproductive. You misunderstand. Alan was talking about pure ZFS systems, where there is o= ne big ZFS pool holding everything. You need to be able to access /boot obv= iously, but ZFS does not allow you to assign separate out data on to a singl= e device. It creates a pool, which combines all devices. To have /boot unencrypted, you have to have a separate partition for just /b= oot, which is undesirable. >>=20 >> The final version of my geliboot took an extra effort to reuse the AES >> code from sys/crypto/rijndael and sys/opencrypto and GELI directly from >> sys/geom/eli to avoid maintaining a separate copy of that code in sys/boo= t > Which means that kernel code must be also runnable in the strange and > incompatible environment of the loader. I cannot see how this reduces > code maintanability even a bit. I am already rather unhappy about ZFS > kernel code being compiled as the userspace library, which hurt me > and other people more than once. Now (?) the kernel code must be also > verified for the loader. I mean, the loader has to be able to access the filesystems, there's no way a= round it (barring crazy coreboot stuff). Also, it should be possible to create a synthetic EFI test-harness that runs= in *userland*. EFI is basically just a bunch of tables of function pointers= , no bios interrupts or anything. As long as you implement the interfaces, a= ny loader should also run in your synthetic environment. I had plans to loo= k into this after this work is done. >>=20 >> Hopefully the work I did to make sys/opencrypto and sys/geom/eli more >> reusable outside of the kernel will make it easier for Eric to do the >> same for the EFI version. >>=20 >> The motivation for the EFI version is the same, ZFS boot environments, >> plus the obvious security advantages of having the kernel stored >> encrypted rather than not. >=20 > Obvious security advantages ? Seriously ? > What is a single 'security' advantage of hiding the kernel ? >=20 There are plenty. Right up at the top, an attacker able to access /boot is free to tamper with= anything, and can insert back-doors into the kernel, loader, or any module.= If you assume that the attacker can't write, then they can still scan the k= ernel and modules for signatures for known vulnerabilities (since the kernel= itself has a commit id and detailed version info, they can compare this aga= inst a CVE database). Even if they can't do that for some reason, they coul= d still potentially exfilt a kernel address map for use in rootkit attacks a= gainst your system. Lastly, general security principles say to minimize the= attack surface, which would definitely mean you should protect the core of t= he system. > Since you noted a 'security', I realized that your changes decrypt the > keys in the pre-kernel environment. In other words, very sensitive > material becoming accessible to strange and unknown code which is > managed by firmware. The likelihood of such an attack, while something I considered, is very low.= A key should look like random binary data (much like the GUIDs prevalent i= n EFI code). I seriously doubt someone could write a firmware module that c= ould dig through the memory state of an arbitrary OS's boot loader and find k= eys. You'd basically have to put a full online binary analysis framework in= the firmware, and have it run fast enough to not be noticed. That would be= some serious Turing award-worthy work kept secret from the world solely to b= uild firmware backdoors. I don't think even Lenovo would go that far. (I know I mentioned scanning the kernel as a threat above; that's an offline= attack that can be done on a copy. Online undetectable analysis of a runni= ng program is WAY harder.) Besides, if someone wants to do evil things in firmware, I think it's far mo= re likely they'd just backdoor the network or USB controllers to let someone= send an override packet and execute bundled code in kernel mode. That work= s every time for every OS and doesn't require surreptitiously picking apart a= rbitrary programs' data structures in real time. For what it's worth, I have considered possible hardening measures: using al= ias GUIDs to disguise interfaces and adding per-build padding or XOR masks t= o structures with keys to throw off scanners. However, I don't think the th= reat is realistic enough to warrant such measures. > Putting aside ineradicable evil of Intel ME or its > AMD twin, and SMM handler, you are exposing keys to whatever code happen > to inhabit the preboot env, not neccessary originating from the firmware > vendor. Secure Boot would not help there, since when the measurement > indicate that untrusted component was there, it is too late. I.e., > you making much easier for malice hacker to steal the keys. I mean, the same argument holds for the kernel, if not moreso. You have ACP= I bytecode, SMM, device blobs, anything that the boot environment chose to k= eep around for runtime by marking that memory as "unavailable", and of cours= e, the evil that is Intel ME. This is an unavoidable risk of having keys in= main memory ever. If you really want any kind of safety from this, you need to use a hardware c= rypto device that stores keys in a separate memory (which, I specifically de= signed things to make it easy to add support for one). Of course, you then h= ave to trust the device... > _______________________________________________ > 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?6A9DADE0-B214-424A-BB14-0B0848F0D08D>