From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: keyrings@vger.kernel.org, Ira Weiny <ira.weiny@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Tyler Hicks <tyhicks@canonical.com>,
Keith Busch <keith.busch@intel.com>,
David Howells <dhowells@redhat.com>,
Vishal Verma <vishal.l.verma@intel.com>,
James Bottomley <jejb@linux.ibm.com>,
Mimi Zohar <zohar@linux.ibm.com>,
linux-integrity@vger.kernel.org, ecryptfs@vger.kernel.org,
Roberto Sassu <roberto.sassu@huawei.com>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/6] security/keys/encrypted: Break module dependency chain
Date: Thu, 21 Mar 2019 15:48:31 +0200 [thread overview]
Message-ID: <20190321134831.GC4603@linux.intel.com> (raw)
In-Reply-To: <20190321134549.GB4603@linux.intel.com>
On Thu, Mar 21, 2019 at 03:45:49PM +0200, Jarkko Sakkinen wrote:
> On Tue, Mar 19, 2019 at 02:01:44PM -0700, Dan Williams wrote:
> > On Mon, Mar 18, 2019 at 11:18 PM Dan Williams <dan.j.williams@intel.com> wrote:
> > >
> > > With v5.1-rc1 all the nvdimm sub-system regression tests started failing
> > > because the libnvdimm module failed to load in the qemu-kvm test
> > > environment. Critically that environment does not have a TPM. Commit
> > > 240730437deb "KEYS: trusted: explicitly use tpm_chip structure..."
> > > started to require a TPM to be present for the trusted.ko module to load
> > > where there was no requirement for that before.
> > >
> > > Rather than undo the "fail if no hardware" behavior James points out
> > > that the module dependencies can be broken by looking up the key-type by
> > > name. Remove the dependencies on the "key_type_trusted" and
> > > "key_type_encrypted" symbol exports, and clean up other boilerplate that
> > > supported those exports in different configurations.
> >
> > Any feedback? Was hoping to get at least patch1 in the queue for
> > v5.1-rc2 since this effectively disables the nvdimm driver on typical
> > configurations. Jarkko, would you be willing to merge it since the
> > regression came through your tree?
>
> Yes, of course. The feedback has been extremely passive because I've
> been sick leave for the early week :-)
>
> Before I'm merging this I'm just thinking that would it be better
> idea to merge a patch for trusted.c that reverts the old behavior
> with cc to stable and fixes tags as I said in my earlier response.
>
> It would less intrusive for stable kernels. Lets quickly sort out
> the best strategy before merging.
I.e. the way I see the situation:
1. Reverting the old behavior in the sense that missing TPM does
not prevent init of trusted.ko should be done right now.
2. Your patch could be definitely merged but not as a bug fix.
3. At some point we could consider failing the init of trusted.ko
if TPM is missing because that is kind of senseful anyway with
better testing now that we understand the dependency context
better.
prev parent reply other threads:[~2019-03-21 13:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-19 6:06 [PATCH 0/6] security/keys/encrypted: Break module dependency chain Dan Williams
[not found] ` <155297557534.2276575.16264199708584900090.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2019-03-19 6:06 ` [PATCH 4/6] security/keys/ecryptfs: Drop direct dependency on key_type_encrypted Dan Williams
2019-03-19 21:01 ` [PATCH 0/6] security/keys/encrypted: Break module dependency chain Dan Williams
2019-03-19 21:08 ` James Bottomley
2019-03-19 21:23 ` Dan Williams
2019-03-20 1:20 ` Mimi Zohar
2019-03-21 13:45 ` Jarkko Sakkinen
2019-03-21 13:48 ` 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=20190321134831.GC4603@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dhowells@redhat.com \
--cc=ecryptfs@vger.kernel.org \
--cc=ira.weiny@intel.com \
--cc=jejb@linux.ibm.com \
--cc=keith.busch@intel.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=roberto.sassu@huawei.com \
--cc=tyhicks@canonical.com \
--cc=vishal.l.verma@intel.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).