linux-kernel - Re: [PATCH] KVM: Unlimit number of ioeventfd assignments for real

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20191126222721.GB14153@xz-x1>
Date:   Tue, 26 Nov 2019 17:27:21 -0500
From:   Peter Xu <peterx@...hat.com>
To:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [PATCH] KVM: Unlimit number of ioeventfd assignments for real

On Sat, Sep 28, 2019 at 09:40:45AM +0800, Peter Xu wrote:
> Previously we've tried to unlimit ioeventfd creation (6ea34c9b78c1,
> "kvm: exclude ioeventfd from counting kvm_io_range limit",
> 2013-06-04), because that can be easily done by fd limitations and
> otherwise it can easily reach the current maximum of 1000 iodevices.
> Meanwhile, we still use the counter to limit the maximum allowed kvm
> io devices to be created besides ioeventfd.
> 
> 6ea34c9b78c1 achieved that in most cases, however it'll still fali the
> ioeventfd creation when non-ioeventfd io devices overflows to 1000.
> Then the next ioeventfd creation will fail while logically it should
> be the next non-ioeventfd iodevice creation to fail.
> 
> That's not really a big problem at all because when it happens it
> probably means something has leaked in userspace (or even malicious
> program) so it's a bug to fix there.  However the error message like
> "ioeventfd creation failed" with an -ENOSPACE is really confusing and
> may let people think about the fact that it's the ioeventfd that is
> leaked (while in most cases it's not!).
> 
> Let's use this patch to unlimit the creation of ioeventfd for real
> this time, assuming this is also a bugfix of 6ea34c9b78c1.  To me more
> importantly, when with a bug in userspace this patch can probably give
> us another more meaningful failure on what has overflowed/leaked
> rather than "ioeventfd creation failure: -ENOSPC".
> 
> CC: Dr. David Alan Gilbert <dgilbert@...hat.com>
> Signed-off-by: Peter Xu <peterx@...hat.com>

Ping - just in case it fell through the cracks.

-- 
Peter Xu