On Thu, Mar 14, 2019 at 9:16 AM Andrea Arcangeli wrote:
> So this will be for who's paranoid and prefers to disable userfaultfd
> as a whole as an hardening feature like the bpf sysctl allows: it will
> allow to block uffd syscall without having to rebuild the kernel with
> CONFIG_USERFAULTFD=n in
On Wed, Mar 13, 2019 at 10:50:48AM -0700, Mike Kravetz wrote:
> On 3/12/19 11:00 PM, Peter Xu wrote:
> > On Tue, Mar 12, 2019 at 12:59:34PM -0700, Mike Kravetz wrote:
> >> On 3/11/19 2:36 AM, Peter Xu wrote:
> >>>
> >>> The "kvm" entry is a bit special here only to make sure that existing
> >>> use
On Thu, Mar 14, 2019 at 11:58:15AM +0100, Paolo Bonzini wrote:
> On 14/03/19 00:44, Andrea Arcangeli wrote:
> > Then I thought we can add a tristate so an open of /dev/kvm would also
> > allow the syscall to make things more user friendly because
> > unprivileged containers ideally should have writ
On 14/03/19 16:23, Alexei Starovoitov wrote:
> On Thu, Mar 14, 2019 at 4:00 AM Paolo Bonzini wrote:
>>
>> On 14/03/19 00:44, Andrea Arcangeli wrote:
>>> Then I thought we can add a tristate so an open of /dev/kvm would also
>>> allow the syscall to make things more user friendly because
>>> unpriv
On Thu, Mar 14, 2019 at 4:00 AM Paolo Bonzini wrote:
>
> On 14/03/19 00:44, Andrea Arcangeli wrote:
> > Then I thought we can add a tristate so an open of /dev/kvm would also
> > allow the syscall to make things more user friendly because
> > unprivileged containers ideally should have writable mo
On 14/03/19 00:44, Andrea Arcangeli wrote:
> Then I thought we can add a tristate so an open of /dev/kvm would also
> allow the syscall to make things more user friendly because
> unprivileged containers ideally should have writable mounts done with
> nodev and no matter the privilege they shouldn'
On 3/13/19 4:55 PM, Andrea Arcangeli wrote:
> On Wed, Mar 13, 2019 at 01:01:40PM -0700, Mike Kravetz wrote:
>> On 3/13/19 11:52 AM, Andrea Arcangeli wrote:
>>> Unless somebody suggests a consistent way to make hugetlbfs "just
>>> work" (like we could achieve clean with CRIU and KVM), I think Oracle
On Wed, Mar 13, 2019 at 01:01:40PM -0700, Mike Kravetz wrote:
> On 3/13/19 11:52 AM, Andrea Arcangeli wrote:
> >
> > hugetlbfs is more complicated to detect, because even if you inherit
> > it from fork(), the services that mounts the fs may be in a different
> > container than the one that Oracle
Hi Paolo,
On Wed, Mar 13, 2019 at 03:12:28PM -0400, Paolo Bonzini wrote:
>
> > On Wed, Mar 13, 2019 at 09:22:31AM +0100, Paolo Bonzini wrote:
> > Unless somebody suggests a consistent way to make hugetlbfs "just
> > work" (like we could achieve clean with CRIU and KVM), I think Oracle
> > will ne
On 3/13/19 11:52 AM, Andrea Arcangeli wrote:
>
> hugetlbfs is more complicated to detect, because even if you inherit
> it from fork(), the services that mounts the fs may be in a different
> container than the one that Oracle that uses userfaultfd later on down
> the road from a different context
> On Wed, Mar 13, 2019 at 09:22:31AM +0100, Paolo Bonzini wrote:
> Unless somebody suggests a consistent way to make hugetlbfs "just
> work" (like we could achieve clean with CRIU and KVM), I think Oracle
> will need a one liner change in the Oracle setup to echo into that
> file in addition of r
Hello,
On Wed, Mar 13, 2019 at 09:22:31AM +0100, Paolo Bonzini wrote:
> On 13/03/19 07:00, Peter Xu wrote:
> >> However, I can imagine more special cases being added for other users.
> >> And,
> >> once you have more than one special case then you may want to combine them.
> >> For example, kvm
On 3/12/19 11:00 PM, Peter Xu wrote:
> On Tue, Mar 12, 2019 at 12:59:34PM -0700, Mike Kravetz wrote:
>> On 3/11/19 2:36 AM, Peter Xu wrote:
>>>
>>> The "kvm" entry is a bit special here only to make sure that existing
>>> users like QEMU/KVM won't break by this newly introduced flag. What
>>> we n
On 13/03/19 07:00, Peter Xu wrote:
>> However, I can imagine more special cases being added for other users. And,
>> once you have more than one special case then you may want to combine them.
>> For example, kvm and hugetlbfs together.
> It looks fine to me if we're using MMF_USERFAULTFD_ALLOW fl
On Tue, Mar 12, 2019 at 12:59:34PM -0700, Mike Kravetz wrote:
> On 3/11/19 2:36 AM, Peter Xu wrote:
> >
> > The "kvm" entry is a bit special here only to make sure that existing
> > users like QEMU/KVM won't break by this newly introduced flag. What
> > we need to do is simply set the "unprivileg
On 3/11/19 2:36 AM, Peter Xu wrote:
>
> The "kvm" entry is a bit special here only to make sure that existing
> users like QEMU/KVM won't break by this newly introduced flag. What
> we need to do is simply set the "unprivileged_userfaultfd" flag to
> "kvm" here to automatically grant userfaultfd
Hi, Kirill,
On Tue, Mar 12, 2019 at 10:49:51AM +0300, Kirill A. Shutemov wrote:
> On Mon, Mar 11, 2019 at 05:36:58PM +0800, Peter Xu wrote:
> > Hi,
> >
> > (The idea comes from Andrea, and following discussions with Mike and
> > other people)
> >
> > This patchset introduces a new sysctl flag t
On Tue, Mar 12, 2019 at 09:01:47AM +0200, Mike Rapoport wrote:
> Hi Peter,
>
> On Mon, Mar 11, 2019 at 05:36:58PM +0800, Peter Xu wrote:
> > Hi,
> >
> > (The idea comes from Andrea, and following discussions with Mike and
> > other people)
> >
> > This patchset introduces a new sysctl flag to a
On Mon, Mar 11, 2019 at 05:36:58PM +0800, Peter Xu wrote:
> Hi,
>
> (The idea comes from Andrea, and following discussions with Mike and
> other people)
>
> This patchset introduces a new sysctl flag to allow the admin to
> forbid users from using userfaultfd:
>
> $ cat /proc/sys/vm/unprivile
Hi Peter,
On Mon, Mar 11, 2019 at 05:36:58PM +0800, Peter Xu wrote:
> Hi,
>
> (The idea comes from Andrea, and following discussions with Mike and
> other people)
>
> This patchset introduces a new sysctl flag to allow the admin to
> forbid users from using userfaultfd:
>
> $ cat /proc/sys/v
Hi,
(The idea comes from Andrea, and following discussions with Mike and
other people)
This patchset introduces a new sysctl flag to allow the admin to
forbid users from using userfaultfd:
$ cat /proc/sys/vm/unprivileged_userfaultfd
[disabled] enabled kvm
- When set to "disabled", all un
21 matches
Mail list logo
