Date: Thu, 02 Oct 2014 07:52:14 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-stable@freebsd.org Subject: Re: Encrypted (GELI) root on ZFS troubles Message-ID: <542D4A7E.1050407@denninger.net> In-Reply-To: <542D108D.80603@FreeBSD.org> References: <542C71C9.1050907@denninger.net> <d4f3fecfcd8785c41e3658ff34123088@dweimer.net> <542CD992.7050509@denninger.net> <542D108D.80603@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 10/2/2014 3:45 AM, Andriy Gapon wrote: > On 02/10/2014 07:50, Karl Denninger wrote: >> 1. Having the kernel able to cross pools and examine the bootfs property >> would be fairly useful. > I don't understand your suggestion. Every pool has bootfs property (if it's not > explicitly set then that means that it just has its default value). So which of > the bootfs properties must be honored and why? At present we honor bootfs of > the "current" pool, which is the only distinguished pool. Except default is "from whence one came" and yes, I understand the problem if there's a conflict. I would argue that if the parameter is set on the pool the kernel booted from it should be honored, but if it is NOT set (that is, if it is defaulted) then if it is validly set on a different pool that one should be honored. We already do this in that if /boot/loader.conf is set that's honored, and this sounds inviolate but it in fact is not for the below reason. I do understand the problem in the general sense with "well what happens if there are two or more bootfs parameters set on other pools but none on the pool the kernel loaded from" but here's the thing -- that risk is already there, in that there's already all sorts of "fun" possible with adapters that don't enumerate reliably in order, especially if the intended boot device goes offline. My LSI adapters, in particular (which are a great example because lots of people use these with SAS expanders and lots of plugged in drives, myself included, as they work well and are pretty fast), will happily look for another bootable device that happens to be plugged in if your primary(s) are offline and, if you have one in the machine, it will attempt to boot it. Sucks to be you if that turns out to be a bootable environment. So what I think makes sense is the following: 1. If /boot/loader.conf has vfs.root.mountfrom set, honor it (yes, there is a risk to this too; you might have booted from an unintended disk!) 2. If we booted from zfs and bootfs is set non-default on the pool you booted from then honor it, otherwise honor the first non-default bootfs setting you find on any pool that is mounted during kernel init (which for a geli-encrypted pool means one that had the "-b" flag set on its members, otherwise it's not available until after init starts.) I understand this has risks but so does an adapter deciding to boot from the "wrong" disk; there's no reason for bootfs to be set non-default on a pool that isn't used for booting. 3. If neither (1) or (2) is true then mount root from the pool/device you loaded the kernel from. I can certainly understand that not being the default (you could get reamed pretty good if you booted a non-corresponding kernel .vs. the rest of the environment) but IMHO it violated the principle of least astonishment when I went to set this up and the implication that bootfs on *a* pool was sufficient as a hint to the kernel. -- Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ [-- Attachment #2 --] 0 *H 01 0 + 0 *H O0K030 *H 01 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 130824190344Z 180823190344Z0[1 0 UUS10UFlorida10UKarl Denninger1!0 *H karl@denninger.net0"0 *H 0 bi՞] MNԿawx?`)'ҴcWgR@BlWh+ u}ApdCF JVй~FOL }EW^bچYp3K& ׂ(R lxڝ.xz?6 &nsJ +1v9 v/( kqĪp[vjcK%fϻe?iq]z lyzFO'ppdX//Lw(3 JI A*S#՟H[f|CGqJKoo y.oEuOw$ /섀$삻J9b|A P~8]D1YI<"""Y^T2iQ2 b yH)] Ƶ0y$ _N 6XqMC 9 XgώjGTP"#nˋ"Bk1 00 U 0 0 `HB0 U 0, `HB OpenSSL Generated Certificate0 U |8 ˴d[20 U #0]Af4 U3x&^"408 `HB+)https://cudasystems.net:11443/revoked.crl0 *H gBwH] j\x`( &gW32"Uf^. ^Iϱ k!DQA g{(w /)\N'[ oRW @C HO>)XrTNɘ!u`xt5(=f\-l3<@C6mnhv##1ŃbH͍_Nq aʷ?rk$^9TIa!kh,D -ct1 0001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 + ;0 *H 1 *H 0 *H 1 141002125214Z0# *H 1(j/I@ -D[+`Y0l *H 1_0]0 `He*0 `He0 *H 0*H 0 *H @0+0 *H (0 +71001 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 *H 101 0 UUS10UFlorida10U Niceville10U Cuda Systems LLC1 0UCuda Systems LLC CA1/0- *H customer-service@cudasystems.net0 *H U)&1s/)If?ԧI ^Z.$h;V uC$]aC(VWx J@ apʌ 0տ \u<fH*j)Sm)AՐ 5uwCzbxE#Z/1d{['#"%1Ğ2*/묔iԫ@[e O8,Z}x& a{_ $uE{+Q:ƸDpx>z{@ Ă2' @ t ゅB>Ѐ"0c"&:Fw@-M]NwEн^% gPc7 #(xu (j!d ^5faV x _`@^r.v?Ɠ b䔯l& V>]q &@ tU)kzzʼnBX6/˰H
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?542D4A7E.1050407>