Date: Mon, 22 Jul 2013 22:38:53 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, Glen Barber <gjb@FreeBSD.org>, FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: r253070 and "disappearing" zpool Message-ID: <20130722203853.GB1400@garage.freebsd.pl> In-Reply-To: <51ECDF64.2020704@FreeBSD.org> References: <20130710180548.GA2151@glenbarber.us> <51ECDF64.2020704@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 22, 2013 at 10:29:40AM +0300, Andriy Gapon wrote: > I think that this setup (on ZFS level) is quite untypical, although not > impossible on FreeBSD (and perhaps only FreeBSD). > It's untypical because you have separate boot pool (where loader, loader.= conf > and kernel are taken from) and root pool (where "/" is mounted from). As I said elsewhere, it is pretty typical when full disk encryption is used. The /boot/ has to be unencrypted and can be stored on eg. USB pendrive which is never left unattended, unlike laptop which can be left in eg. a hotel room, but with entire disk encrypted. > So, I see three ways of resolving the problem that my changes caused for = your > configuration. >=20 > 1. [the easiest] Put zpool.cache loading instructions that used to be in > defaults/loader.conf into your loader.conf. This way everything should w= ork as > before -- zpool.cache would be loaded from your boot pool. >=20 > 2. Somehow (I don't want to go into any technical details here) arrange t= hat > your root pool has /boot/zfs/zpool.cache that describes your boot pool. = This is > probably hard given that your /boot is a symlink at the moment. This pro= bably > would be easier to achieve if zpool.cache lived in /etc/zfs. >=20 > 3. [my favorite] Remove an artificial difference between your boot and r= oot > pools, so that they are a single root+boot pool (as zfs gods intended). = As far > as I understand your setup, you use GELI to protect some sensitive data. > Apparently your kernel is not sensitive data, so I wonder if your /bin/sh= or > /sbin/init are really sensitive either. > So perhaps you can arrange your unencrypted pool to hold all of the base = system > (boot + root) and put all your truly sensitive filesystems (like e.g. /ho= me or > /var/data or /opt/xyz) onto your encrypted pool. If all you care about is laptop being stolen, then that would work. If you however want to be protected from someone replacing your /sbin/init with something evil then you use encryption or even better integrity verification also supported by GELI. Remember, tools not policies. There is also option number 4 - backing out your commit. When I saw your commit removing those entries from defaults/loader.conf, I thought it is fine, as we now don't require zpool.cache to import the root pool, which was, BTW, very nice and handy improvement. Now that we know it breaks existing installations I'd prefer the commit to be backed out. This is because apart from breaking some existing installations it doesn't gain us anything. > So I understand that my change causes a problem for a setup like yours, b= ut I > believe that the change is correct. The change is clearly incorrect or incomplete as it breaks existing installations and doesn't allow for full disk encryption configuration on ZFS-only systems. BTW. If moving zpool.cache to /etc/zfs/ will work for both cases that's fine by me, although the migration might be tricky. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHtmF0ACgkQForvXbEpPzThTgCgw4sjqVzDo2SQTz60mA67V9gy 7GoAn1bOXMhOJ3EEoAZT2h1URfGHu9Y2 =dUcf -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130722203853.GB1400>