Date: Sat, 2 Apr 2016 20:04:32 -0400 From: Eric McCorkle <eric@metricspace.net> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Boot crypto framework patch, need testers Message-ID: <A65A2A87-C879-4E4D-960A-5EB4E2F1CEE7@metricspace.net>
next in thread | raw e-mail | index | archive | help
Hello, I've put together the following patch as part of a larger body of work I'm p= ursuing: https://github.com/emc2/freebsd/tree/boot_crypto This isn't a big patch, but it's aiming to be a central hub for boot-time cr= ypto, so it needs due consideration. This patch basically pulls all the cry= pto bits out of the recent geliboot work and moves them into a separate modu= le, called "boot_crypto". This is supposed to be a behavior-neutral patch, s= o it should be possible to drop it in to existing systems and have it Just W= ork. I'm not aware of other areas in the boot ecosystem that use crypto, bu= t if there are, they should probably be moved onto this framework as well. After studying the kernel crypto framework, GELI, and others, I have elected= NOT to try to design an interface for asking for passwords securely, storin= g keys, and other functionality I had previously contemplated. The existing= frameworks just don't support that kind of thing. I'm ok with this being reviewed to go in as-is, or it can be done as part of= my (very nearly finished) GELI EFI work. Whatever the decision, though, th= is is probably the best point to test that it doesn't break the existing gel= iboot functionality. The rationale for doing this code reorganization follows: * It helps avoid duplication and extra work for things like the EFI work * It makes it easier to add support for more ciphers (camellia and blowfish a= re unsupported in the current boot GELI implementation, for example, and act= ivity in the crypto world suggests new ciphers/modes will be arriving) * It lowers the overhead of implementing other crypto-based functionality at= boot time (gbde, ZFS encryption, secure boot, etc) * Boot crypto functionality has different enough needs (simplicity, small co= de size, etc) to warrant a boot-specific interface. * It's much easier to install an interface like this one when there are few c= onsumers than to rip out 5-6 random ad-hoc crypto implementations at some po= int in the future. *Especially* in a boot loader. Please review, test, and provide feedback. Thanks, Eric=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A65A2A87-C879-4E4D-960A-5EB4E2F1CEE7>