From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 6/7] tpm2-tools: do not enforce dependency on tpm2-abrmd
Date: Wed, 16 Jan 2019 12:43:41 +0100 [thread overview]
Message-ID: <875zuog74i.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20190115204308.GB2556@scaer> (Yann E. MORIN's message of "Tue, 15 Jan 2019 21:43:08 +0100")
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> Peter, All,
> On 2019-01-15 11:15 +0100, Peter Korsgaard spake thusly:
>> tpm2-tools is commonly used with the resource manager, tpm2-abrmd - But it
>> CAN be used without, E.G. by setting the TPM2TOOLS_TCTI_NAME environment
>> variable to communicate directly with the kernel driver:
>>
>> export TPM2TOOLS_TCTI_NAME=device
>>
>> For some use cases (E.G. initramfs) it makes sense to use tpm2-tools
>> without abrmd, so downgrade the dependency from select to imply, so abrmd is
>> enabled by default but can be explicitly disabled.
>>
>> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
>> ---
>> package/tpm2-tools/Config.in | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/package/tpm2-tools/Config.in b/package/tpm2-tools/Config.in
>> index cc87e2a1bf..f4622b4ec9 100644
>> --- a/package/tpm2-tools/Config.in
>> +++ b/package/tpm2-tools/Config.in
>> @@ -8,7 +8,7 @@ config BR2_PACKAGE_TPM2_TOOLS
>> select BR2_PACKAGE_LIBCURL
>> select BR2_PACKAGE_LIBGLIB2
>> select BR2_PACKAGE_OPENSSL
>> - select BR2_PACKAGE_TPM2_ABRMD # run-time
>> + imply BR2_PACKAGE_TPM2_ABRMD # run-time
> Sorry, but I reiterate my position: I don't like the use of 'imply'.
> Either the thing is mandatory, in which case we select it or depend on
> it, or the thing is optional, in which case we elt the user enable it.
I understand you don't like it, but what is the alternative? Just
mention the optional-but-likely-to-be-needed dependency in the help
text? That is IMHO worse than imply.
For this specific case, tpm2-tools fails with a somewhat confusing error
message if tpm2-abrmd isn't available unless a specific command line
option / environment variable is used:
# tpm2_pcrlist
** (process:8628): WARNING **: 11:38:39.606: Failed to create connection with service: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name com.intel.tss2.Tabrmd was not provided by any .service files
ERROR: Failed to initialize TABRMD TCTI context: 0xa0008
The solution is to set the TCTI name to device, either through the
TPM2TOOLS_TCTI_NAME environment variable or the --tcti option.
This is imho exactly the kind of use cases imply has been made for.
> Use of imply does not sound nice to me, because it is not authoritative.
> I'm afraid we get reports of users complaining that "sometimes the stuff
> is enabled when I do X, while sometmes it is not enabled when I do the
> same X.'
Is that any different than changing toolchain options or toggling
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS?
> The coutner argument has been that we were now trying to make sensible
> choices for the user, so that things "work out of the box". My position
> is that it is an illusion, because making things "just work" is more
> often than not more involving than just enabling a package.
I agree that we probably cannot do this perfectly, but a solution for
E.G. 80% of the use cases is still an improvement, as long as the
remaining 20% can still change things.
> For example, when dealing with TPM and such: keys and certs provisionning
> and checking the chain of trust and such is only scratching the surface.
> People that want to deal with this topic better know what they *are* doing,
> as it is a sensible topic. Those people will have to understand what they
> need if they do not already know.
Sure, but we can atleast ensure that the tpm2-tools utilites do not fail
out of the box because of a missing obscure dependency and that fairly
common use cases are possible.
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2019-01-16 11:43 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-15 10:15 [Buildroot] [PATCH v2 1/7] tpm2-tss: do not enforce -fstack-protector-all Peter Korsgaard
2019-01-15 10:15 ` [Buildroot] [PATCH v2 2/7] tpm2-tss: fix build with BR2_FORTIFY_SOURCE_1 Peter Korsgaard
2019-01-16 13:26 ` Peter Korsgaard
2019-01-25 7:28 ` Peter Korsgaard
2019-01-15 10:15 ` [Buildroot] [PATCH v2 3/7] tpm2-tools: always disable hardening options Peter Korsgaard
2019-01-16 13:25 ` Peter Korsgaard
2019-01-25 7:28 ` Peter Korsgaard
2019-01-15 10:15 ` [Buildroot] [PATCH v2 4/7] tpm2-abrmd: do not enforce -fstack-protector-all Peter Korsgaard
2019-01-16 13:25 ` Peter Korsgaard
2019-01-25 7:29 ` Peter Korsgaard
2019-01-15 10:15 ` [Buildroot] [PATCH v2 5/7] tpm2-abrmd: fix build with BR2_FORTIFY_SOURCE_1 Peter Korsgaard
2019-01-16 13:25 ` Peter Korsgaard
2019-01-25 7:29 ` Peter Korsgaard
2019-01-15 10:15 ` [Buildroot] [PATCH v2 6/7] tpm2-tools: do not enforce dependency on tpm2-abrmd Peter Korsgaard
2019-01-15 20:43 ` Yann E. MORIN
2019-01-16 11:43 ` Peter Korsgaard [this message]
2019-01-17 15:58 ` Yann E. MORIN
2019-01-17 19:01 ` Peter Korsgaard
2019-01-28 21:23 ` Yann E. MORIN
2019-01-28 22:08 ` Peter Korsgaard
2019-01-24 16:50 ` Arnout Vandecappelle
2019-01-25 15:03 ` Peter Korsgaard
2019-01-15 10:15 ` [Buildroot] [PATCH v2 7/7] tpm2-abrmd: S80tpm2-abrmd: create pid file at startup Peter Korsgaard
2019-01-16 13:26 ` Peter Korsgaard
2019-01-25 7:30 ` Peter Korsgaard
2019-01-16 13:25 ` [Buildroot] [PATCH v2 1/7] tpm2-tss: do not enforce -fstack-protector-all Peter Korsgaard
2019-01-25 7:28 ` Peter Korsgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875zuog74i.fsf@dell.be.48ers.dk \
--to=peter@korsgaard.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox