svn commit: r316938 - head/sbin/savecore

[Mark Johnston]

On Fri, Apr 14, 2017 at 02:28:57PM -0700, Xin LI wrote:
> On Fri, Apr 14, 2017 at 1:29 PM, Mark Johnston <markj at 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.