Date: Fri, 14 Apr 2017 15:05:25 -0700 From: Mark Johnston <markj@freebsd.org> To: Xin LI <delphij@gmail.com> Cc: Alan Somers <asomers@freebsd.org>, Ngie Cooper <ngie@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r316938 - head/sbin/savecore Message-ID: <20170414220525.GF5039@wkstn-mjohnston.west.isilon.com> In-Reply-To: <CAGMYy3siQA-%2Brh7RvUoApXA3HJjiiyeb=7d6ZUyBeVJiJjtnhQ@mail.gmail.com> References: <201704141941.v3EJfmCW003347@repo.freebsd.org> <CAOtMX2gPHWRGiE9UA5AevZz=cTv_qksAWX0H-xRjDEHp0huCVg@mail.gmail.com> <20170414202918.GD5039@wkstn-mjohnston.west.isilon.com> <CAGMYy3siQA-%2Brh7RvUoApXA3HJjiiyeb=7d6ZUyBeVJiJjtnhQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170414220525.GF5039>