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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <loom.20150316T114052-105@post.gmane.org>
Date:	Mon, 16 Mar 2015 10:45:37 +0000 (UTC)
From:	Thomas Martitz <kugel@...kbox.org>
To:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/21] userfaultfd: add new syscall to provide memory externalization

Andrea Arcangeli <aarcange <at> redhat.com> writes:

> 
> Once an userfaultfd has been created and certain region of the process
> virtual address space have been registered into it, the thread
> responsible for doing the memory externalization can manage the page
> faults in userland by talking to the kernel using the userfaultfd
> protocol.
> 
> poll() can be used to know when there are new pending userfaults to be
> read (POLLIN).
> 


Hello,

I'm wondering why a new syscall was chosen over a simple special file
/dev/userfault (analogous to /dev/shm) to obtain an fd. In my book the
special file has only advantanges: no additional syscall is needed, system
admins can tweak access to this feature via normal file permissions, and
signaling the availability of the feature in the kernel simply by the
existence of the dev file.

I already wondered the same for memfd(). Here I can perhaps follow that
there is a need such fds before /dev is mounted (because PID1 might need
it). But not for this case as devtmpfs should be mounted early enough.

Not saying it's the wrong decision, but I want to learn about the rationale.

Best regards.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ