linux-kernel - Re: [PATCH] dm: introduce a no open flag for deferred remove

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 25 Jan 2022 00:20:25 +0000
From:   Alasdair G Kergon <agk@...hat.com>
To:     Brian Geffon <bgeffon@...gle.com>
Cc:     Alasdair Kergon <agk@...hat.com>,
        Mike Snitzer <snitzer@...hat.com>, dm-devel@...hat.com,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dm: introduce a no open flag for deferred remove

On Mon, Jan 24, 2022 at 10:25:47AM -0500, Brian Geffon wrote:
> Thank you for looking at this. There are a few reasons this might be
> useful, the first is if you're trying to speed up a graceful teardown
> of the device by informing userspace that this device is going to be
> removed in the near future. Another might be on systems where it might
> be worthwhile to not have users with CAP_DAC_OVERRIDE be able to open
> the device. The logic on this second case is that, suppose you have a
> dm-crypt block device which is backing swap, the data on this device
> is ephemeral so a flow might be to setup swap followed by dmsetup
> remove --deferred /dev/mapper/encrypted-swap. This will guarantee that
> as soon as swap is torn down the encrypted block device is dropped,
> additionally with this new flag you'll be guaranteed that there can be
> no further opens on it.

And is that the reason you propose this?
- You want a special exclusive 'one time open' device that 
  self-destructs when closed?

> No, this is fully backwards compatible with the current deferred
> remove behavior, it's not required. Additionally, since on the actual
> remove userspace would receive an -ENXIO already once the remove
> process has started it seems reasonable to return -ENXIO in the
> deferred remove case when this flag is enabled.

Well I feel it does break existing semantics which is why we wrote
the code the way we did.  The state can be long-lived, the code
that has it open might legitimately want to open it again in
parallel etc. - in general this seems a bad idea.

But if the reason for this is basically "make it harder for 
anything else to access my encrypted swap" and to deliberately
prevent access, then let's approach the requirement from that angle.
Are there alternative implementations with interventions at different
points?  Are there similar requirements for devices that don't need
deferred remove?  If this is indeed the best place to insert this type
of restriction, then we should label it and document it accordingly so
people don't mistakenly use it for the 'normal' case.  (We always keep
libdevmapper and dmsetup in sync with kernel interface extensions, so
we'd seek a tiny patch to do that too.)

Alasdair