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
This is a cryptographically signed message in MIME format. --------------ms040202080402060309010207 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 proper= ty >> 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 boo= tfs 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. --=20 Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ --------------ms040202080402060309010207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEwMDIxMjUyMTRaMCMGCSqGSIb3DQEJBDEW BBQoai+GSc/96b9AmSAtRFsrYFmBgzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAtv6dCRgOxVWe7imbksMmMQNzzC+7 7O0pSWY/1KdJCZDODF67gcBaEtAusKuU3/wkwGg7kFaVHHXXQySSXaNhhEPo4ChWV3i4HOpK QB5hmHC8GuDvyoy5road7SDnMI3Vv5jLC1zl/Jqy+5d/dbQ8ZtPxSPwqainRU20pQdWQvx/q NfwU6N3WdYJ385EZQ3pioot4BEUjWovzGC/wMZBke1u7J58j0SIlMcSeMva6Biov66yUaZPx 84fvudSrQFveZQCATzitEfnCGYYs/1qffXgmCtNhhRHqvAidydR7X8GNzs/1us4ewpUkdUV7 GggrtVGOt746xrhEf7+pcBOn/oR495DrPnrX5Mz0EXvU8PGizkCo2uTJIMSCjDKXJwnb1h0S QAr4dAzjgoVCxD7QgCJ/Esvk3DCDnZwBzwJjIhn/JoC3uo2XOkZ3QM6NjvP8EpOWk4kI4S1N XU6M0Hej0kXQvbic6l4QJbQe74aGyWdQYwI3n7MdyyMGKHgB2s8G9XX8mA0fKGr3IcRkIF7l mjVm4/3xYbtWIHjtvAoN3V8OYEBeCOtyFcMugdjUds7y58o/kAfGk5UJgWLklK+ibCa9H+nB Vr37PvZdtBS+sPSvcZWNDZkK3+wmERTrzbmEQB90VSkHa8R6knrFiUIDB+qO/8VYxzYvv/zm wsuwSAEAAAAAAAA= --------------ms040202080402060309010207--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?542D4A7E.1050407>