Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Apr 2017 14:28:57 -0700
From:      Xin LI <delphij@gmail.com>
To:        Mark Johnston <markj@freebsd.org>
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:  <CAGMYy3siQA-%2Brh7RvUoApXA3HJjiiyeb=7d6ZUyBeVJiJjtnhQ@mail.gmail.com>
In-Reply-To: <20170414202918.GD5039@wkstn-mjohnston.west.isilon.com>
References:  <201704141941.v3EJfmCW003347@repo.freebsd.org> <CAOtMX2gPHWRGiE9UA5AevZz=cTv_qksAWX0H-xRjDEHp0huCVg@mail.gmail.com> <20170414202918.GD5039@wkstn-mjohnston.west.isilon.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.  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.

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.

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.

Cheers,



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGMYy3siQA-%2Brh7RvUoApXA3HJjiiyeb=7d6ZUyBeVJiJjtnhQ>