From owner-freebsd-hackers@freebsd.org Sat May 28 17:26:25 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D342B4DA6E for ; Sat, 28 May 2016 17:26:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9D4241FAE; Sat, 28 May 2016 17:26:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u4SHQJoU092097 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 28 May 2016 20:26:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u4SHQJoU092097 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u4SHQICv092096; Sat, 28 May 2016 20:26:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 28 May 2016 20:26:18 +0300 From: Konstantin Belousov To: Allan Jude Cc: freebsd-hackers@freebsd.org Subject: Re: EFI GELI support ready for testers Message-ID: <20160528172618.GB38613@kib.kiev.ua> References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2016 17:26:25 -0000 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 testing. I am able to successfully detect multiple GELI partitions in boot1 and pass the keys into the kernel. > > > > Can somebody explain in which way this is useful ? > > Same question for the GELI code for non-EFI loader. > > > > 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. > > > > 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" > > > > 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 / > > 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 selecting the actual partition for loader. Throw thousand lines of code into the unstable and very hard to debug environment of loader looks somewhat unproductive. > > 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/boot 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. > > 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. > > 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. Obvious security advantages ? Seriously ? What is a single 'security' advantage of hiding the kernel ? 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. 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.