Date: Sun, 10 Feb 2013 16:44:49 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: Eitan Adler <lists@eitanadler.com>, Andrey Zonov <zont@FreeBSD.org>, current@FreeBSD.org Subject: Re: geli(8) breaks after a couple hours of uptime Message-ID: <20130210154449.GI1375@garage.freebsd.pl> In-Reply-To: <51175162.3030401@FreeBSD.org> References: <20130207180153.GX35868@acme.spoerlein.net> <20130208095709.6ae61cff@fabiankeil.de> <20130208114825.GY35868@acme.spoerlein.net> <5114F390.4010302@FreeBSD.org> <CAF6rxgn7PRmBkx3FLnXfOjKzSHi1JEQQ_wc4273oHCmpTCjR1A@mail.gmail.com> <20130209140733.0b753c60@fabiankeil.de> <51166580.4080603@FreeBSD.org> <511672B5.5080300@FreeBSD.org> <20130209233500.GH1375@garage.freebsd.pl> <51175162.3030401@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--MGu/vTNewDGZ7tmp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 10, 2013 at 09:50:58AM +0200, Andriy Gapon wrote: > on 10/02/2013 01:35 Pawel Jakub Dawidek said the following: > > geli(8) almost exclusively deals with sensitive data. Even mlocking > > MAXPHYS would fail with current limits, but this is bad idea. > >=20 > > With mlockall() I am sure I didn't miss anything - be it forgetting > > about mlocking some buffer or zeroing it before munlock. I'm also sure > > someone else who can modify geli(8) in the future won't miss anything > > too. >=20 > Well, the geli is not such a complex program really. It seems to use onl= y two > or so buffers for sensitive data. [...] Maybe it isn't very complex, but complex enough that you missed a dozen or so buffers that would need mlocking (almost everything that is bzero'ed), not to mention internal states for hash and encryption algorithms that operate on blocks, so they can keep plain data until their update method gather entire block. Encryption and HMAC calculation is done by API used by both userland and kernel parts, so it would need some ifdefs to make it work, thus further complicating entire thing. > [...] As far as I can see geli deals only with some > key management (reading keys, generating key from key material, etc). The= re is > definitely no need to mlock the code, etc. I fully agree there is no need to mlock the code and I'd be happy to use mlockall(2) flag that protects only the data. Until such flag is introduced I'll keep mlocking everything. > I think that PAGE_SIZE (or at most a small multiple of it) should be suff= icient. > I don't think that we currently have (or expect to see in the near future) > algorithms where keys with more than 4096 size provide any additional sec= urity. geli(8) deals just fine with files that are larger than buffers, so even with smaller buffer it can read the data in few steps. The proposed patch is here if someone would like to give it a try: http://people.freebsd.org/~pjd/patches/geom_eli.c.patch --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --MGu/vTNewDGZ7tmp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEXwHEACgkQForvXbEpPzRkdgCbBQQcuHrj3nvXibqD+rHpmu65 dJMAoJ4RNzUFvdjBy9CNNbl//6026pvs =Tf9c -----END PGP SIGNATURE----- --MGu/vTNewDGZ7tmp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130210154449.GI1375>