After running a bunch of tcp ping tests, the conclusion is this attack
is not really effective against TCP like ICMP. The latency is much lower
for TCP pings and though it slightly decreases with cpu stress it is not
consistent. Reloading pages in TBB with cpu stress
on/off does not impact latency readings while doing so with tc
attached has massive latency foot prints - implying it will ironically make such attacks much easier in addition to degrading performance.

Cyrus recommends adding delays per packet to disrupt inter-packet patterns that remain. The command can be fine tuned as such:

The good news is I think I've figured out the equivalent tc-netem command looking the slot parameter in the manual:

Ticket above closed and convo moved to tails-dev.

We actually ended up using Whonix KVM and placing images to:

We should be able to create a drop-in file at /lib/systemd/system/user-.slice.d/ and add something such as

cgroups were mentioned by @madaidan

https://redmine.tails.boum.org/code/issues/17156

Analysis by Cyrus cited here for completion:

Reported build failures:

When an implementation is decided, let's decide if we can include this in security-misc for use on Linux hosts and Kicksecure. We would need some way in detecting the active NIC since on wireless systems wlan0 is the interface of choice and not eth0

tc-netem is a utility that is part of the iproute2 package in Debian. It leverages functionality already built into Linux and userspace utilities to simulate networks including packet delays and loss.

Accepted as optional feature/usecase. Moved implementation design from protocol level to spice-gtk.

HulaHoop (HulaHoop):

HulaHoop added a comment.

https://gitlab.freedesktop.org/spice/spice-protocol/issues/8

https://gitlab.freedesktop.org/spice/spice-protocol/issues/8

In T720#18410, @HulaHoop wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=1320263#c5

Issue was discussed by Libvirt devs on RedHat bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1320263#c4
I even linked to a secure clipboard proposal that would have given a secure clipboard functionality by copying Qubes style interaction. It went no where and was closed as WONTFIX.

Awesome!

yes it working

Does this work? @TNTBOMBOM

https://github.com/Whonix/whonix-developer-meta-files/commit/2a0064f4214e04a0f454fd1b29fe9f14c6629d2e

There's been research showing that trying to hide CPU information in a virtualizer is futile.

This will be undone. Ticket:

• https://github.com/Whonix/vbox-disable-timesync/commit/c9c36ebda2134d16cdaa18a3bd20b95978d3f8b6
• https://github.com/Whonix/vbox-disable-timesync/commit/f669dbc265e246c1a4df0f6c9d6a4e898f6dbcc0

Regarding the spectre vulnerability and its effect on VirtualBox your input is desired. @dumbmouse

"Hiding CPU model is futile." Any reference for that? @HulaHoop

virt-sparsify solution dropped because needs booting the image with qemu-system (not clean, to much unknown consequences, see attached ouptut).

https://github.com/Whonix/Whonix/pull/415

NB for the record: with qemu-ga a guest can still shut itself off via crafted input to the agent. So besides removing timer access to the guest, there was no other advantage to removing ACPI.

Actually we don't have to suspend the guest. Execution of any command on the host after resume is enough to create a uniqu event in the qemu-ga's log file.

The proper and direct way to use virsh to communicate with guest agent:

The YAJL parser used in libvirt is tiny, modern (written in2007) and has no CVEs. It is an SAX type event-driven parser unlike the vulnerable, top-down recursive descent type that was used in QEMU.

https://wiki.libvirt.org/page/Qemu_guest_agent

It turns out the QEMU guest agent warning was not relevant to those who use libvirt. With libvirt a safe parser is used. Breakouts can only happen if a process on the host is designed to parse guest input because there is no way to control that otherwise it should be safe for our uses. This potentially simplifies the design in many respects but a host package will still be needed. I will update the task list.

https://www.redhat.com/archives/libvirt-users/2018-February/msg00083.html
[libvirt-users] QEMU guest-agent safety in hostile VM?

Yes there are less moving parts especially when multiple WSs share a GW. Some way to exempt timesync traffic from the WS would be needed though.

HulaHoop (HulaHoop):

HulaHoop added a comment.

With qemu-ga code the whole clock drift detection code becomes redundant. If a
suspend event is triggered the GW should assume clocks are out of sync and
trigger lockdown.

With qemu-ga code the hwclock drift detection code becomes redundant. If a suspend event is triggered the GW should assume clocks are out of sync and trigger lockdown.

Oops didn't realize ntpdate requires query of remote servers. ntpdate is obsolete anyhow but the newer clockdiff still talks to online servers instead of comparing local values. hwclock can give us that:

It's a very good rehash!

@Patrick I wrote a rehash. If you think is too complicated, let me know. It was the simplest and most reliable way I could think of:

Didn't rehash. What's next here? Looks like we learned a lot, but then things stalled. Could you please rehash, and then create a follow-up ticket with the way forward? @HulaHoop

Added. Not yet tested by me but will test in the next build.

Works for me, hid my cpu name

Here is a more limited version, but better for general distribution:

Alright, great!

Actually I need to test this more. I will fine tune it and add another comment here in couple of days.