So last night i built a new machine for @ home. And I learned a few things I thought i would share.

First, there is a motherboard form-factor called EE-ATX. That first E matters. Its huge. I bought the biggest case (Thermaltake X9, about the size of a bar-fridge) on the theory that this should be simple to install the Supermicro X10DRi-LN4+ motherboard. It was not, I had to take a hack-saw to the case, and then drill and tap for the the #6-32 standoffs all the holes. Ugh. But, finished (or is it? read on!) work below.

OK, that done, installed both processors (2699 v3, 2696 v3) and the 8 x 32GB DDR4 ram. Should be done now right? Just leave it run some stress test over night to check temperatures etc.

OK, that was good. Now a quick Ubuntu 16.04 install and we should have more home VM horsepower (72 threads, 256GB ram, should be a good test bench).

Hmm. When it boots it gives this mystery message about CPU consistency. Huh, that’s weird. I’ve checked a bunch of times, the 2696 and 2699 are the same processor (one is the OEM tray SKU, one is the single-package retail SKU). They have the same stepping ID, same # cores, cache, frequency all is good. And it does work, just not w/ kvm-intel.ko (boo, its the whole purpose of having this).

OK, so use the source. Dig a bit, add some debugging to the kernel, and lo and behold one of them (the 2696) has an extended vmcs flag (tsc scaling). TSC scaling is designed so that you can hot-migrate a VM from one physical machine to another, where the 2nd one has a different clock rate. I don’t need that.

So, I introduce this:

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 5382b82..5ace575 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -103,6 +103,9 @@ module_param_named(enable_shadow_vmcs, enable_shadow_vmcs, bool, S_IRUGO);
 static bool __read_mostly nested = 0;
 module_param(nested, bool, S_IRUGO);
 
+static bool __read_mostly enable_tsc_scaling = true;
+module_param(enable_tsc_scaling, bool, S_IRUGO);
+
 static u64 __read_mostly host_xss;
 
 static bool __read_mostly enable_pml = 1;
@@ -3449,6 +3452,8 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf)
 vmcs_conf->pin_based_exec_ctrl = _pin_based_exec_control;
 vmcs_conf->cpu_based_exec_ctrl = _cpu_based_exec_control;
 vmcs_conf->cpu_based_2nd_exec_ctrl = _cpu_based_2nd_exec_control;
+ if (!enable_tsc_scaling)
+ vmcs_conf->cpu_based_2nd_exec_ctrl &= ~SECONDARY_EXEC_TSC_SCALING;
 vmcs_conf->vmexit_ctrl = _vmexit_control;
 vmcs_conf->vmentry_ctrl = _vmentry_control;

And boom, we are solved.  Just change the command line to:

GRUB_CMDLINE_LINUX="nomodeset kvm-intel.nested=1 kvm-intel.enable_tsc_scaling=0"

and I’m good to go.

But this got me to thinking. If i had 2 very similar processors, would I prefer to have a non-shared feature just masked off on the better one? or have nothing work? I think they made a mistake here.

Now on to the next problem (the stupid UPS I bought for it has a L5-30P twist-lock connector). So i’ve acquired the L5-30R receptacle and 10m of #10-3 armoured cable and 30A single-pole breaker. So I guess Sunday morning will be spent fishing a new power cable.

Nothing is ever simple!

Recently we’ve been seeing a lot of ‘baidu/…’ links sent via compromised skype contacts.

What is happening here is not malware. Instead, your password is known and someone has logged into the web interface to use it.

How did your password become known? Recently dropbox was compromised, as was yahoo, and many other large sites. And, its likely, that you have used the same password on more than one site. <strong>DO NOT DO THAT</strong>. But you say, I cannot remember all of them, what am I to do? Well, there is a simple technique to reduce your risk.

Step 1. Pick 3 passwords (high/medium/low).
Step 2. On each site or service you use, assess your exposure if it becomes known. Put it in one of those three categories.
Step 3. For each site, set the password as {high|medium|low}-sitename

OK, so lets give this an example. I use RBC, paypal for banking. Lets assume my ‘high’ security password is “goose”. So i would use goose-rbc, goose-paypal. Now lets assume I use github, a dns-registration system, dropbox. I assign these ‘medium’ and my medium password is “beaver”. So it would be beaver-dropbox, beaver-dns, etc. Lets say I have some ‘low’ accounts, e.g. feedly. If my ‘low’ password were ‘squirrel’, then i would have ‘squirrel-feedly’. Now i only need to remember 3 things (goose/beaver/squirrel) no matter how many sites.

Now, lets assume dropbox gets hacked again. Well, its not people going through this list. They take my username + ‘beaver-dropbox’ and try to supply it to RBC, it fails.

Of course you should always use 2-factor authentication when you have the opportunity, but not everything got the memo.

The current issue we are seeing is not a vulnerability in Skype, its a vulnerability in the users. It can just as easily be happening on other services **AND YOU WOULDN’T KNOW**. E.g. if your Skype sent spam, you are embarrassed. But the same agent that did that might be spending your money right now from your bank and you wouldn’t know. So, again, <strong>NEVER USE THE SAME PASSWORD ON 2 SITES</strong>.

A lot of people say, oh, use special-symbols etc. This really doesn’t help, its not dictionary attacks used here. Neither does rotating the passwords over-frequently. This just leads to writing them down.

Of course there are tools (lastpass et al) that can help this problem out a lot. But the above technique is strong and simple, feel free to use it and share it with your friends and family.

OK we’ve all watched Maximum Overdrive (starring the music of AC/DC) a number of times. Great movie.

It seems that the movie is on point for our future with the exception that its not Diesel powered, CB-communicating trucks, but instead, light-bulbs slurping WiFi that will be our skynet undoing.

Watch this great video of a drone infecting a building full of lightbulbs and weaponising them. IoT goes nuclear is the pleasant title chosen by the perpetrators. You can read the paper here. zigbee + wifi + drone, its just missing Who made Who.