From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Jarkko Sakkinen" <jarkko@kernel.org>, <linux-integrity@vger.kernel.org>
Cc: <keyrings@vger.kernel.org>,
"David Woodhouse" <dwmw2@infradead.org>,
"Eric Biggers" <ebiggers@kernel.org>,
"James Bottomley" <James.Bottomley@hansenpartnership.com>,
"Ben Boeckel" <me@benboeckel.net>,
"David Howells" <dhowells@redhat.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
"Andrew Morton" <akpm@linux-foundation.org>,
"James Bottomley" <James.Bottomley@HansenPartnership.com>,
"Mimi Zohar" <zohar@linux.ibm.com>,
"Paul Moore" <paul@paul-moore.com>,
"James Morris" <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"open list:CRYPTO API" <linux-crypto@vger.kernel.org>,
"open list" <linux-kernel@vger.kernel.org>,
"open list:SECURITY SUBSYSTEM"
<linux-security-module@vger.kernel.org>
Subject: Re: [PATCH v3] KEYS: trusted: Use ASN.1 encoded OID
Date: Thu, 23 May 2024 17:29:56 +0300 [thread overview]
Message-ID: <D1H3GNK4GHSW.2DNFO64RJYXR2@kernel.org> (raw)
In-Reply-To: <D1H3DW5XHHBS.3V527WMDQ829U@kernel.org>
On Thu May 23, 2024 at 5:26 PM EEST, Jarkko Sakkinen wrote:
> On Thu May 23, 2024 at 5:20 PM EEST, Jarkko Sakkinen wrote:
> > There's no reason to encode OID_TPMSealedData at run-time, as it never
> > changes.
> >
> > Replace it with an encoded u8-array, which has the same number of
> > elements:
> >
> > 67 81 05 0A 01 05
> >
> > Include OBJECT IDENTIFIER (0x06) tag and length as the prologue so that
> > the OID can be simply copied to the blob leading to:
> >
> > 06 06 67 81 05 0A 01 05
> >
> > Since this in stationary place in the buffer it is guaranteed to always
> > fit and not further checks are required.
> >
> > Reviewed-by: David Howells <dhowells@redhat.com>
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
>
> Does not really substitute distribution kernel testing, which is
> IMHO essential for something like TPM2 boot in systemd but for
> simple patches like this, the following does a trivial smoke
> test:
>
> export LINUX_OVERRIDE_SRCDIR=<path to a kernel tree with a trusted keys patch>
> git clone https://gitlab.com/jarkkojs/linux-tpmdd-test.git
> cd linux-tpmdd-test
> cmake -Bbuild && make -Cbuild buildroot-prepare
> make -Cbuild/buildroot/build
> build/buildroot/build/images/run-tests.sh
>
> I'm planning to migrate at some point to systemd and make it
> appear more like distribution tho..
>
> For recompiling just kernel only thing needed is:
>
> rm -rf build/buildroot/build/build/linux-custom
> make -Cbuild/buildroot/build
>
> I've put this also to the MAINTAINERS entry of TPM driver although
> I use it also for keyrings etc. Also it is open for contributions
> via Gitlab merge requests (not requesting them per se but I'm open
> to such possibility).
Right and this is fully CI compatible with both Github and Gitlab
with only a single tweak: BR2_PACKAGE_HOST_QEMU needs to be added
to the qemu config. It is CI agnostic test environment to put
short.
I've had this also deployed to the CI in the past. It can run both
x86 and aarch64 based runners and even emulates hardware TPM in
three different modes (TPM 1.2, TPM 2.0 FIFO, TPM 2.0 CRB).
I've been just wondering why we need kernel tree changes for Gitlab
CI when you can pretty easily just bootstrap toolchain and qemu
and call it a day (and with trimmed builds it is quite fast too).
BR, Jarkko
prev parent reply other threads:[~2024-05-23 14:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 14:20 [PATCH v3] KEYS: trusted: Use ASN.1 encoded OID Jarkko Sakkinen
2024-05-23 14:26 ` Jarkko Sakkinen
2024-05-23 14:29 ` Jarkko Sakkinen [this message]
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=D1H3GNK4GHSW.2DNFO64RJYXR2@kernel.org \
--to=jarkko@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=me@benboeckel.net \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=zohar@linux.ibm.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).