Sjur Brændeland <sjurbren@xxxxxxxxx> writes: > On Fri, Dec 21, 2012 at 7:11 AM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote: >> "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: >> >>> On Wed, Dec 05, 2012 at 03:36:58PM +0100, Sjur Brændeland wrote: >>>> Feedback on this patch-set is appreciated, particularly on structure >>>> and code-reuse between vhost.c and the host-side virtio-queue. >>>> I'd also like some suggestions on how to handle the build configuration >>>> better - currently there are some unnecessary build dependencies. >>> >>> Rusty seems to disagree but one of the concerns people have about vhost >>> is security; so I value getting as much static checking as we can. This >>> discards __user annotations so this doesn't work for me. >> >> Sometimes, when we generalize code, we lose some type safety. Callbacks >> take void *, for example. And it happens *all the time* with const. We >> don't create a set of parallel const-safe routines. >> >> Extracting common code where it can be shared provides better, not worse >> security, because more people will read it. I've never audited the >> vhost code, for example. >> >> We already have a 'struct vring', we should just use that. >> >> I meant to do more work on this, but I've run out of time :( I was >> thinking of a drivers/virtio/virtio_ring.c, and in that we'd put the >> wrappers for vhost_net/blk, and for CAIF, etc. We could at least have a >> variant which did the __user etc thing, even if you have to pass in >> getdesc(). >> >> getu16: get_user or assignment. >> getdesc: copy (and check, translate) the descriptor. >> getmem/putmem: memcpy or copy_to/from_user. >> >> (Completely untested, of course...) >> >> Thoughts? > > Any thoughts on this Michael? I'm actually testing code this time, and it's mutated a little. It basically involves moving much of vring.c into a virtio_host.c: the parts which actually touch the ring. Then it provides accessors for vring.c to use which are __user-safe (all casts are inside virtio_host.c). I should have something to post by end of today, my time... Thanks, Rusty. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
