libvirt users - May 2018 - Virtio-net drivers immune to Nethammer?

Hi I'm a privacy distro maintainer investigating the implications of the
newly published nethammer attack [0] on KVM guests particularly the
virtio-net drivers. The summary of the paper is that rowhammer can be
remotely triggered by feeding susceptible* network driver crafted
traffic. This attack can do all kinds of nasty things such as modifying
SSL certs on the victim system.

* Susceptible drivers are those relying on Intel CAT, uncached memory or
the clflush instruction.

My question is, do virtio-net drivers do any of these things?

***

[0] https://arxiv.org/abs/1805.04956

On Sat, May 19, 2018 at 12:42:14AM +0000, procmem wrote:
> Hi I'm a privacy distro maintainer investigating the implications of
the
> newly published nethammer attack [0] on KVM guests particularly the
> virtio-net drivers. The summary of the paper is that rowhammer can be
> remotely triggered by feeding susceptible* network driver crafted
> traffic. This attack can do all kinds of nasty things such as modifying
> SSL certs on the victim system.
> 
> * Susceptible drivers are those relying on Intel CAT, uncached memory or
> the clflush instruction.
> 
> My question is, do virtio-net drivers do any of these things?
This question is probably better directed at either linux net maintainers
list, or the qemu developers list, since that's where the virtio-net
experts will be.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Daniel P. Berrangé:
> On Sat, May 19, 2018 at 12:42:14AM +0000, procmem wrote:
>> Hi I'm a privacy distro maintainer investigating the implications
of the
>> newly published nethammer attack [0] on KVM guests particularly the
>> virtio-net drivers. The summary of the paper is that rowhammer can be
>> remotely triggered by feeding susceptible* network driver crafted
>> traffic. This attack can do all kinds of nasty things such as modifying
>> SSL certs on the victim system.
>>
>> * Susceptible drivers are those relying on Intel CAT, uncached memory
or
>> the clflush instruction.
>>
>> My question is, do virtio-net drivers do any of these things?
> 
> This question is probably better directed at either linux net maintainers
> list, or the qemu developers list, since that's where the virtio-net
> experts will be.
> 
> Regards,
> Daniel
> 
OK I will thanks.

Hi. What are the security implications for the host when using direct
kernel boot for guests that are potentially malicious? Is guest
filesystem data saved to an emulated drive or directly on the host? [0]
Direct boot seems like an otherwise more efficient way to do things.

[0] It was discovered that tenants using cloud infrastructure that used
LVM were able to recover deleted sensitive data from others however
emulated drives control the data available to the guest at a very low
level and consequently don't suffer from this huge disadvantage.

Hello. I'm interested in running guests as read-only to turn them into a
sort of virtualized "live=cd". The goal is to leave no forensic
evidence
on the host disk or virtual one which would lead to traces on the host
still- similar to how TAILS works but with the added convenince and
flexibility of running in a VM. If I set the qcow image to read-only as
per the manual, will any changes made during a session be written to
disk (or a transient file on disk)?

On Sun, Jun 24, 2018 at 21:19:06 +0000, procmem wrote:
> Hi. What are the security implications for the host when using direct
> kernel boot for guests that are potentially malicious? Is guest
The same as for any VM. The only factor may be how the kernel for the
guest is obtained. If the kernel and initrd are present on the host it's
as every other VM.

Obviously if you try to get the kernel/initrd from the guest/VM image
there are security implications e.g. by mounting the image on the host.
> filesystem data saved to an emulated drive or directly on the host? [0]
This depends solely on the configuration of the <disk> so anything
related to that applies.
> Direct boot seems like an otherwise more efficient way to do things.
> 
> [0] It was discovered that tenants using cloud infrastructure that used
> LVM were able to recover deleted sensitive data from others however
> emulated drives control the data available to the guest at a very low
> level and consequently don't suffer from this huge disadvantage.
Using a qcow2 image as a file can avoid this. Just set your disks
correctly.
> 
> _______________________________________________
> libvirt-users mailing list
> libvirt-users@redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users