Re: [PATCH v11 00/20] Automatic Disk Unlock with TPM2

2024-04-15 Thread Gary Lin via Grub-devel
On Mon, Apr 15, 2024 at 10:26:32AM -0400, Stefan Berger wrote:
> 
> 
> On 4/15/24 05:45, Gary Lin wrote:
> > On Fri, Apr 12, 2024 at 12:24:36PM -0400, Stefan Berger wrote:
> > > 
> > > 
> > > On 4/12/24 04:39, Gary Lin via Grub-devel wrote:
> > > > GIT repo for v11: https://github.com/lcp/grub2/tree/tpm2-unlock-v11
> > > > 
> > > > This patch series is based on "Automatic TPM Disk Unlock"(*1) posted by
> > > > Hernan Gatta to introduce the key protector framework and TPM2 stack
> > > > to GRUB2, and this could be a useful feature for the systems to
> > > > implement full disk encryption.
> > > 
> > > You also need to extend the documentation with the command line steps and 
> > > a
> > > IMO there has to be a warning for VM users that sealing to PCRs inside a 
> > > VM
> > > is dangerous since the next packages update may bring an update to 
> > > TianoCore
> > > UEFI/SeaBIOS/SLOF/... showing different PCR values and unsealing will not
> > > work then.
> > > 
> > For baremetal users, it still could happen after upgrading the firmware.
> 
> Right but this is much rarer.
> 
> > We surely need a place to notice users this situation when using PCR
> > 0~7.
> 
> PCRs 8-9 probably have to be all zeros at the time of sealing (running the
> user space application for seting this up) so they have the values at the
> time before grub measures kernel and initramfs, right?
> 
For grub-protect, yes. On the other hand, pcr-oracle can predict PCR 9
based on the current grub.cfg and the eventlog. PCR 8 is tricky because
grub measures the command with the expanded variables, and pcr-oracle has
to be improved to parse all grub config files to make the prediction.

Gary Lin

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [PATCH v11 00/20] Automatic Disk Unlock with TPM2

2024-04-15 Thread Stefan Berger



On 4/15/24 05:45, Gary Lin wrote:

On Fri, Apr 12, 2024 at 12:24:36PM -0400, Stefan Berger wrote:



On 4/12/24 04:39, Gary Lin via Grub-devel wrote:

GIT repo for v11: https://github.com/lcp/grub2/tree/tpm2-unlock-v11

This patch series is based on "Automatic TPM Disk Unlock"(*1) posted by
Hernan Gatta to introduce the key protector framework and TPM2 stack
to GRUB2, and this could be a useful feature for the systems to
implement full disk encryption.


You also need to extend the documentation with the command line steps and a
IMO there has to be a warning for VM users that sealing to PCRs inside a VM
is dangerous since the next packages update may bring an update to TianoCore
UEFI/SeaBIOS/SLOF/... showing different PCR values and unsealing will not
work then.


For baremetal users, it still could happen after upgrading the firmware.


Right but this is much rarer.


We surely need a place to notice users this situation when using PCR
0~7.


PCRs 8-9 probably have to be all zeros at the time of sealing (running 
the user space application for seting this up) so they have the values 
at the time before grub measures kernel and initramfs, right?




Thanks,

Gary Lin


___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [PATCH v11 13/20] util/grub-protect: Add new tool

2024-04-15 Thread Gary Lin via Grub-devel
On Mon, Apr 15, 2024 at 05:40:53PM +0800, Gary Lin wrote:
> On Fri, Apr 12, 2024 at 04:52:02PM -0400, Stefan Berger wrote:
> > 
> > 
> > On 4/12/24 04:39, Gary Lin via Grub-devel wrote:
> > > From: Hernan Gatta 
> > > 
> > > To utilize the key protectors framework, there must be a way to protect
> > > full-disk encryption keys in the first place. The grub-protect tool
> > > includes support for the TPM2 key protector but other protectors that
> > > require setup ahead of time can be supported in the future.
> > > 
> > > For the TPM2 key protector, the intended flow is for a user to have a
> > > LUKS 1 or LUKS 2-protected fully-encrypted disk. The user then creates a
> > > new LUKS key file, say by reading /dev/urandom into a file, and creates
> > > a new LUKS key slot for this key. Then, the user invokes the grub-protect
> > > tool to seal this key file to a set of PCRs using the system's TPM 2.0.
> > > The resulting sealed key file is stored in an unencrypted partition such
> > > as the EFI System Partition (ESP) so that GRUB may read it. The user also
> > > has to ensure the cryptomount command is included in GRUB's boot script
> > > and that it carries the requisite key protector (-P) parameter.
> > > 
> > > Sample usage:
> > > 
> > > $ dd if=/dev/urandom of=luks-key bs=1 count=32
> > > $ sudo cryptsetup luksAddKey /dev/sdb1 luks-key --pbkdf=pbkdf2 
> > > --hash=sha512
> > > 
> > > To seal the key with TPM 2.0 Key File (recommended):
> > > 
> > > $ sudo grub-protect --action=add \
> > >  --protector=tpm2 \
> > >   --tpm2-pcrs=0,2,4,7,9 \
> > >  --tpm2key \
> > >  --tpm2-keyfile=luks-key \
> > >  --tpm2-outfile=/boot/efi/boot/grub2/sealed.tpm
> > > 
> > > Or, to seal the key with the raw sealed key:
> > > 
> > > $ sudo grub-protect --action=add \
> > >  --protector=tpm2 \
> > >   --tpm2-pcrs=0,2,4,7,9 \
> > >  --tpm2-keyfile=luks-key \
> > >  --tpm2-outfile=/boot/efi/boot/grub2/sealed.key
> > > 
> > > Then, in the boot script, for TPM 2.0 Key File:
> > > 
> > > tpm2_key_protector_init --tpm2key=(hd0,gpt1)/boot/grub2/sealed.tpm
> > > cryptomount -u  -P tpm2
> > > 
> > > Or, for the raw sealed key:
> > > 
> > > tpm2_key_protector_init --keyfile=(hd0,gpt1)/boot/grub2/sealed.key 
> > > --pcrs=0,2,4,7,9
> > > cryptomount -u  -P tpm2
> > > 
> > > The benefit of using TPM 2.0 Key File is that the PCR set is already
> > > written in the key file, so there is no need to specify PCRs when
> > > invoking tpm2_key_protector_init.
> > > 
> > > Signed-off-by: Hernan Gatta 
> > > Signed-off-by: Gary Lin 
> > > ---
> > >   .gitignore  |2 +
> > >   Makefile.util.def   |   22 +
> > >   configure.ac|   30 +
> > >   util/grub-protect.c | 1396 +++
> > >   4 files changed, 1450 insertions(+)
> > >   create mode 100644 util/grub-protect.c
> > > 
[...]
> > > +  /* Create SRK */
> > > +  authCommand.sessionHandle = TPM_RS_PW;
> > > +  inPublic.publicArea.type = args->srk_type.type;
> > > +  inPublic.publicArea.nameAlg  = TPM_ALG_SHA256;
> > > +  inPublic.publicArea.objectAttributes.restricted = 1;
> > > +  inPublic.publicArea.objectAttributes.userWithAuth = 1;
> > > +  inPublic.publicArea.objectAttributes.decrypt = 1;
> > > +  inPublic.publicArea.objectAttributes.fixedTPM = 1;
> > > +  inPublic.publicArea.objectAttributes.fixedParent = 1;
> > > +  inPublic.publicArea.objectAttributes.sensitiveDataOrigin = 1;
> > > +  inPublic.publicArea.objectAttributes.noDA = 1;
> > > +
> > > +  switch (args->srk_type.type)
> > > +{
> > > +case TPM_ALG_RSA:
> > > +  inPublic.publicArea.parameters.rsaDetail.symmetric.algorithm = 
> > > TPM_ALG_AES;
> > > +  inPublic.publicArea.parameters.rsaDetail.symmetric.keyBits.aes = 
> > > 128;
> > > +  inPublic.publicArea.parameters.rsaDetail.symmetric.mode.aes = 
> > > TPM_ALG_CFB;
> > > +  inPublic.publicArea.parameters.rsaDetail.scheme.scheme = 
> > > TPM_ALG_NULL;
> > > +  inPublic.publicArea.parameters.rsaDetail.keyBits = 
> > > args->srk_type.detail.rsa_bits;
> > 
> > Same comment here about pairing RSA3072 with AES-256 and SHA-512 maybe
> > (since SHA 384 isn't supported here).
> > 
> It's sad that we don't have native SHA384 support due to the outdated
> libgcrypt :(
> 
I revised the code and found We actually don't need libgcrypt here. When
writing the patches to support authorized policy, TPM2_Hash() was introduced,
and we can replace grub_crypto_hash() with TPM2_Hash() to enable SHA-384
digest calculation.

Gary Lin

> > Rest LGTM.
> > 
> Thanks for reviewing the patch!
> 
> Gary Lin
> 

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [PATCH v11 00/20] Automatic Disk Unlock with TPM2

2024-04-15 Thread Gary Lin via Grub-devel
On Fri, Apr 12, 2024 at 12:24:36PM -0400, Stefan Berger wrote:
> 
> 
> On 4/12/24 04:39, Gary Lin via Grub-devel wrote:
> > GIT repo for v11: https://github.com/lcp/grub2/tree/tpm2-unlock-v11
> > 
> > This patch series is based on "Automatic TPM Disk Unlock"(*1) posted by
> > Hernan Gatta to introduce the key protector framework and TPM2 stack
> > to GRUB2, and this could be a useful feature for the systems to
> > implement full disk encryption.
> 
> You also need to extend the documentation with the command line steps and a
> IMO there has to be a warning for VM users that sealing to PCRs inside a VM
> is dangerous since the next packages update may bring an update to TianoCore
> UEFI/SeaBIOS/SLOF/... showing different PCR values and unsealing will not
> work then.
> 
For baremetal users, it still could happen after upgrading the firmware.
We surely need a place to notice users this situation when using PCR
0~7.

Thanks,

Gary Lin

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [PATCH v11 13/20] util/grub-protect: Add new tool

2024-04-15 Thread Gary Lin via Grub-devel
On Fri, Apr 12, 2024 at 04:52:02PM -0400, Stefan Berger wrote:
> 
> 
> On 4/12/24 04:39, Gary Lin via Grub-devel wrote:
> > From: Hernan Gatta 
> > 
> > To utilize the key protectors framework, there must be a way to protect
> > full-disk encryption keys in the first place. The grub-protect tool
> > includes support for the TPM2 key protector but other protectors that
> > require setup ahead of time can be supported in the future.
> > 
> > For the TPM2 key protector, the intended flow is for a user to have a
> > LUKS 1 or LUKS 2-protected fully-encrypted disk. The user then creates a
> > new LUKS key file, say by reading /dev/urandom into a file, and creates
> > a new LUKS key slot for this key. Then, the user invokes the grub-protect
> > tool to seal this key file to a set of PCRs using the system's TPM 2.0.
> > The resulting sealed key file is stored in an unencrypted partition such
> > as the EFI System Partition (ESP) so that GRUB may read it. The user also
> > has to ensure the cryptomount command is included in GRUB's boot script
> > and that it carries the requisite key protector (-P) parameter.
> > 
> > Sample usage:
> > 
> > $ dd if=/dev/urandom of=luks-key bs=1 count=32
> > $ sudo cryptsetup luksAddKey /dev/sdb1 luks-key --pbkdf=pbkdf2 --hash=sha512
> > 
> > To seal the key with TPM 2.0 Key File (recommended):
> > 
> > $ sudo grub-protect --action=add \
> >  --protector=tpm2 \
> > --tpm2-pcrs=0,2,4,7,9 \
> >  --tpm2key \
> >  --tpm2-keyfile=luks-key \
> >  --tpm2-outfile=/boot/efi/boot/grub2/sealed.tpm
> > 
> > Or, to seal the key with the raw sealed key:
> > 
> > $ sudo grub-protect --action=add \
> >  --protector=tpm2 \
> > --tpm2-pcrs=0,2,4,7,9 \
> >  --tpm2-keyfile=luks-key \
> >  --tpm2-outfile=/boot/efi/boot/grub2/sealed.key
> > 
> > Then, in the boot script, for TPM 2.0 Key File:
> > 
> > tpm2_key_protector_init --tpm2key=(hd0,gpt1)/boot/grub2/sealed.tpm
> > cryptomount -u  -P tpm2
> > 
> > Or, for the raw sealed key:
> > 
> > tpm2_key_protector_init --keyfile=(hd0,gpt1)/boot/grub2/sealed.key 
> > --pcrs=0,2,4,7,9
> > cryptomount -u  -P tpm2
> > 
> > The benefit of using TPM 2.0 Key File is that the PCR set is already
> > written in the key file, so there is no need to specify PCRs when
> > invoking tpm2_key_protector_init.
> > 
> > Signed-off-by: Hernan Gatta 
> > Signed-off-by: Gary Lin 
> > ---
> >   .gitignore  |2 +
> >   Makefile.util.def   |   22 +
> >   configure.ac|   30 +
> >   util/grub-protect.c | 1396 +++
> >   4 files changed, 1450 insertions(+)
> >   create mode 100644 util/grub-protect.c
> > 
> > diff --git a/.gitignore b/.gitignore
> > index 4d0dfb700..d7b7c22d6 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -169,6 +169,8 @@ widthspec.bin
> >   /grub-ofpathname.exe
> >   /grub-probe
> >   /grub-probe.exe
> > +/grub-protect
> > +/grub-protect.exe
> >   /grub-reboot
> >   /grub-render-label
> >   /grub-render-label.exe
> > diff --git a/Makefile.util.def b/Makefile.util.def
> > index 19ad5a96f..a0a3e2cd5 100644
> > --- a/Makefile.util.def
> > +++ b/Makefile.util.def
> > @@ -207,6 +207,28 @@ program = {
> > ldadd = '$(LIBINTL) $(LIBDEVMAPPER) $(LIBZFS) $(LIBNVPAIR) $(LIBGEOM)';
> >   };
> > +program = {
> > +  name = grub-protect;
> > +
> > +  common = grub-core/osdep/init.c;
> > +  common = grub-core/tpm2/args.c;
> > +  common = grub-core/tpm2/buffer.c;
> > +  common = grub-core/tpm2/mu.c;
> > +  common = grub-core/tpm2/tpm2.c;
> > +  common = grub-core/tpm2/tpm2key_asn1_tab.c;
> > +  common = util/grub-protect.c;
> > +  common = util/probe.c;
> > +
> > +  ldadd = libgrubmods.a;
> > +  ldadd = libgrubgcry.a;
> > +  ldadd = libgrubkern.a;
> > +  ldadd = grub-core/lib/gnulib/libgnu.a;
> > +  ldadd = '$(LIBTASN1)';
> > +  ldadd = '$(LIBINTL) $(LIBDEVMAPPER) $(LIBUTIL) $(LIBZFS) $(LIBNVPAIR) 
> > $(LIBGEOM)';
> > +
> > +  condition = COND_GRUB_PROTECT;
> > +};
> > +
> >   program = {
> > name = grub-mkrelpath;
> > mansection = 1;
> > diff --git a/configure.ac b/configure.ac
> > index 84a202c6e..3a07ab570 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -76,6 +76,7 @@ grub_TRANSFORM([grub-mkpasswd-pbkdf2])
> >   grub_TRANSFORM([grub-mkrelpath])
> >   grub_TRANSFORM([grub-mkrescue])
> >   grub_TRANSFORM([grub-probe])
> > +grub_TRANSFORM([grub-protect])
> >   grub_TRANSFORM([grub-reboot])
> >   grub_TRANSFORM([grub-script-check])
> >   grub_TRANSFORM([grub-set-default])
> > @@ -2057,6 +2058,29 @@ fi
> >   AC_SUBST([LIBZFS])
> >   AC_SUBST([LIBNVPAIR])
> > +AC_ARG_ENABLE([grub-protect],
> > + [AS_HELP_STRING([--enable-grub-protect],
> > + [build and install the `grub-protect' utility 
> > (default=guessed)])])
> > +if test x"$enable_grub_protect" = xno ; then
> > +  

Re: [PATCH v11 11/20] key_protector: Add TPM2 Key Protector

2024-04-15 Thread Gary Lin via Grub-devel
On Fri, Apr 12, 2024 at 02:57:42PM -0400, Stefan Berger wrote:
> 
> 
> On 4/12/24 04:39, Gary Lin via Grub-devel wrote:
> > From: Hernan Gatta 
> > 
> > The TPM2 key protector is a module that enables the automatic retrieval
> > of a fully-encrypted disk's unlocking key from a TPM 2.0.
> 
> A few minor finds/comments below.
> 
> > 
> > The theory of operation is such that the module accepts various
> > arguments, most of which are optional and therefore possess reasonable
> > defaults. One of these arguments is the keyfile/tpm2key parameter, which
> > is mandatory. There are two supported key formats:
> > 
> > 1. Raw Sealed Key (--keyfile)
> > When sealing a key with TPM2_Create, the public portion of the sealed
> > key is stored in TPM2B_PUBLIC, and the private portion is in
> > TPM2B_PRIVATE. The raw sealed key glues the fully marshalled
> > TPM2B_PUBLIC and TPM2B_PRIVATE into one file.
> > 
> > 2. TPM 2.0 Key (--tpm2key)
> > The following is the ASN.1 definition of TPM 2.0 Key File:
> > 
> > TPMPolicy ::= SEQUENCE {
> >   CommandCode   [0] EXPLICIT INTEGER
> >   CommandPolicy [1] EXPLICIT OCTET STRING
> > }
> > 
> > TPMAuthPolicy ::= SEQUENCE {
> >   Name[0] EXPLICIT UTF8STRING OPTIONAL
> >   Policy  [1] EXPLICIT SEQUENCE OF TPMPolicy
> > }
> > 
> > TPMKey ::= SEQUENCE {
> >   typeOBJECT IDENTIFIER
> >   emptyAuth   [0] EXPLICIT BOOLEAN OPTIONAL
> >   policy  [1] EXPLICIT SEQUENCE OF TPMPolicy OPTIONAL
> >   secret  [2] EXPLICIT OCTET STRING OPTIONAL
> >   authPolicy  [3] EXPLICIT SEQUENCE OF TPMAuthPolicy OPTIONAL
> >   parent  INTEGER
> >   pubkey  OCTET STRING
> >   privkey OCTET STRING
> > }
> > 
> >The TPM2 key protector only expects a "sealed" key in DER encoding,
> >so 'type' is always 2.23.133.10.1.5, 'emptyAuth' is 'TRUE', and
> >'secret' is empty. 'policy' and 'authPolicy' are the possible policy
> >command sequences to construst the policy digest to unseal the key.
> >Similar to the raw sealed key, the public portion (TPM2B_PUBLIC) of
> >the sealed key is stored in 'pubkey', and the private portion
> >(TPM2B_PRIVATE) is in 'privkey'.
> > 
> >For more details: 
> > https://www.hansenpartnership.com/draft-bottomley-tpm2-keys.html
> > 
> 
> > +
> > +/* Get the SRK with the template */
> > +static grub_err_t
> > +grub_tpm2_protector_srk_get (const grub_srk_type_t srk_type,
> > +const TPM_HANDLE parent,
> > +TPM_HANDLE *srk_handle)
> > +{
> > +  TPM_RC rc;
> > +  TPMT_PUBLIC_PARMS parms = { 0 };
> > +  TPMS_AUTH_COMMAND authCommand = { 0 };
> > +  TPM2B_SENSITIVE_CREATE inSensitive = { 0 };
> > +  TPM2B_PUBLIC inPublic = { 0 };
> > +  TPM2B_DATA outsideInfo = { 0 };
> > +  TPML_PCR_SELECTION creationPcr = { 0 };
> > +  TPM2B_PUBLIC outPublic = { 0 };
> > +  TPM2B_CREATION_DATA creationData = { 0 };
> > +  TPM2B_DIGEST creationHash = { 0 };
> > +  TPMT_TK_CREATION creationTicket = { 0 };
> > +  TPM2B_NAME srkName = { 0 };
> > +  TPM_HANDLE tmp_handle = 0;
> > +
> > +  inPublic.publicArea.type = srk_type.type;
> > +  inPublic.publicArea.nameAlg = TPM_ALG_SHA256;
> > +  inPublic.publicArea.objectAttributes.restricted = 1;
> > +  inPublic.publicArea.objectAttributes.userWithAuth = 1;
> > +  inPublic.publicArea.objectAttributes.decrypt = 1;
> > +  inPublic.publicArea.objectAttributes.fixedTPM = 1;
> > +  inPublic.publicArea.objectAttributes.fixedParent = 1;
> > +  inPublic.publicArea.objectAttributes.sensitiveDataOrigin = 1;
> > +  inPublic.publicArea.objectAttributes.noDA = 1;
> > +
> > +  if (srk_type.type == TPM_ALG_RSA)
> > +{
> > +  inPublic.publicArea.parameters.rsaDetail.symmetric.algorithm = 
> > TPM_ALG_AES;
> > +  inPublic.publicArea.parameters.rsaDetail.symmetric.keyBits.aes = 128;
> > +  inPublic.publicArea.parameters.rsaDetail.symmetric.mode.aes = 
> > TPM_ALG_CFB;
> > +  inPublic.publicArea.parameters.rsaDetail.scheme.scheme = 
> > TPM_ALG_NULL;
> > +  inPublic.publicArea.parameters.rsaDetail.keyBits = 
> > srk_type.detail.rsa_bits;
> 
> In the officail TCG EK templates they pair RSA3072 with AES 256 and SHA384.
> I wonder whether this would not also make sense here?
Ok, I'll follow the template. 'grub_srk_type_t' can be extended to cover
those fields.

> Similar for ECC but I think you only use NIST P256 here iiuc.
> 
The '--asymmetric' argument allows the user to specify the non-default
algorithm, so it's still possible to use other ECC curves. In practice,
I guess NIST P256 is the only one really used.

> > +  inPublic.publicArea.parameters.rsaDetail.exponent = 0;
> > +}
> > +  else if (srk_type.type == TPM_ALG_ECC)
> > +{
> > +  inPublic.publicArea.parameters.eccDetail.symmetric.algorithm = 
> > TPM_ALG_AES;
> > +  inPublic.publicArea.parameters.eccDetail.symmetric.keyBits.aes = 128;
> > +  

Re: [PATCH v11 10/20] tpm2: Add TPM Software Stack (TSS)

2024-04-15 Thread Gary Lin via Grub-devel
On Fri, Apr 12, 2024 at 11:26:48AM -0400, Stefan Berger wrote:
> 
> 
> On 4/12/24 04:39, Gary Lin wrote:
> > From: Hernan Gatta 
> > 
> > A Trusted Platform Module (TPM) Software Stack (TSS) provides logic to
> > compose, submit, and parse TPM commands and responses.
> 
> compose and submit TPM commands and parse reponses.
> > 
> > A limited number of TPM commands may be accessed via the EFI TCG2
> > protocol. This protocol exposes functionality that is primarily geared
> > toward TPM usage within the context of Secure Boot. For all other TPM
> > commands, however, such as sealing and unsealing, this protocol does not
> > provide any help, with the exception of passthrough command submission.
> 
> Other platforms don't have EFI at all...
> 
The current target is the systems with EFI support. Since the EFI
protocol is only used to submit the commands, other platforms with a
proper grub_tcg2_submit_command() still can use the stack. For example,
tcg2-emu.c implements that function for grub-emu, so that the test
script can test key unsealing.

> > 
> > The SubmitCommand method allows a caller to send raw commands to the
> > system's TPM and to receive the corresponding response. These
> > command/response pairs are formatted using the TPM wire protocol. To
> > construct commands in this way, and to parse the TPM's response, it is
> > necessary to, first, possess knowledge of the various TPM structures, and,
> > second, of the TPM wire protocol itself.
> > 
> > As such, this patch includes a set of header files that define the
> > necessary TPM structures and TSS functions, implementations of various
> > TPM2_* functions (inventoried below), and logic to write and read command
> > and response buffers, respectively, using the TPM wire protocol.
> > 
> > Functions: TPM2_Create, TPM2_CreatePrimary, TPM2_EvictControl,
> > TPM2_FlushContext, TPM2_Load, TPM2_PCR_Read, TPM2_PolicyGetDigest,
> > TPM2_PolicyPCR, TPM2_ReadPublic, TPM2_StartAuthSession, TPM2_Unseal,
> > TPM2_LoadExternal, TPM2_HashSequenceStart, TPM2_SequenceUpdate,
> > TPM2_SequenceComplete, TPM2_Hash, TPM2_VerifySignature,
> 
> HashSequenceStart, SequenceUpdate and SequenceComplete don't have callers
> and could be removed.
> 
Ok, we won't use them in the forseeable future, so I'm fine to remove
them. I'll also remove the related structs and marshal/unmarshal
functions.

Thanks,

Gary Lin

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [PATCH v10 20/20] tests: Add tpm2_test

2024-04-15 Thread Gary Lin via Grub-devel
On Fri, Apr 12, 2024 at 12:09:36PM -0400, Stefan Berger wrote:
> 
> 
> On 4/9/24 04:30, Gary Lin via Grub-devel wrote:
> > For the tpm2 module, the TCG2 command submission function is the only
> > difference between the a QEMU instance and grub-emu. To test TPM key
> > unsealing with a QEMU instance, it requires an extra OS image to invoke
> > grub-protect to seal the LUKS key, rather than a simple grub-shell rescue
> > CD image. On the other hand, grub-emu can share the emulated TPM device
> > with the host, so that we can seal the LUKS key on host and test key
> > unsealing with grub-emu.
> > 
> > This test script firstly creates a simple LUKS image to be loaded as a
> > loopback device in grub-emu. Then an emulated TPM device is created by
> > swtpm_cuse and PCR 0 and 1 are extended.
> 
> My concern here would be that distros for example don't build swtpm with the
> CUSE interface but build it with the socket and chardev interfaces. If you
> don't want users to have to build their own version of swtpm then I would
> suggest to use either 'swtpm chardev' with the vtpm_proxy module (it is
> quite commonly available on recent distros) or 'swtpm socket'.
> 
> The chardev usage is for example described here and should be least involved
> to convert to:
> 
> https://github.com/stefanberger/swtpm/wiki/Using-the-Intel-TSS-with-swtpm#character-device-using-tpm_vtpm_proxy
> 
> You could start it like this with UnixIO control port (needs adjustment to
> swtpm_ioctl in your code).
> 
> swtpm chardev --vtpm-proxy --tpmstate dir=/tmp/myvtpm --tpm2 --ctrl
> type=unixio,path=/tmp/myvtpm/ctrl --flags startup-clear --daemon > logfile
> 
> No need to run 'swtpm_ioctl -i' and tpm2_startup with the startup-clear
> passed.
> 
> One of my test cases determines the created device (/dev/tpmXYZ) like this:
> 
> for ((i = 0; i < 200; i ++)); do
> if [ -z "${TPM_DEVICE}" ]; then
> TPM_DEVICE=$(sed -n 's,.*\(/dev/tpm[0-9]\+\).*,\1,p'
> "logfile")
> if [ -n "${TPM_DEVICE}" ]; then
> echo "Using ${TPM_DEVICE}."
> fi
> fi
> if [ -n "${TPM_DEVICE}" ]; then
> [ -c "${TPM_DEVICE}" ] && break
> fi
> sleep 0.1
> done
> 
> shutdown: sudo swtpm_ioctl -s --unix /tmp/myvtpm/ctrl
> 
> 
> Otherwise you could use the socket version described here:
> 
> https://github.com/stefanberger/swtpm/wiki/Using-the-Intel-TSS-with-swtpm#socket-interface
> 
> It needs the swtpm tcti as a dependency, though.
> 
Thanks for the suggestion. Using 'swtpm socket' requires additional changes
to grub-emu and grub-protect. To minimize the impact, I'd convert the test
script to use 'swtpm chardev'.

Gary Lin

>Stefan
> 
> > 
> > There are several test cases in the script to test various settings. Each
> > test case uses grub-protect to seal the LUKS password against PCR 0 and
> > PCR 1. Then grub-emu is launched to load the LUKS image, try to mount
> > the image with tpm2_key_protector_init and cryptomount, and verify the
> > result.
> > 
> > Based on the idea from Michael Chang.
> > 
> > Cc: Michael Chang 
> > Signed-off-by: Gary Lin 

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel