Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: iac594737:Fastmail
Date:   Sun, 25 Jun 2023 12:02:29 -0400
From:   Demi Marie Obenour <demi@invisiblethingslab.com>
To:     Milan Broz <gmazyland@gmail.com>, Alasdair Kergon <agk@redhat.com>,
        Mike Snitzer <snitzer@kernel.org>, dm-devel@redhat.com
Cc:     linux-kernel@vger.kernel.org
Subject: Re: [dm-devel] [PATCH v2 3/4] dm ioctl: Allow userspace to suppress
 uevent generation
Message-ID: <ZJhlGCP0gTz7T3gG@itl-email>
References: <20230624230950.2272-1-demi@invisiblethingslab.com>
 <20230624230950.2272-4-demi@invisiblethingslab.com>
 <0b22e328-40e1-54d7-367c-96059a3fef7c@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="LLikrifq3elm0+u6"
Content-Disposition: inline
In-Reply-To: <0b22e328-40e1-54d7-367c-96059a3fef7c@gmail.com>
Precedence: bulk


--LLikrifq3elm0+u6
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Sun, 25 Jun 2023 12:02:29 -0400
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Milan Broz <gmazyland@gmail.com>, Alasdair Kergon <agk@redhat.com>,
	Mike Snitzer <snitzer@kernel.org>, dm-devel@redhat.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [dm-devel] [PATCH v2 3/4] dm ioctl: Allow userspace to suppress
 uevent generation

On Sun, Jun 25, 2023 at 03:25:38PM +0200, Milan Broz wrote:
> On 6/25/23 01:09, Demi Marie Obenour wrote:
> > Userspace can use this to avoid spamming udev with events that udev
> > should ignore.
>=20
> Well, does it also mean that udev will not create /dev/disk/by-* symlinks
> (as response to the change udev event followed by internal udev blkid sca=
n)?

In the use-case I have for this feature (block devices for Qubes VMs)
the blkid scan is unwanted and there are udev rules to prevent this.

> If it is a private device, that is ok. But for a visible device I think
> that it breaks some assumptions in userspace (presence of symlinks mentio=
ned
> above etc).

The devices I am considering are implementation details of a userspace
process.  Nobody else should be opening them.  Ideally, no other
userspace process would even know they exist, at least without mucking
around in /proc or using ptrace.

> So, what is the exact use for this patch?

Ephemeral devices that are created, opened, marked for deferred removal,
assigned to a Xen VM (needs another patch currently being worked on),
and then closed.  udev has no business scanning these devices, and
indeed for it to scan them at all would be a security vulnerability
since their contents are under guest control.  There are udev rules to
ignore these devices, but for udev to even process the event wastes CPU
time and delays processing of other events that actually matter.  The
only symlink that possibly ought to be created is /dev/disk/by-diskseq
and I can just do that myself.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

--LLikrifq3elm0+u6
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmSYZRgACgkQsoi1X/+c
IsHJyA/+IJjlQ3TEADPdYhQeK6IxVs0Ggy0keFLY6+r4jHI5FM3SJ99om+Iu8WkN
jQ2iQ24VyeO3lu3J6Y5GkpkJ6qLvfY0HpqgN6+2TKQoOgXyYuvGRODoFPpB/xA41
jtPTIGtZF+U9AdweW9p0W63z3tTf9v9tDVFB0XF8F0Bp3/cWdSrS6BbhC9BFCqke
0c5JNsz+OVSx0C7VJ+SYEWZ6Va/DM9tybZpygumsyu3ZKZjyFdyL23x1e0HYKZis
rAr39c2ntv0VtwGmDFly6oWLzdhtkDXahJ7DvQKt4cpslDfrwMjgLNpvbRj49RO3
LcJWNpoXm9vNfzIr/p2T3NUajczXCmygE5OvIi5286tOjU/LdE9b2Fgjhpbsh6+3
leOU3ntYPrW9brLPExg5PaJTa6q4ZGr8YiOfv40lOlaHjG6I9QcaPEBVBBJ3QQ5L
VTc0XPyzMJxKLSNsM5jqxgtKt+uFhqNqkGwKemIvabOjWaLwZAYj+TpJU4HNFdaw
BldSECUfgCagcYsSFpvwcTMTdV48bdlN4hJUXxPBlVcJ93TldBop95mp/mjLMeAr
hiQvd9MCHKJpRRZwTO214eFYejYVEntxYYrk6nfWRz8lmrWiTS+hFE+4bXZ0MdJY
bV4yGsUBfTpS1PM4dHMxmF3sELoKTjo6ssSHhqfeyi2DMxgOmdo=
=1n/o
-----END PGP SIGNATURE-----

--LLikrifq3elm0+u6--