Xen project Mailing List

I think this blog would benefit from a bigger picture / simplified explanation on how this will improve the security of Xen, which is a hot topic for many reporters.

Maybe pull out some of the main points/conclusions raised in "Zero-Footprint Guest Memory Introspection from Xen - Mihai Dontu, Bitdefender and Ravi Sahita, Intel" instead of just linking to the PPT.Â

Touch on security threats we face today, how/why advanced attacks evade traditional security solutions, summary of memory introspection (its benefits), where Xen is today with hardware enforced isolation providing Xen with much improved security, what 4.6 will deliver.Â

With more context, I think I'd be able to pitch this to a few of the reporters who are following Xen's every security move.Â

Also, is this the biggest security hook we'll have for 4.6? Hoping it's not so that there will be plenty of other security updates to discuss when we issue that news in the fall.Â

On Thu, Jul 30, 2015 at 1:59 PM, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>
> On 07/30/2015 07:45 PM, Lars Kurth wrote:
> > I am wondering whether some of what Tamas raised can be made clearer
>
> I've updated the article. The "in order to work properly, LibVMI
> requires that you install a configuration file into either
> $HOME/etc/libvmi.conf or /etc/libvmi.conf, with a set of entries for
> each virtual machine or memory image that LibVMI will access" part is
> taken almost verbatim from the LibVMI website (linked in the article),
> so hopefully it's no longer controversial.
>
> I've explicitly stated the way in which Glib is an (indirect) dependency
> for LibVMI client applications.
>
> I've qualified the statement that LibVMI doesn't offer a way to directly
> map guest pages to mean that it doesn't offer any public way to do so
> (i.e. via libvmi.h), and also gave Driver::mapVirtMemToHost() as an
> example of how even what LibVMI does offer in the Xen driver source code
> differs from the goals of our code.
>
> I've removed the "smaller and more up-to-date" comparison, because while
> technically the comparison is correct, it also compares libraries with
> different aims, so that's somewhat of an apples-to-oranges comparison
> and I can see how it might be seen as such.
>
> I've also remembered that LibVMI doesn't offer a way to inject page
> faults, and emphasized that performance is a key factor with Libbdvmi.
>
> As for intergrating the changes into LibVMI, that's certainly something
> we'd like to see happen. The point has really never been to create an
> alternative to LibVMI, but simply to move forward as efficiently as
> possible with our project, and to eventually have a solid base for
> discussion and sharing code and ideas with LibVMI and anyone else
> interested. We would actually be quite happy to be able to use the
> libbdvmi interfaces simply as wrappers over LibVMI.
>
>
> Thanks,
> Razvan
>
> _______________________________________________
> Publicity mailing list
> Publicity@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity

--
Sarah Conway
PR Manager
The Linux Foundation
sconway@xxxxxxxxxxxxxxxxxxx
(978) 578-5300 ÂCell
Skype: Âsarah.k.conway

Re: [Publicity] [Xen-devel] The Bitdefender virtual machine introspection library is now on GitHub