On Tue, 18 Aug 2020, 18:28:16 +0200, Larry Finger wrote:
On 8/18/20 7:17 AM, Manfred Hollstein wrote:
to be honest, this is a perfect example where Oracle failed to keep
track with recent kernel development! As we had seen it before, probably
just not as extreme as we see it now, I thought it might be time to
migrate all my virtual machines from VB to KVM...
Guess what, I did not have trouble with any of them, which include Win 7
32bit, Win 10 64bit and various Linux VMs. One thing which really
surprised me was, how well usage of USB devices works these days. I could
even use a webcam inside a KVM VM which only very barely worked in VB.
FWIW, I may have been lucky, but I certainly don't need VB anymore!
If you look at https://bugzilla.opensuse.org/show_bug.cgi?id=1175201
will note that conversion to KVM is my second suggested work around, right
after staying with kernel 5.7.
yes, absolutely! I always appreciated your work (and applied your
patches to my local systems), but...
The fundamental reason for this situation is that the kernel developers in
charge of memory management have the goal of restricting the acquisition of
memory that can can execute code. When code external to the kernel can
acquire this feature, a huge security hole exists. Through the past 4 or 5
kernel releases such memory acquisition has been tightened and VirtualBox
has undergone several changes to adapt; however, with kernel 5.8, there is
... here's the point. I cannot see why/how Oracle/VB developers got
involved to find a solution for this issue - and, I completely agree
correction: I cannot see how they got involved or responded at all! This
was my main intention to bring over...
with the kernel developers in this respect and how
Please note that I proposed a 2-line patch to our
kernel developers to
handle our situation until Oracle found a proper solution, but that request
was denied. Oracle was also given advance notice.
Apparently Oracle does have a solution, but it
has not worked for me.
Perhaps it will in work with VB 6.1.14, but I expect such a solution to be a
temporary fix as it still requires the security hole.
Exactly. FWIW, I find it unacceptable to a wait for such a long period,
assuming VM users will wait that long, even knowing it's not a *real*
The real solution will
be to incorporate libvirt the way that QEMU/KVM does, but that
implementation is beyond my abilities.
And again, yes, this is the way forward from my point of view, and it's
absolutely not against your work - it's just a good chance now to decide if
Oracle is a real good open source citizen, or not.
This issue has been a full-time sink for me for
nearly 2 months.
Unfortunately, I was not able to supply a seamless solution!
Again, thanks a lot for your work!