From nobody Sat Nov 27 17:00:10 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CD98F18A3E21 for ; Sat, 27 Nov 2021 17:00:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1dCc53QMz3P1G for ; Sat, 27 Nov 2021 17:00:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92d.google.com with SMTP id n6so24933793uak.1 for ; Sat, 27 Nov 2021 09:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fBy62RXg11dYoXtE3y7Te+VnQvTXxniJ19BQEyr5QL0=; b=YX98I0rmZ9BysThwugg4F+MkmGf8p5xpezGnX8I7UaDwdCUrLMXp9KRy5u+jlBj0sD PMrfXDiGz3Wzbs3j/Ot1MNmJy5GSrao5pbTns4H12gjCfcgnZe3OJsRpLGnG0n0fNwDI hsXcNyBqjvJZqQS+ToA2NEhyJL9gzHONoZJxJSbon/mkCDem8zfSZWj3e2ml0gUSYtfV 1RhWFkXz2L68UAbcdF/EFjiDKkki94aKeOR+rpIH5LSOHFUSAMpnWRyP3pRr7FZn+sSH DXcfbPcrcD5sdyR7kK2cwzEP5FhPPGJyYFranHIZmbYPj5UUSXIz0F37SHNAHxp2FhXj aHnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fBy62RXg11dYoXtE3y7Te+VnQvTXxniJ19BQEyr5QL0=; b=DJ9Fk2YIJUUUE06uhZ2eYsTs8Yslv2Lz69G95wUtcZ5GUmmvoqrVo7s51HeSWn2A2f NR2DrBPtaTVg/6Mbtmx9AhF8AflWI7cktYH3X/XpHG26EqZ+om2jfaX/I5iYYZuhkw1Z RtxQUrxekRxIidIKi0uxPVlBJEYZ2lZsMORGXNapYHv44EL0WEMLcYuJdyb7RH4L8OsF EtM7WSSbAl9B1iIeLaRd8jZvpK41dTDW8aBmwDqeSnmTC33qZtrERcDKww7vr1s3O2y3 4++GogCckHWZDZenTvRoTa6pITRbozh4uUIabb3xzffoJBoCRLfaR7nPA3LN5I/t3xFk 2/jA== X-Gm-Message-State: AOAM531pig66eFfONbQqccyftGHv8/3TxMse+uxSLaUzZB15CNpkCayM hsdQ3F4VHPCp5AJWcENw2vYAOyMjuWX1nFzYr6bG2QIFoAQKtQ== X-Google-Smtp-Source: ABdhPJx4M1BnuRJ1QbWklg6cj+LeHrlkAFfyqWeJ2gauanYk7/tx6B5K3xhvtFE3DPhvykLUFG5MkSok/FYYMUhRAn8= X-Received: by 2002:a67:f950:: with SMTP id u16mr24662718vsq.68.1638032428019; Sat, 27 Nov 2021 09:00:28 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sat, 27 Nov 2021 10:00:10 -0700 Message-ID: Subject: Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase To: Stanislaw Adaszewski Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000000c52905d1c825fd" X-Rspamd-Queue-Id: 4J1dCc53QMz3P1G X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000000c52905d1c825fd Content-Type: text/plain; charset="UTF-8" On Sat, Nov 27, 2021, 7:36 AM Stanislaw Adaszewski wrote: > Dear All, > > Could you please guide me so that we can together integrate > the following piece of work into the FreeBSD base system? > Thank you for your time and consideration. > See below for some advice. I have created the following bundle of work [1]. The referenced > patch implements on top of releng/13.0, the support for TPM2 > in the EFI bootloader and in the kernel in order to allow for > storage and retrievel of a GELI passphrase in a TPM2 module, > secured with a PCR policy. > > The way the bootloader behavior is modified is the following: > > 1) before calling efipart_inithandles() an attempt to retrieve the > passphrase from a TPM2 module might be performed - > how this is achieved is described later on. > 2) if a passphrase is indeed retrieved, then after determining > currdev, the currdev is checked for the presence of a > /.passphrase_marker file which must contain the same passphrase > as retrieved from the TPM. This is supposed to ensure that we > do not end up booting an environment not on the device we just > unlocked with the passphrase. > 3a) If all is go, the autoboot_delay is set to -1 in order to prevent > any interaction and continue the boot process of the "safe" environment, > a 'kern.geom.eli.passphrase.from_tpm2.passphrase' variable is set > to the passphrase from TPM in order for kernel use later, as well as a > kern.geom.eli.passphrase.from_tpm2.was_retrieved'='1' variable. > 3b) If the passphrase marker does not match, the bootloader cleans up > GELI keys, the TPM passphrase and kern.geom.eli.passphrase and exits. > I worry about information disclosure having the pass phrase available on the running system with this setup. Can you explain why that design point was selected? Usually there is something signed with a private key that the public key can be used to verify instead of a direct comparison like this to prevent disclosure of key material. I've not looked at the code yet, so it may already do this... The way the kernel behavior is modified is the following: > > 1) In init_main.c, after vfs_mountroot() a check is added > 2a) If kern.geom.eli.passphrase.from_tpm2.was_retrieved is not > set to 1, then we do nothing and continue the boot process > 2b) If the was_retrieved variable is set to '1' then we check for the > same passphrase marker as the bootloader, its content compared > against the 'kern.geom.eli.passphrase.from_tpm2.passphrase' > variable. > 3a) If all is go, the passphrase variable is unset and the boot process > continues, > 3c) If the passphrase marker does not match, we panic. > I'm sure that main_init should not know about geom or geli. This is usually done with a handler of some sort so the mountroot code can just call the generic handler. Can your code be restructured such that this is possible? The reason I ask is that ZFS supports encryption too and it would be nice to use that instead of geli. The configuration of the bootloader for this procedure looks the following: > > 1) We set an efivar KernGeomEliPassphraseFromTpm2NvIndex > to contain the TPM2 NV Index we store our passphrase in, e.g. 0x1000001 > 2) We set an efivar KernGeomEfiPassphraseFromTpm2PolicyPcr > to contain the PCR policy used to secure the passphrase, e.g. > sha256:0,2,4,7 > 3a) If both are set, the bootloader will attempt to retrieve the passphrase > and behave in the modified way described above > 3b) Otherwise, it behaves as the vanilla version and will ask for GELI > passphrases if necessary > > The configuration of the TPM and the passphrase marker looks the following: > > 1) echo -n "passphrase" >/.passphrase_marker > 2) chmod 600 /.passphrase_marker > 3) tpm2_createpolicy -L policy.digest --policy-pcr -l sha256:0,2,4,7 > 4) tpm2_nvdefine -Q 0x1000001 -s `wc -c /.passphrase_marker` -L > policy.digest -A "policyread|policywrite" > 5) tpm2_nvwrite -Q 0x1000001 -i /.passphrase_marker -P pcr:sha256:0,2,4,7 > > [1] > https://github.com/sadaszewski/freebsd-src/compare/releng/13.0...tpm-support-in-stand This sounds cool. Any chance you can rebase this to the tip of the main branch? All code goes into FreeBSD that way and 13.0 is about a year old already. Thanks for sharing this. Despite some reservations expressed above, I think this has potential to be quite cool. Warner > Kind regards, --00000000000000c52905d1c825fd--