[HOME] [DOWNLOAD] [DOCS] [BLOG] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Recurring Time Error within Gateway 11 under VirtualBox 5 - ERROR: Unwanted PVClock kvm-clock tsc acpi_pm detected!


#1

This time-based error within a fully updated Gateway 11 running under VBox 5. This error causes whonixcheck to fail, and continues to drive me nuts!

Facts:

My 64-Bit VBox 5 Host is/always has been set to UTC.

Running ‘date’ in a fully updated Gateway, correctly shows:

Tue Nov 24 07:49:03 UTC 2015

Yet following every Gateway boot, I see this error DESPITE the Gateway’s Tor working correctly:

ERROR: PVClock Test Result:
Unwanted PVClock kvm-clock tsc acpi_pm detected! This is unsupported by Whonix developers! Whonixcheck aborted!
Using PVClock together with Whonix is recommended against, because PVClock conflicts with Whonix’s TimeSync design [1].
You probably did not follow Whonix’s KVM instructions. [2]
This might endanger your anonymity. Do not proceed unless you know what you are doing.
If you wish to ignore this warning and to continue whonixcheck anyway, you can set
WHONIXCHECK_NO_EXIT_ON_PVCLOCK_DETECTION="1"
in /etc/whonix.d/30_whonixcheck_default.
Recommended action:

Do I need to mention again this is a Gateway 11 error when run under VirtualBox 5, and is UNRELATED to KVM?

Also note that I run many different OSes under VBox 5, and I have never seen another time-based error with any other VBox Guest OS.

You should also be aware, this error does NOT occur immediately following a clean install/reinstall of the Gateway-11.ova file.

The error occurs, and then persists, only following several apt-get updates. Therefore, the solution to this bug, imo, lies in figuring out what changed to impact the time/clocks, and why, during those updates.

Setting and using time should be drop dead simple in linux. What was the original time goal, and why does it appear to have become so complex? Why all the pain/PITA with Whonix’s version of time?

What in the world are you actually delivering in terms of safety by using these flawed time checks? Time is time, all users should be using UTC, period.

Let me know,

CCP

+++++++++++++++++++++++++++++++++++

Is /usr/lib/whonixcheck/check_pvclock the script that is driving the error?

Here is the current content of that script.

$ cat /usr/lib/whonixcheck/check_pvclock
#!/bin/bash

This file is part of Whonix.

Copyright © 2012 - 2014 Patrick Schleizer adrelanos@riseup.net

See the file COPYING for copying conditions.

pvclock_unwanted_detected() {
if [ “$WHONIXCHECK_NO_EXIT_ON_PVCLOCK_DETECTION” = “1” ]; then
local MSG="

PVClock Test Result: Unwanted PVClock detected, but WHONIXCHECK_NO_EXIT_ON_PVCLOCK_DETECTION is set, continuing.

"
if [ “$verbose” -ge “1” ]; then
$output_x ${output_opts[@]} --messagex --typex “info” --message “$MSG”
$output_cli ${output_opts[@]} --messagecli --typecli “info” --message "$MSG"
fi
return 0
fi

local MSG="

PVClock Test Result:


Unwanted PVClock $available_clocksource detected! This is unsupported by Whonix developers! Whonixcheck aborted!

Using PVClock together with Whonix is recommended against, because PVClock conflicts with Whonix's TimeSync design [1].

You probably did not follow Whonix's KVM instructions. [2]

This might endanger your anonymity. Do not proceed unless you know what you are doing.

If you wish to ignore this warning and to continue whonixcheck anyway, you can set

WHONIXCHECK_NO_EXIT_ON_PVCLOCK_DETECTION=\"1\"
in /etc/whonix.d/30_whonixcheck_default.

Recommended action:
- Shut down.
- Read Whonix documentation. [3]
- Follow Whonix's KVM instructions. [2]
- Or use Whonix a supported virtualizer.
- Or use Whonix with Physical Isolation. [4]

[1] https://www.whonix.org/wiki/Dev/TimeSync
[2] https://www.whonix.org/wiki/KVM
[3] https://www.whonix.org
[4] https://www.whonix.org/wiki/Physical_Isolation

"

$output_x ${output_opts[@]} --messagex --typex “error” --message “$MSG”
$output_cli ${output_opts[@]} --messagecli --typecli “error” --message "$MSG"
EXIT_CODE="1"
cleanup "1"
return 0
}

check_pvclock() {
if [ -f “/var/run/qubes-whonix/qubes.SetDateTime” ]; then
qubes_set_date_time_content="$(cat “/var/run/qubes-whonix/qubes.SetDateTime”)" || true
local MSG="


PVClock Result: dom0 is telling us the time.
File /var/run/qubes-whonix/qubes.SetDateTime exists.
Its content is $qubes_set_date_time_content.
This is non-ideal. A known issue. Contributions happily considered. Read more: https://phabricator.whonix.org/T397

"
if [ “$verbose” -ge “1” ]; then
$output_x ${output_opts[@]} --messagex --typex “info” --message “$MSG”
$output_cli ${output_opts[@]} --messagecli --typecli “info” --message "$MSG"
fi
fi

if [ ! -f “/sys/devices/system/clocksource/clocksource0/current_clocksource” ]; then
local MSG="

PVClock Result: /sys/devices/system/clocksource/clocksource0/current_clocksource does not exist, ok.

"
if [ “$verbose” -ge “1” ]; then
$output_x ${output_opts[@]} --messagex --typex “info” --message “$MSG”
$output_cli ${output_opts[@]} --messagecli --typecli “info” --message "$MSG"
fi
return 0
fi

local current_clocksource available_clocksource
current_clocksource="$(cat “/sys/devices/system/clocksource/clocksource0/current_clocksource”)" || true
available_clocksource="$(cat “/sys/devices/system/clocksource/clocksource0/available_clocksource”)" || true

if [ “$current_clocksource” = “xen” ]; then
local MSG="

PVClock Result: /sys/devices/system/clocksource/clocksource0/current_clocksource exist, is $current_clocksource.
This is non-ideal. A known issue. Contributions happily considered. Read more: https://phabricator.whonix.org/T389

"
if [ “$verbose” -ge “1” ]; then
$output_x ${output_opts[@]} --messagex --typex “info” --message “$MSG”
$output_cli ${output_opts[@]} --messagecli --typecli “info” --message "$MSG"
fi
return 0
fi

if [ “$current_clocksource” = “kvm-clock” ]; then
pvclock_unwanted_detected
return 0
fi

local MSG="

PVClock Result: /sys/devices/system/clocksource/clocksource0/current_clocksource exist, is $current_clocksource.

"
if [ “$verbose” -ge “1” ]; then
$output_x ${output_opts[@]} --messagex --typex “info” --message “$MSG”
$output_cli ${output_opts[@]} --messagecli --typecli “info” --message "$MSG"
fi
return 0
}

Whonix 12 testers repository - Notes
#2

That error doesn’t directly break Tor. It derivatives from the recommend/expected virtualizer configuration.

This is unrelated to UTC. It is about the pvclock setting. If you want more background on it, search the forum for kvmclock. See also https://www.whonix.org/wiki/Dev/KVM#How_to_disable_KVMClock.3F. It allows an attack similar to the one described here https://www.whonix.org/wiki/Dev/TimeSync#Clock_Correlation_Attack.

Did you change any settings in VirtualBox? The paravirtualization providers? Don’t.

This is unsupported, discouraged.
( [unsupported] VirtualBox now supports KVM and Hyper-V as paravirtualization providers )

Whonix 11 didn’t get any updates related to that recently. Did you update from the testers repository?


#3

Hi Patrick,

Thanks for your follow-up.

Yes, I always get my updates from the Testers repo.

On Gateway 11 - under System, Acceleration, Paravirtualization interface = Default.

Note, I also have both of these options ENABLED:

Enable VT-x/AMD-v
Enable Nested Paging

I also have 1 CPU allocated with PAE/NX ENABLED

Patrick, also note that even though Paravirtualization interface = Default, the main VBox GUI still reports: KVM Paravirtualization for the Gateway, as it also shows for every linux OS VBox Guest on my system. Are you suggesting changing the setting from Default to None?

Let me know if you can already see the settings choices that are causing this error.

Thanks,

CCP


#4

Are we still using these two time related options for the default build? I found them at:

https://github.com/Whonix/Whonix/blob/master/build-steps.d/2600_create-vbox-vm

  1. sudo -u “$user_name” VBoxManage modifyvm “$VMNAME” --rtcuseutc on
  2. sudo -u “$user_name” VBoxManage setextradata “$VMNAME” “VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled” “1”

Neither of the explanations accompanying either option makes either option seem necessary if the host is already set to UTC.

As for the VBox Gateway, under System, Motherboard, users can/should have ‘Hardware Clock in UTC Time’ Checked/Enabled - and also for any other OSes they run where revealing timezones can potentially harm them.


#5

Corrupt_Correct_Pig:

Are you suggesting changing the setting from Default to None?

No.


#6

Corrupt_Correct_Pig:

Are we still using these two time related options for the default build? I found them at:

https://github.com/Whonix/Whonix/blob/master/build-steps.d/2600_create-vbox-vm

  1. sudo -u “$user_name” VBoxManage modifyvm “$VMNAME” --rtcuseutc on
  2. sudo -u “$user_name” VBoxManage setextradata “$VMNAME” “VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled” “1”

Still in use. But those are unrelated here. This is not about UTC at
all. This is only related to pvclock.

/sys/devices/system/clocksource/clocksource0/available_clocksource

/sys/devices/system/clocksource/clocksource0/current_clocksource

The stopgap will be a Whonix 12 update to disable this test in VirtualBox.

And if you are wondering about the real fix… The real solution would
be https://phabricator.whonix.org/T437 but unfortunately, it’s very
unlikely to happen. Even fixing this for better supported virtualizers
seems very hard.

Neither of the explanations accompanying either option seems necessary if the host is already set to UTC.

We don’t expect the host to be set to UTC. Also don’t recommend that
anywhere. (Would result in a strange browser fingerprint for
non-torified browsing on the host.) Also would not be great to require
this from users. Luckily UTC here is a non-issue.

As for the VBox Gateway, under System, Motherboard, users can/should have ‘Hardware Clock in UTC Time’ Checked/Enabled - and also for any other OSes they run where revealing timezones can potentially harm them.

This is already advised here:


#7

OK Patrick - I’m learning more about this issue as we progress, and I’m glad you’ll work to resolve it in 12.

And, unsurprisingly, the issue of a real fix had crossed my mind. :triumph:

Your UTC explanations make sense in the larger user context.

If it’s important enough to try to isolate the update/group of updates which are triggering this error, I can start with a clean Gateway 11.ova reinstall and a from known set of initial VBox paramaters, and then start running updates/rebooting after each set, and finding out when/where it breaks.

Let me know if you think this is worth the effort.

CCP


#8

Corrupt_Correct_Pig:

Let me know if you think this is worth the effort.

No. Wait for the updated whonixcheck repository. No more diagnosis required.


#9

Patrick,

Since this whonixcheck ‘error’ does not impact the Gateway’s Tor functionality, it’s not really a significant problem.

I will continue to manually update the Gateway, and wait for a fix.

KUDOS: More generally, you’ve done a great job with Gateway 11! The Gateway runs on my end with excellent stability even with only 128 Mb of allocated DRAM, and even when the Gateway needs to provide an isolated network for several OSes running behind it, concurrently. Furthermore, I see that same Gateway 11 stabilty whether running VBox, or KVM, on my Host.

Just for the record:

From my 64-bit Linux Host:
’# cat /sys/devices/system/clocksource/clocksource0/current_clocksource’
tsc

From the VBoxxed Gateway 11:
’# cat /sys/devices/system/clocksource/clocksource0/current_clocksource’
kvm-clock

Thanks for helping me to understand to what is occuring here Patrick.

CCP


#10

The git commit.


@HulaHoop please consider testing if kvm-clock detection would still work in KVM.

Still have to produce an upgraded package.


#11

Upgrades in testers repository coming soon. (Less than 1 hour expected.)


#12

Hi Patrick,

Thank you. I grabbed the update, and whonixcheck is now working correctly on VBox following boot, despite the now understood to be trivial PVClock ‘error’ continuing to be reported.

I think we are making good progress here.

I’ll wait for HulaHoop’s testing/input on the KVM side of the house.

Concerning the whonixcheck process, has the possibility been discussed of having whonixcheck not merely do an apt-get package update check, but to have whonixcheck directly offer to download and install a listed group of upgradeable packages?

This is not a whonixcheck bug, just a potential feature request. In other words, I don’t just want whonixcheck to scan the repos and tell me 24 packages can be upgraded, leaving me to need to apt-get scan the reops again myself, and then download and install the packages. It seems like a waste of time and resources to scan the repos twice for the exact same information.

I think a better/more efficient solution would include:

  1. whonixcheck scans the repos, identifies, and lists all upgradeable packages.
  2. A time test since the last package update check can be used. If a sufficient amount of time has passed since the previous update check, the repo scan should run at every boot.
  3. whonixcheck asks if the user wants to download and install that group of packages (Y/n) from its scan.

Let me know if this functionality has been considered previously, and if it would be difficult, or unwise, to implement.

Cheers,

CCP


#13

Corrupt_Correct_Pig:

I grabbed the update, and whonixcheck is now working correctly on
VBox
following boot, despite the now understood to be trivial PVClock 'error’
continuing to be reported.

Reported as error or warning?

  • Warning -> better, that’s the update
  • Error -> update did not work

Does whonixcheck still stop?

  • stop -> update did not work
  • continue -> better, but it should not show a warning anymore

Please post the output of the pvclock this check.

What whonixcheck version you have now installed?

dpkg -l | grep whonixcheck

Should be 3:3.8.2-1.

Concerning the whonixcheck process, has the possibility been
discussed of having whonixcheck not merely do an apt-get package
update check, but to have whonixcheck directly offer to download and
install a listed group of upgradeable packages?

Yes. But it’s too difficult to implement this on the Whonix side. It’s a
Debian [and derivatives] issue. More info:

Upgrading with best security there is left a manual process. Documented
here:

I don’t just want whonixcheck to scan the repos

Every check in whonixcheck can be selectively disabled. For disabling
the operating system updates check, see:


#14

Patrick,

Yes - my use of the word ‘error’ was in error. :triumph:

As you can see below, a [WARNING] is generated, and the updates scan is working.

I am running 3:3.8.2-1. The entire run looks like this:

whonixcheck
[INFO] [whonixcheck] Connected to Tor.
[WARNING] [whonixcheck] PVClock Test Result:

Unwanted PVClock kvm-clock tsc acpi_pm detected! Using this PVClock together with Whonix is recommended against, because it conflicts with Whonix’s TimeSync design [1].

If you know what you are doing, feel free to disable this check.
Create a file /etc/whonix.d/50_whonixcheck_user and add:
whonixcheck_skip_functions+=" pvclock_unwanted_detected "

Recommended action:

  • If you are using KVM, you probably did not follow Whonix’s KVM instructions. [2]
  • Or use a different supported Whonix platform. [3]

[1] https://www.whonix.org/wiki/Dev/TimeSync
[2] https://www.whonix.org/wiki/KVM
[3] https://www.whonix.org/wiki/Supported_Platforms
[INFO] [whonixcheck] Whonix is produced independently of, with no guarantee from, The Tor Project. Whonix is experimental software. Do not rely on it for strong anonymity. https://www.whonix.org
[INFO] [whonixcheck] SocksPort Test: Testing Tor’s SocksPort…
[INFO] [whonixcheck] SocksPort Test Result: Connected to Tor. IP: XX.XX.XX.XX
[INFO] [whonixcheck] Whonix News Download: Checking for Whonix news and updates…
[INFO] [whonixcheck] Whonix News Result:
√ Up to date: whonix-gateway-packages-dependencies 2.9-1
√ Up to date: Whonix Build Version: 11.0.0.3.0
[INFO] [whonixcheck] Debian Package Update Check: Checking for software updates via apt-get… ( Documentation: https://www.whonix.org/wiki/Update )
[INFO] [whonixcheck] Debian Package Update Check Result: No updates found via apt-get.
[INFO] [whonixcheck] Whonix APT Repository: Enabled.
When the Whonix team releases TESTERS updates,
they will be AUTOMATICALLY installed (when you run apt-get dist-upgrade)
along with updated packages from the Debian team. Please
read https://www.whonix.org/wiki/Trust to understand the risk.
If you want to change this, use:
sudo whonix_repository

++++++++++++++++++++++++++++++++++++

Thanks for your input on ‘automating’ the update download and installation process from within whonixcheck. I understand.

CCP


#15

You got the upgrade. But that test doesn’t totally work as expected. It
shouldn’t show that.

Could you please post the output of the following two commands?

sudo virt-what

sudo systemd-detect-virt


#16

Patrick,

I’m running KVM atm, so I’ll need to reboot a couple of things to return to VBox.

However, while I here, on an updated Gateway 11 running under KVM, please note this output of whonixcheck, most notably the absence of the PVClock [WARNING].

whonixcheck
[INFO] [whonixcheck] Connected to Tor.
[INFO] [whonixcheck] Whonix is produced independently of, with no guarantee from, The Tor Project. Whonix is experimental software. Do not rely on it for strong anonymity. https://www.whonix.org
[INFO] [whonixcheck] SocksPort Test: Testing Tor’s SocksPort…
[INFO] [whonixcheck] SocksPort Test Result: Connected to Tor. IP: xx.xx.xx.xx
[INFO] [whonixcheck] Whonix News Download: Checking for Whonix news and updates…
[INFO] [whonixcheck] Whonix News Result:
√ Up to date: whonix-gateway-packages-dependencies 2.9-1
√ Up to date: Whonix Build Version: 11.0.0.3.0
[INFO] [whonixcheck] Debian Package Update Check: Checking for software updates via apt-get… ( Documentation: https://www.whonix.org/wiki/Update )
[INFO] [whonixcheck] Debian Package Update Check Result: No updates found via apt-get.
[INFO] [whonixcheck] Whonix APT Repository: Enabled.
When the Whonix team releases TESTERS updates,
they will be AUTOMATICALLY installed (when you run apt-get dist-upgrade)
along with updated packages from the Debian team. Please
read https://www.whonix.org/wiki/Trust to understand the risk.
If you want to change this, use:
sudo whonix_repository

Also, while I’m running KVM, here is the Gateway 11 output you requested:

sudo virt-what
kvm

sudo systemd-detect-virt
kvm

I’ll post the Gateway output from within VBox in a few minutes.

CCP


#17

Patrick,

This is the Gateway output while it is running under VBox:

sudo virt-what
virtualbox
kvm

sudo systemd-detect-virt
kvm

As I mentioned earlier, Acceleration is set to Default for my Gateway in VBox.

CCP


#18

The user support answer would be:
Good enough for now. Might be fixed in Whonix 13. Don’t hold your breath for it.


Since you seem to be interested in the technical backgrounds, this will be the development discussion answer:
I keep it in the same topic, since otherwise this does not get attention anyhow, and I wouldn’t know who else would look into Whonix VirtualBox development.

Your Whonix KVM [real KVM on LInux, I suppose] results seems fine.

The terminology now gets difficult since VirtualBox 5 now also supports KVM as paravirtualization provider. ( [unsupported] VirtualBox now supports KVM and Hyper-V as paravirtualization providers)

Your Whonix VirtualBox results are not ideal development wise yet. The problem now is, that systemd-detect-virt detects kvm, even though you are running in VirtualBox.

I am wondering why you are the only one reporting this. Did you change System, Acceleration, Paravirtualization interface?

FYI, it’s related to:

If you set it to Paravirtualization interface to legacy, that whonixcheck error should varnish. Also the output of cat /sys/devices/system/clocksource/clocksource0/available_clocksource should change then.

I wonder what the optimal paravirtualization for Whonix 13 will be.

  • default is problematic, since as in your case, it does autodetection, then used VirtualBox KVM

  • none explicitly turns off exposing any paravirtualization interface sounds good security wise but could be really slow. Please test and leave feedback.

  • minimal sounds like a worthwhile alternative if none is too slow. But what technology is minimal actually using? VirtualBox legacy or kvm? However, documentation says, it lets the VM read the APIC frequency. To be researched how bad this would be.

  • legacy is good enough for now. That’s like VirtualBox 4.x. But since they now call it legacy, that code will rot, and probably should be avoided in long run.

  • kvm (VirtualBox) is problematic, since it provides unwanted pvclock kvm-clock. (Which allows a clock correlation attacks once VM is compromised.

  • Does not seem like pvclocks can be configured in VirtualBox. (With linux libvirt kvm it’s possible.)

  • https://www.whonix.org/wiki/Dev/TimeSync#Clock_Correlation_Attack

  • However, this presupposes that users did read and apply https://www.whonix.org/wiki/Advanced_Security_Guide#Spoof_the_Initial_Virtual_Hardware_Clock_Offset beforehand, which probably few do.

  • Therefore probably not a big issues.

  • hyperv The microsoft thingy. No idea about that one. May or may not be great for Linux guests (Whonix).

Each virtualization platform should be reviewed for performance, security, pvclock interfaces and hardware identifiers readable by the vm ( https://www.whonix.org/wiki/Protocol-Leak-Protection_and_Fingerprinting-Protection ).

Not sure you noticed the new Download table yet:


The point is, it introduces a security column. For your information:


#19

Hi Patrick,

Yes - I’ve got Gateway 12 updated and running. I can confirm the entire PVClock issue on VBox stems from the paravirtualization choice. I knew this before I even saw your latest, because I noticed you had Legacy selected as the default VBox Acceleration on 12.

I ran whonixcheck both ways: Legacy and Default.

With Legacy, no PVClock [WARNING] and apt-get scan completes.

With Default, the PVClock [WARNING] is present and apt-get scan completes.

And yes, it does appear that VBox ‘auto-selects’ KVM paravirtualization for Linux Guests running on Linux Hosts when Acceleration = Default is selected.

I think we’ve beaten this issue to death, but at least we understand what is driving it. It certainly is not an issue worth losing sleep over, as the Gateway continues to operate correctly in either acceleration mode.

Thanks for all your support Patrick,

CCP - an almost normally-adjusted, non-breath-holder :triumph:


#20

The remaining question is, which setting the best VirtualBox paravirtualization setting for Whonix is.