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:43:44 -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: <ZJhuw3MaFjW5Bocw@itl-email>
References: <20230624230950.2272-1-demi@invisiblethingslab.com>
 <20230624230950.2272-4-demi@invisiblethingslab.com>
 <0b22e328-40e1-54d7-367c-96059a3fef7c@gmail.com>
 <ZJhlGCP0gTz7T3gG@itl-email>
 <81c94a1e-b316-c195-402c-01776f3200dc@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="xgxcetYBA/qMp0pW"
Content-Disposition: inline
In-Reply-To: <81c94a1e-b316-c195-402c-01776f3200dc@gmail.com>
Precedence: bulk


--xgxcetYBA/qMp0pW
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Sun, 25 Jun 2023 12:43:44 -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 06:33:33PM +0200, Milan Broz wrote:
> On 6/25/23 18:02, Demi Marie Obenour wrote:
> > 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-* syml=
inks
> > > (as response to the change udev event followed by internal udev blkid=
 scan)?
> >=20
> > 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.
> >=20
> > > If it is a private device, that is ok. But for a visible device I thi=
nk
> > > that it breaks some assumptions in userspace (presence of symlinks me=
ntioned
> > > above etc).
> >=20
> > 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.
> >=20
> > > So, what is the exact use for this patch?
> >=20
> > 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.
> But this is not clear from the patch header. I guess you also need
> to disable udev inotify on close on write, which will trigger device scan=
 too.
>=20
> BTW we use exactly this scenario in cryptsetup for years with existing fl=
ags
> (DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG | DM_UDEV_DISABLE_DISK_RULES_FLAG
> DM_UDEV_DISABLE_OTHER_RULES_FLAG) - just rules are ignored while uevent i=
s still
> sent.
> Anyway, not sure we need another way to disable it; I just asked do you n=
eed it.

How can one set these flags using the raw kernel ioctls?  The code I am
working on does not use libdevmapper at all and just uses the kernel API
directly.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

--xgxcetYBA/qMp0pW
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmSYbsQACgkQsoi1X/+c
IsG7Lg/+JO5Xx1J/OAEBlAdC5MHRtdJVoYorTf91RrYG3eFJcxMF8EjoKbwFUL+Q
NzQ6bpzZx7QUHKybUCJD9h2OYBz1y5gUllfw8nbffxncrlWLuIEuuFah9pJQSz1P
WQD0g8KFCpW0atLhAaEYJEdU6eABOL53une4H3NShRUZ0UR5Mj3hAWNUuq2GL+QA
VmA1Riz/w8l3ynOucuexpefC+s4UMn1kel4PYVRQkD81UFn5Qn/OtwNbabJwSA2P
XyvQHcEEsKbdsd7hYyxLB1JgPRtp83qLI7uclQofJlFpaxPN/1apjaw049IX1akY
OZOGaUWIG/xyXd9zh7mwHFf37bvjwLEzASEyKKA4btO/Lsql8zpUmxuOkN6/xYoo
5fRVYLle1lXg2l1Pe55Igu65Z/n+zeWq1oxi3WA1zIOFyVOzR6Jp6g4g4u7X7iBO
1HbPca1foLtfdEL47/55ZyikIi4Z1Mu7v5gZDZnwdtRB2oklj1VyWsjFZzPNRo7P
UJY93Ldmjgg26eDukMQNYQGcPXb4+7eo90C9KkaDoWP2ykyWiStmDBZviYrkSp0j
8c1VfdvnieL9maPHq5gH8SyzSK1Q9Z7J1zptSe6+7xrhd3cc3AlJbLvP1EBwU5fX
ZfF4M4f+2H72QR8ATh4akixRJ9FZs64YoRKKYWxVvTiOd5GCCa0=
=CIIC
-----END PGP SIGNATURE-----

--xgxcetYBA/qMp0pW--