public inbox for linux-integrity@vger.kernel.org
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Benjamin Marzinski <bmarzins@redhat.com>
Cc: Mike Snitzer <snitzer@kernel.org>,
	dm-devel@lists.linux.dev,  linux-integrity@vger.kernel.org,
	Alasdair Kergon <agk@redhat.com>,
	 Mimi Zohar <zohar@linux.ibm.com>,
	Roberto Sassu <roberto.sassu@huawei.com>,
	 Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	 Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
	 steven chen <chenste@linux.microsoft.com>
Subject: Re: [PATCH v2 00/10] Fix dm-ima bugs
Date: Mon, 4 May 2026 17:45:44 +0200 (CEST)	[thread overview]
Message-ID: <f90f2f8e-37c4-9412-1f33-b95f821aa7d6@redhat.com> (raw)
In-Reply-To: <20260429202108.2823261-1-bmarzins@redhat.com>

Applied, thanks.

Mikulas



On Wed, 29 Apr 2026, Benjamin Marzinski wrote:

> The dm-ima code does not guarantee that the dm_ima_measure_on_*
> functions will not be called at the same time. Since they modify and
> free shared memory, this can lead to Use-After-Free errors or garbage
> measurements. Further, they don't make sure that the state they measure
> corresponds to the actual device state. For instance if table_load()
> runs at the same time as do_resume() on a table swap,
> dm_ima_measure_on_device_resume() can end up thinking the wrong table is
> active. Or a concurrent dm_hash_rename() and a table swap, can end up
> with a the new active table still using the old name. This patchset
> makes sure the the dm-ima function are serialized and report the correct
> device state.
> 
> However, the code is still messier that in could be. This is because
> it duplicates the current measurement events and format. I would really
> like to know if that is necessary. Specifically, it currently measures
> the following dm device and table actions:
> 
> load
> clear
> rename
> resume
> remove
> 
> I don't see the benefit of reporting changes to the inactive table, or
> resumes where the device does not change state. From the user's point of
> view, the device is still the same after these events.  At the same
> time, it doesn't measure device creates if no table was loaded, so you
> can have situations where the the first measurement for a device is a
> rename or a remove. A more sensible set of actions to measure would be:
> 
> create
> table_swap
> rename
> remove
> 
> Also, the measurement format doesn't map well to how dm device's are
> actually set up, in a way that makes it harder for the code and records
> extraneous information. First, like I mentioned before, I don't see the
> benefit of measuring the inactive table. Second, the name, uuid, and
> major/minor numbers are properties of the device, not it's table (and dm
> devices can't have partitions, so the minor count will always be 1). I
> don't see a reason to store and occasinally log this information twice,
> if there is an active and incative table, and it forces extra
> coordination between the dm_ima_measure_on_* functions.
> 
> I'm wondering it we are stuck with the current events and format, now
> that this has been released? Or could we bump the version, and change
> what events we measure, and how we format the output?
> 
> Changes in v2:
> - 05/10: Switched from using atomics and barriers to using a spinlock to
>          serialize the dm_ima_measure_on_* functions
> - 05/10: Fixed typos in comments and commit message
> - 06/10: changed no_data string from "table_rename" to "device_rename"
> 
> If this patchset is going in largely as it is, I should point out that
> there are changes to the ima measurements in corner cases, where the
> data was previously incorrect (as mentioned in the patches). However
> it's possible, although I don't think very likely, that systems are
> expecting these incorrect measurements. We could bump the version number
> because of this possible change in the measurements, but IIUC, since
> this version number itself is part of the IMA measurements, that would
> guarantee that systems would get different measurements. 
> 
> Benjamin Marzinski (10):
>   dm-ima: remove dm_ima_reset_data()
>   dm-ima: remove broken last_target_measured logic
>   dm-ima: Remove status_flags from dm_ima_measure_on_table_load()
>   dm-ima: don't copy the active table to the inactive table
>   dm-ima: Fix UAF errors and measuring incorrect context
>   dm-ima: remove new_map from dm_ima_measure_on_device_clear
>   dm-ima: Fix issues with dm_ima_measure_on_device_rename
>   dm-ima: Handle race between rename and table swap
>   dm-ima: Fail more gracefully in dm_ima_measure_on_*
>   dm-ima: use active table's size if available
> 
>  drivers/md/dm-ima.c   | 492 +++++++++++++++++++-----------------------
>  drivers/md/dm-ima.h   |  68 ++++--
>  drivers/md/dm-ioctl.c | 146 +++++++++++--
>  drivers/md/dm.c       |   2 +-
>  4 files changed, 410 insertions(+), 298 deletions(-)
> 
> -- 
> 2.53.0
> 


      parent reply	other threads:[~2026-05-04 15:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-29 20:20 [PATCH v2 00/10] Fix dm-ima bugs Benjamin Marzinski
2026-04-29 20:20 ` [PATCH v2 01/10] dm-ima: remove dm_ima_reset_data() Benjamin Marzinski
2026-04-29 20:21 ` [PATCH v2 02/10] dm-ima: remove broken last_target_measured logic Benjamin Marzinski
2026-04-29 20:21 ` [PATCH v2 03/10] dm-ima: Remove status_flags from dm_ima_measure_on_table_load() Benjamin Marzinski
2026-04-29 20:21 ` [PATCH v2 04/10] dm-ima: don't copy the active table to the inactive table Benjamin Marzinski
2026-04-29 20:21 ` [PATCH v2 05/10] dm-ima: Fix UAF errors and measuring incorrect context Benjamin Marzinski
2026-04-29 20:21 ` [PATCH v2 06/10] dm-ima: remove new_map from dm_ima_measure_on_device_clear Benjamin Marzinski
2026-04-29 20:21 ` [PATCH v2 07/10] dm-ima: Fix issues with dm_ima_measure_on_device_rename Benjamin Marzinski
2026-04-29 20:21 ` [PATCH v2 08/10] dm-ima: Handle race between rename and table swap Benjamin Marzinski
2026-04-29 20:21 ` [PATCH v2 09/10] dm-ima: Fail more gracefully in dm_ima_measure_on_* Benjamin Marzinski
2026-04-29 20:21 ` [PATCH v2 10/10] dm-ima: use active table's size if available Benjamin Marzinski
2026-05-04 15:45 ` Mikulas Patocka [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=f90f2f8e-37c4-9412-1f33-b95f821aa7d6@redhat.com \
    --to=mpatocka@redhat.com \
    --cc=agk@redhat.com \
    --cc=bmarzins@redhat.com \
    --cc=chenste@linux.microsoft.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=nramas@linux.microsoft.com \
    --cc=roberto.sassu@huawei.com \
    --cc=snitzer@kernel.org \
    --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