From owner-freebsd-hackers@freebsd.org Sat May 28 17:24:56 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 D9BFAB4D9C0 for ; Sat, 28 May 2016 17:24:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A03031E7B; Sat, 28 May 2016 17:24:56 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x22d.google.com with SMTP id w184so210842777oiw.2; Sat, 28 May 2016 10:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=f7CGhNaHBovkVVWb8IQiBwA8AY85iar9o19jiU9uexE=; b=oXR9P8w6+x27f/X9abJV2dJnPHLdyw1rmCIBmuEb/kxVdfFrL0EstooM+vpJRQtDGn ZJM+ItA8sqzDJcyfFpFldnCVtMfUFwWJ5vhAOjvFLqSnX7GoFgFn5Ef1g+ZlNKwpEPef U4gAUZt3yC1HJhsF+8BBnObQtN7pn/SGnumfADDY5CoI36+J1y7VT/OEbAnN7zk3rQIW VnqDCxv9vo/vOESqazfv7FpnpkQVu39e4oLmrKtIJC72swNzr0N4h2/1VtDKvbeMAnGn 2LWWItfwDg+nyrLNgJEsYryWvHv7DEtIWOdkJAvRCoFid0QRDmYgthvGQcYbkRiyS5B5 dvGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=f7CGhNaHBovkVVWb8IQiBwA8AY85iar9o19jiU9uexE=; b=ehzW/ZRefL8PvXtYmyXqUtZuHyu8xdtHk/Eh0f/ZllT/m6hhxgihY2f/MTKCAeGZuC duDkUFlku4J13y2dHU+Jc0MDQj1Q37upvPbxBm0f74nExLCNJjh5KH0FfEoUI6xdFOtz X4Nv2vcR76ecS8sC3qrrE133nJmlOtFItRTFpIE0qcB7mxmf/B2QhLQ1fh9Imq6qe7/T N/UG/kky2GrJ5+eIHcA4JqF0l+ifs88R1D2HHVDM8B6ykIL+FVfpBcvdn7aC5/rkHp7e uHfP10HeHEMP+tai32vUJ0f0sL4yl4IfHBrW6orWNf8hJgHC3amIX8o8Mv3cKpElmNtC xjTQ== X-Gm-Message-State: ALyK8tL+EQw/XuWeV2mwdFdWSqkZtJoMz6q2GDjN4wxAAkx7a6FoW1Zg3VsIgLF3dxN1LOGRzIfdd3M64kc2Fg== MIME-Version: 1.0 X-Received: by 10.202.224.85 with SMTP id x82mr9342759oig.176.1464456295711; Sat, 28 May 2016 10:24:55 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.202.4.200 with HTTP; Sat, 28 May 2016 10:24:55 -0700 (PDT) In-Reply-To: References: <519CC1FC-84DF-4710-8E62-AF26D8AED2CF@metricspace.net> <20160528083656.GT38613@kib.kiev.ua> Date: Sat, 28 May 2016 11:24:55 -0600 X-Google-Sender-Auth: sk3yvvesd9_zy_fddKWVD-1Xf5k Message-ID: Subject: Re: EFI GELI support ready for testers From: Alan Somers To: Eric McCorkle Cc: Allan Jude , "freebsd-hackers@freebsd.org" , "Kenneth D. Merry" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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:24:56 -0000 On Sat, May 28, 2016 at 9:23 AM, Eric McCorkle wrote= : > >> On May 28, 2016, at 10:27, Allan Jude wrote: >> >> 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/bo= ot >> >> 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. > > It did indeed make things easier, though I think there is potential for w= ork to be done on the crypto framework. It looks like the crypto framework= has kind of accumulated code over time from different sources and has beco= me somewhat disorganized. There seem to be two codebases (crypto and opencr= ypto), and multiple differing implementations for some ciphers. I ran into= this when trying to figure out how to add Camellia support. There's a usa= ble interface for AES CBC/XTS, but not Camellia CBC. There are also some i= nsecure ciphers (DES, RC4, etc) in there, some more modern ciphers (like ch= acha20) are missing, and it's possible to implement ciphers other than AES = using AESNI/AVX instructions to achieve hardware acceleration. > > It also ought to be simpler to share crypto code between kernel, boot, an= d userland, imo. In theory, one could have a single library (with multiple= compilations for different ABIs) that could be statically linked into the = kernel and boot loaders, and also installed in to the base OS. > > I'm not sure if there's any plans for crypto, but it might be worth a dis= cussion. > >> >> 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. >> > > The ability to have a single ZFS filesystem is indeed a motivator for the= EFI work. I forgot to mention it because my personal motivations are stro= ngly focused on security and tamper-resistance. The problem with opencrypto is that it was written when crypto accelerators lived on PCI cards and were treated as shared resources. That's why userland programs wishing to use opencrypto have to send all of their data into the kernel. It's a very inefficient way of using CPU-resident accelerators like AESNI and Padlock. For clients within the kernel, it's not so bad. It adds a few extra stack frames and a lot of code but there are no additional data copies. crypto(3), OTOH, is part of OpenSSL. AFAIK it doesn't have the data copies problem, but it's still quite complicated. ken@ once tried to build OpenSSL into the kernel but gave up because it has too many dependencies. So neither of these libraries is suitable for use in both kernel and userland. I don't know of any that is (though I haven't looked). -Alan