Re: Looking for users of userfaultfd(2) syscall in Fedora

Adrian Reber <[email protected]> Tue, 6 Apr 2021 19:07:18 +0200
Newsgroups gmane.linux.redhat.fedora.devel,gmane.linux.redhat.fedora.selinux
Message-ID <[email protected]>
On Tue, Apr 06, 2021 at 06:57:27PM +0200, Ondrej Mosnacek wrote:
> Hi all,
> 
> Kernel 5.12 added support to SELinux for controlling access to the
> userfaultfd interface [1][2] and we'd like to implement this in
> Fedora's selinux-policy. However, once we add the corresponding class
> to the policy, all SELinux domains for which we don't add the
> appropriate rules will have any usage of userfaultfd(2) denied.
> 
> Therefore, we would like to identify as many users of this syscall as
> possible before we make that change, so that we can add and test all
> the needed rules in one go, minimizing the amount of denials found
> after the fact. My understanding is that userfaultfd(2) doesn't have
> many users among system services, so it should be possible to catch
> most/all of them in advance.
> 
> So if you know that your (or any other) Fedora component uses
> userfaultfd(2), please let us know. AFAIK, at least QEMU most likely
> uses it, so we'll have that one on our radar, but we'd like to know if
> there are any other programs/services we need to cover.

CRIU can use userfaultfd to lazy migrate processes from one host to
another. It can be also triggered from runc when migrating containers.
As far as I know userfaultfd based container migration is not exposed in
any container engine above the level of runc.

		Adrian

_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEV/k5jAN2FYx6uDoXgsk3jtPEkGoFAmBslUYACgkQgsk3jtPE
kGovgA/+MKcWGdapqy9wvWrTwYa9Jb8REdEju5ELZX9C+kfBpdKgkEGXQkUuu/1Q
BhdSlV3wqtDZQoi5WlSbHljhxUNfFOyRz8Xtj7IvAlYtjsSCg/ft0yxO2m88rvv3
HHO8V9wK7WiOc6aqbwTQfiyURjefDosb6Hf/N4Tf060DJRSjRN8Wyox9J0wbNTPp
YFL1W3xrBJrfS4cAgTruZTbaHt49h1ly2zR0zuf/L0JHbERQGIrKiIAgu28zvbN9
QMRewLrd2sKtPUPuRLmgwO7QtG/AfSvR4520CRcSHZjQ9RkJWDMUsXiQe5iEI/A8
D9jFL8CGWWEIY2gi+Lcbk6OCgs+Qvj3E5gWX+U4ZIwQjCSLGdAIQEHOmlwGzMhyZ
E+cEvf9xnrhroRTt9oONA+xLerV1DhXXorhGj6N9BKppT8eFkQUCHu2j6n9tRIPW
zgPN5Y+t4UgMk9MXlPHGgdG78P5tW81J/WYVR/4zm5ZPOvfjahlumlJqI3lPVUSG
Aqb3BZRn7vT4zgHv5cJ8HGorLfqZIJ9bzSpCtYvm6/bjNp1xSO5HwSZKYNfCHC5R
GLaWBjzNoBxnr7WDrR0/7zA7nmvDHoRCSdtlhx5TY3r6KcFs9uCBLhLP5shfBUeu
pAjeA4CMxABd03LHvcILgMixfLLjX3QDyctwijeAsvg0aHj55+c=
=BimK
-----END PGP SIGNATURE-----