On Sat, Dec 21, 2024 at 3:44 PM Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > > On Fri, 20 Dec 2024 at 10:56, Timos Ampelikiotis > <t.ampelikiotis@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Wed, Dec 4, 2024 at 7:18 PM Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > >> > >> On Wed, 4 Dec 2024 at 10:38, <t.ampelikiotis@xxxxxxxxxxxxxxxxxxxxxx> wrote: > >> > > >> > From: Timos Ampelikiotis <t.ampelikiotis@xxxxxxxxxxxxxxxxxxxxxx> > >> > > >> > This commit, is based on virtio MMIO driver, adds support > >> > for dynamic allocated (platform) virtio devices. This > >> > allows applications running in native environments to use > >> > virtio drivers as a HAL and eventually communicate with > >> > user-space drivers (implementing the vhost-user protocol). [...] > > The current implementation of the driver collaborates with our > > user-space counterpart (adapter application) in order to establish > > the control plane with the vhost-user device, and indeed there is > > partially a trust relationship. > > > > Currently we are working on updating the API between driver and the > > user-space counterpart in order to make the driver more robust > > and make sure that leaks like this do not happen. > > Okay. Please take kernel lockdown into account: > https://www.man7.org/linux/man-pages/man7/kernel_lockdown.7.html > > Userspace must not be able to modify arbitrary kernel memory or load > code. Even root cannot do this except for limited mechanisms like > loading signed kernel modules. Thanks, I fully agree! I have implemented a new version of virtio-loopback in which I am adapting the bouncing buffer logic from vDUSE which I believe it covers partially what you suggested.
