On Fri, Apr 14, 2017 at 02:28:57PM -0700, Xin LI wrote: > On Fri, Apr 14, 2017 at 1:29 PM, Mark Johnston <ma...@freebsd.org> wrote: > > - I'm not sure how encryption should compose with compression. It seems > > intuitively obvious that we should compress before encrypting if the > > compression is to be of any use, but I don't know enough to know > > whether the compression might somehow compromise the effectiveness of > > the encryption. > > I think the biggest concern is the added code involved in the dump > process (which happen when the kernel is already unhealthy), which can > jeopardize it and defeat the usefulness of having a crash dump being > set up in the first place.
I agree in principle but this doesn't appear to cause problems in practice. zlib allocates memory only at initialization time, so its requirements in panic context are quite minimal. I wrote a little bit of zlib glue, used currently for compressed userland core dumps, which works properly in panic context as well. > And with textdumps available, the benefit > of having compression is limited because we can request for minidump > or full dumps only when the textdumps are not good enough for > diagnosing the kernel bug. Sure, but in this case the compression may be vital. > > I don't think security (e.g. leaking information because of the use of > compression) is a very big concern in this context because in order > for the potential attacker to read the raw material needs a > compromised system (unlike an attack from the network, where someone > who controls the network would have access to the raw material); the > dump is usually quite large, and measuring downtime would be hard at > that scale. Ok. > > By the way (not meant to bikeshed) if I was to do this I'd prefer > using lz4 or something that compresses faster than zlib. I agree, but I think the existing lz4 implementation in the kernel is not so well suited to running after a panic. It seems fixable, but compression speed also isn't hugely important here IMO. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
