From owner-freebsd-questions@freebsd.org Mon Apr 20 19:38:20 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8C2BB2ACE77 for ; Mon, 20 Apr 2020 19:38:20 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 495cSD2WzLz3xgZ for ; Mon, 20 Apr 2020 19:38:20 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: by mailman.nyi.freebsd.org (Postfix) id 54E5D2ACE76; Mon, 20 Apr 2020 19:38:20 +0000 (UTC) Delivered-To: questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 54A8F2ACE75 for ; Mon, 20 Apr 2020 19:38:20 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from echo.brtsvcs.net (echo.brtsvcs.net [IPv6:2607:f740:c::4ae]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 495cSC1vG7z3xgX for ; Mon, 20 Apr 2020 19:38:18 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from chombo.houseloki.net (unknown [IPv6:2602:41:642b:600::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "chombo.houseloki.net", Issuer "brtsvcs.net CA" (verified OK)) by echo.brtsvcs.net (Postfix) with ESMTPS id B8B9B38D21 for ; Mon, 20 Apr 2020 19:38:12 +0000 (UTC) Received: from [IPv6:2602:41:642b:630:e9e5:f7a:bf1c:ca79] (unknown [IPv6:2602:41:642b:630:e9e5:f7a:bf1c:ca79]) by chombo.houseloki.net (Postfix) with ESMTPSA id E9C6B1B93 for ; Mon, 20 Apr 2020 12:38:11 -0700 (PDT) To: questions@freebsd.org From: Mel Pilgrim Subject: Root on GELI+ZFS without a separate boot pool? Message-ID: <5c8c640c-8811-d7f4-a239-f42fcac3688f@bluerosetech.com> Date: Mon, 20 Apr 2020 12:38:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 495cSC1vG7z3xgX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of list_freebsd@bluerosetech.com designates 2607:f740:c::4ae as permitted sender) smtp.mailfrom=list_freebsd@bluerosetech.com X-Spamd-Result: default: False [-4.61 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[bluerosetech.com]; IP_SCORE(-3.31)[ip: (-8.52), ipnet: 2607:f740:c::/48(-4.19), asn: 36236(-3.80), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:36236, ipnet:2607:f740:c::/48, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2020 19:38:20 -0000 Threads on others lists mentioned that with 12-R it's no longer necessary to have a separate boot pool when using a GELI-encrypted root ZFS pool. The documentation I can find only shows the simple case of using a passphrase without a boot pool, or the "legacy" configuration of using keyfiles with a separate boot pool. The use case is data privacy on a failed disk sent back to the OEM under RMA combined with unattended restarts. Prompting for a passphrase can't happen. The means to decrypt the GELI volumes must never be stored on the disk with the encrypted partitions. It seems like it would work if the loader could access a separate filesystem containing just the keys, but nothing in the documentation suggests how to do this. That is, the configuration for using GELI keys assumes the keys are on the same filesytem as the loader. How do I get rid of having a separate /boot pool in my use case?