Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Sep 2010 17:03:44 +0200
From:      Pawel Jakub Dawidek <pjd@FreeBSD.org>
To:        Carl <k0802647@telus.net>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: geli'd swap and core dumps
Message-ID:  <20100905150344.GD1900@garage.freebsd.pl>
In-Reply-To: <4C834D1A.2010405@telus.net>
References:  <4C834D1A.2010405@telus.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--AsxXAMtlQ5JHofzM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Sep 05, 2010 at 12:56:10AM -0700, Carl wrote:
> I would like to encrypt my swap partition like Pawel does on his=20
> company's production servers:
>=20
>=20
> http://blogs.freebsdish.org/pjd/2010/08/06/from-sysinstall-to-zfs-only-co=
nfiguration/
>=20
> Does Pawel's method result in kernel panics having no functional dump=20
> device?
>=20
> What are best practices for achieving encrypted swap and functional core=
=20
> dump recovery? Or are these mutually exclusive goals?

Well, the idea to encrypt swap is to prevent any sensitive data to be
stored on disk unencrypted where it might last for a long time.
If you configure to dump kernel memory to a disk (kernel dumps are not
encrypted) you kinda miss the point, as kernel memory can contain a lot
of sensitive data.

It would be best in such cases to use textdump(4) as there is quite a
lot of useful info, but no sensitive data at all (or not much at least,
depends on what you consider sensitive).

Unfortunately rc.d scripts order doesn't allow geli-encrypted swap and
dumpdev to co-operate, ie.  geli is configured on swap device before
savecore(8) has a chance to read underlying device (to be more precise
not only read it, but also write to it, as it has to mark the data as
already obtained, so we don't save the same crash info on every reboot).

On the other hand we do want swap as soon as possible (even before
mounting / or /var read-write so we have more memory for fsck(8) for
example), so the solution is not as trival as changing scripts order.
The better fix would be to obtain and save crash info in memory
somewhere before we configure swap and copy it to /var/crash/ once we
mount it.

--=20
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

--AsxXAMtlQ5JHofzM
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAkyDsVAACgkQForvXbEpPzQ/DACcDWH6RyT0T9urUBWXnF/hr5Dk
F/4AoJibwtRtqm5KEtbBQ55Bdqgpiv9g
=h9sb
-----END PGP SIGNATURE-----

--AsxXAMtlQ5JHofzM--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100905150344.GD1900>