From: Jarkko Sakkinen <jarkko@kernel.org>
To: Paul Moore <paul@paul-moore.com>
Cc: "Eric Snowberg" <eric.snowberg@oracle.com>,
"Mimi Zohar" <zohar@linux.ibm.com>,
"David Howells" <dhowells@redhat.com>,
"open list:SECURITY SUBSYSTEM"
<linux-security-module@vger.kernel.org>,
"David Woodhouse" <dwmw2@infradead.org>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>,
"Ard Biesheuvel" <ardb@kernel.org>,
"James Morris" <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Roberto Sassu" <roberto.sassu@huawei.com>,
"Dmitry Kasatkin" <dmitry.kasatkin@gmail.com>,
"Mickaël Salaün" <mic@digikod.net>,
"casey@schaufler-ca.com" <casey@schaufler-ca.com>,
"Stefan Berger" <stefanb@linux.ibm.com>,
"ebiggers@kernel.org" <ebiggers@kernel.org>,
"Randy Dunlap" <rdunlap@infradead.org>,
"open list" <linux-kernel@vger.kernel.org>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>
Subject: Re: [RFC PATCH v3 00/13] Clavis LSM
Date: Fri, 21 Mar 2025 19:22:21 +0200 [thread overview]
Message-ID: <Z92gTQj6QkedbH0K@kernel.org> (raw)
In-Reply-To: <CAHC9VhQMN6cgWbxdAgBNffpCAo=ogGdm4qBGS_kKdDmiT8b3cw@mail.gmail.com>
On Thu, Mar 20, 2025 at 05:36:41PM -0400, Paul Moore wrote:
> On Thu, Mar 20, 2025 at 12:29 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
> > > On Mar 6, 2025, at 7:46 PM, Paul Moore <paul@paul-moore.com> wrote:
> > > On March 6, 2025 5:29:36 PM Eric Snowberg <eric.snowberg@oracle.com> wrote:
>
> ...
>
> > >> Does this mean Microsoft will begin signing shims in the future without
> > >> the lockdown requirement?
> > >
> > > That's not a question I can answer, you'll need to discuss that with the UEFI SB people.
> >
> > Based on your previous lockdown comments, I thought you might have
> > some new information. Having lockdown enforcement has always been
> > a requirement to get a shim signed by Microsoft.
>
> I want to address two things, the first, and most important, is that
> while I am currently employed by Microsoft, I do not speak for
> Microsoft and the decisions and actions I take as an upstream Linux
> kernel maintainer are not vetted by Microsoft in any way. I think you
> will find that many upstream kernel maintainers operate in a similar
> way for a variety of very good reasons.
This is understood. If one takes a kernel maintainer role, one should
unconditionally disobey any vetting by the employer (even at the cost of
the job, or alternatively at the cost of giving up the maintainership).
And with you in particular I don't think anyone has any trust issues,
no matter which group of villains you might be employed by ;-)
>
> The second issue is that my main focus is on ensuring we have a
> secure, safe, and well maintained LSM subsystem within the upstream
> Linux kernel. While I do care about downstream efforts, e.g. UEFI
> Secure Boot, those efforts are largely outside the scope of the
> upstream Linux kernel and not my first concern. If the developer
> groups who are focused on things like UEFI SB want to rely on
> functionality within the upstream Linux kernel they should be prepared
> to stand up and contribute/maintain those features or else they may go
> away at some point in the future. In very blunt terms, contribute
> upstream or Lockdown dies.
Could Lockdown functionality be re-implemented with that eBPF LSM? I
have not really looked into it so far...
BR, Jarkko
next prev parent reply other threads:[~2025-03-21 17:22 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 15:55 [RFC PATCH v3 00/13] Clavis LSM Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 01/13] certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check Eric Snowberg
2024-10-17 16:13 ` Jarkko Sakkinen
2024-10-17 16:50 ` Eric Snowberg
2024-12-23 13:21 ` Mimi Zohar
2025-01-03 23:15 ` Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 02/13] certs: Introduce ability to link to a system key Eric Snowberg
2024-10-17 16:16 ` Jarkko Sakkinen
2024-10-17 16:53 ` Eric Snowberg
2024-12-23 16:11 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 03/13] clavis: Introduce a new system keyring called clavis Eric Snowberg
2024-10-17 16:50 ` Jarkko Sakkinen
2024-10-17 20:34 ` Eric Snowberg
2024-10-17 21:16 ` Jarkko Sakkinen
2024-12-24 0:01 ` Mimi Zohar
2025-01-03 23:27 ` Eric Snowberg
2025-01-05 11:43 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 04/13] keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE) Eric Snowberg
2024-10-17 19:20 ` Jarkko Sakkinen
2024-10-17 21:42 ` Eric Snowberg
2024-10-17 21:58 ` Jarkko Sakkinen
2024-12-24 0:17 ` Mimi Zohar
2025-01-03 23:28 ` Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 05/13] clavis: Introduce a new key type called clavis_key_acl Eric Snowberg
2024-10-18 5:21 ` Ben Boeckel
2024-10-18 15:42 ` Eric Snowberg
2024-10-18 16:55 ` Ben Boeckel
2024-10-18 21:55 ` Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 06/13] clavis: Populate clavis keyring acl with kernel module signature Eric Snowberg
2024-10-17 19:27 ` Jarkko Sakkinen
2024-10-17 15:55 ` [RFC PATCH v3 07/13] keys: Add ability to track intended usage of the public key Eric Snowberg
2025-02-06 20:13 ` Jarkko Sakkinen
2025-02-07 23:09 ` Eric Snowberg
2025-02-12 12:42 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 08/13] clavis: Introduce new LSM called clavis Eric Snowberg
2024-10-23 2:25 ` sergeh
2024-10-23 19:25 ` Eric Snowberg
2024-10-24 19:57 ` sergeh
2024-12-24 17:43 ` Mimi Zohar
2025-01-03 23:32 ` Eric Snowberg
2025-01-05 12:59 ` Mimi Zohar
2024-10-17 15:55 ` [RFC PATCH v3 09/13] clavis: Allow user to define acl at build time Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 10/13] efi: Make clavis boot param persist across kexec Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 11/13] clavis: Prevent boot param change during kexec Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 12/13] clavis: Add function redirection for Kunit support Eric Snowberg
2024-10-17 15:55 ` [RFC PATCH v3 13/13] clavis: " Eric Snowberg
2024-12-24 1:11 ` Mimi Zohar
2024-12-23 12:09 ` [RFC PATCH v3 00/13] Clavis LSM Mimi Zohar
2025-01-03 23:14 ` Eric Snowberg
2025-01-04 4:48 ` Paul Moore
2025-01-06 3:40 ` Paul Moore
2025-01-06 17:15 ` Eric Snowberg
2025-02-27 20:41 ` Mimi Zohar
2025-02-27 22:22 ` Paul Moore
2025-02-28 14:08 ` Mimi Zohar
2025-02-28 16:14 ` Paul Moore
2025-02-28 17:18 ` Mimi Zohar
2025-03-03 22:38 ` Paul Moore
2025-03-04 12:53 ` Mimi Zohar
2025-03-05 0:19 ` Paul Moore
2025-03-05 1:49 ` Mimi Zohar
2025-03-05 2:09 ` Paul Moore
2025-03-05 2:20 ` Mimi Zohar
2025-03-05 2:24 ` Paul Moore
2025-02-28 17:51 ` Eric Snowberg
2025-03-03 22:40 ` Paul Moore
2025-03-04 14:46 ` Eric Snowberg
2025-03-05 0:23 ` Paul Moore
2025-03-05 21:29 ` Eric Snowberg
2025-03-06 1:12 ` Paul Moore
2025-03-06 22:28 ` Eric Snowberg
2025-03-07 2:46 ` Paul Moore
2025-03-20 16:24 ` Eric Snowberg
2025-03-20 21:36 ` Paul Moore
2025-03-21 16:37 ` Eric Snowberg
2025-03-21 18:57 ` Paul Moore
2025-03-21 21:20 ` Eric Snowberg
2025-03-21 22:13 ` Paul Moore
2025-03-21 22:56 ` Eric Snowberg
2025-03-22 2:00 ` Paul Moore
2025-03-21 17:22 ` Jarkko Sakkinen [this message]
2025-03-21 19:05 ` Paul Moore
2025-03-20 22:40 ` James Bottomley
2025-03-21 16:40 ` Eric Snowberg
2025-03-21 16:55 ` James Bottomley
2025-03-21 20:15 ` Eric Snowberg
2025-03-21 20:53 ` James Bottomley
2025-03-24 17:44 ` Eric Snowberg
2025-03-21 17:08 ` Jarkko Sakkinen
2025-03-04 22:24 ` Jarkko Sakkinen
2025-03-05 0:25 ` Paul Moore
2025-03-05 0:29 ` Jarkko Sakkinen
2025-03-01 2:20 ` Jarkko Sakkinen
2025-03-01 2:19 ` Jarkko Sakkinen
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=Z92gTQj6QkedbH0K@kernel.org \
--to=jarkko@kernel.org \
--cc=ardb@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ebiggers@kernel.org \
--cc=eric.snowberg@oracle.com \
--cc=herbert@gondor.apana.org.au \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=rdunlap@infradead.org \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=stefanb@linux.ibm.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 NNTP newsgroup(s).