Skip site navigation (1)Skip section navigation (2)
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>