From: Milan Broz <gmazyland@gmail.com>
To: Eric Biggers <ebiggers@kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>
Cc: Lorenz Kofler <lorenz@sigma-star.at>,
Mike Snitzer <snitzer@kernel.org>,
Benjamin Marzinski <bmarzins@redhat.com>,
Alasdair Kergon <agk@redhat.com>,
dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
upstream+dm@sigma-star.at, David Howells <dhowells@redhat.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
keyrings@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] dm-integrity: support keys in the kernel keyring
Date: Sun, 4 Oct 2026 09:44:57 +0200 [thread overview]
Message-ID: <d737b17e-7872-4afb-b4c2-bfa8f4e119df@gmail.com> (raw)
In-Reply-To: <20261002201419.GA205250@google.com>
On 10/2/26 10:14 PM, Eric Biggers wrote:
...
> From what I understand, the point of the keyring support in
> dm-{crypt,inlinecrypt,integrity} is:
>
> - To support "trusted" keys. But that is not what was actually
> implemented in dm-inlinecrypt.
>
> - To avoid having the key be readable with STATUSTYPE_TABLE. But that
> is not what was actually implemented in dm-inlinecrypt. Keyrings are
> also unnecesary to solve that problem.
There is more to that
- to avoid key cached in dm-crypt (or other target)
(dmsetup must be able to retrieve mapping table in the form directly
reusable for recreating DM mapping, so raw key must be available)
- to avoid inclusion of key in DM ioctl calls (mapping table again)
- to somehow simplify keyring handling was used already by other userspace tools
(just reference existing keyring instead of creating new one)
>
> - To cause security bugs such as https://lwn.net/Articles/1090568/ .
> Since otherwise things aren't exciting enough, I guess.
:-) But TBH, this can happen in any other subsystem working with keys.
That said, I see keyring as incredibly complex code with complicated CLI tool...
Anyway, DM targets should be unified.
Userspace support will be tricky, but that is another issue (we have full support
for dm-crypt, dm-integrtity maybe requires some API changes. Will check once
kernel get the support.)
Milan
prev parent reply other threads:[~2026-10-04 7:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 6:27 [RFC PATCH 0/1] " Lorenz Kofler
2026-09-28 6:27 ` [RFC PATCH 1/1] " Lorenz Kofler
2026-09-30 15:00 ` Mikulas Patocka
2026-10-02 9:12 ` Lorenz Kofler
2026-10-02 11:48 ` Mikulas Patocka
2026-10-02 20:14 ` Eric Biggers
2026-10-02 21:09 ` Mikulas Patocka
2026-10-04 7:44 ` Milan Broz [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=d737b17e-7872-4afb-b4c2-bfa8f4e119df@gmail.com \
--to=gmazyland@gmail.com \
--cc=agk@redhat.com \
--cc=bmarzins@redhat.com \
--cc=dhowells@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=ebiggers@kernel.org \
--cc=jarkko@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenz@sigma-star.at \
--cc=mpatocka@redhat.com \
--cc=snitzer@kernel.org \
--cc=upstream+dm@sigma-star.at \
/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
all inboxes | Powered by JetHome®