geli(8) breaks after a couple hours of uptime

[Andriy Gapon]

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.
> 
> 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.

Well, the geli is not such a complex program really.  It seems to use only two
or so buffers for sensitive data.  As far as I can see geli deals only with some
key management (reading keys, generating key from key material, etc). There is
definitely no need to mlock the code, etc.

> geli(8) is relatively simple program, it doesn't allocate megabytes of
> memory for different pruposes and just needs few pages for sensitive
> data. As I said most of the memory it uses is for sensitive data.

Right, except for code (from geli and from shared libraries) and other stuff
that is really not sensitive at all.

> The obvious problem is allocating MAXPHYS on the stack. This has to be
> changed, especially that we may want to rise MAXPHYS in the future.

Yes, I do not see any relation between what geli does and MAXPHYS.

> Other than that I expect thing would be tuned properly so that geli(8)
> can work by default. I'm happy to use smaller buffers than MAXPHYS -
> keyfiles are far smaller usually than 128kB, so there shouldn't be any
> issue with this.

I think that PAGE_SIZE (or at most a small multiple of it) should be sufficient.
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 security.

-- 
Andriy Gapon