Intel chip security risk?

Roon Software Discussion ROCK
1

How does this affect ROCK or the nucleus? Both run linux on a NUC

2

Your Intel-powered machine will run slower as a result.

3

Not that much slower though, as they are pretty modern.

1 Like
4

Pleased I finally purchased and just last night assembled my first ever AMD based PC:

5

Well, AMD is still affected by Spectre.

6

@danny can you anticipate what the impact would be for ROCK?
I guess upsampling could be affected

7

Not Danny, but I doubt anything Roon does is affected in a way that matters. I have hard time believing Roon does anything that requires almost 100% of the cpu while playing, so (for example) 5% performance penalty shouldn’t break functionality.

8

Actually, the article mentions 5-30% impact.
So if you’re already on the limit (by for instance heavy use of DSP for multiple zones), you may have impact.

9

Yes, 5-30% impact, but the high impact is with older processors (pre haswell) that lack PCID support. Also the size of the impact really depends on what you’re doing. My assumption is that Roon operates mostly in the userspace and even if hard calculation is required, it doesn’t really matter. I know there is some amount of disc and network activity, but I assume Roon doesn’t need a lot of system calls in and out of kernel, right? So the actual impact will be at the lower end of the range.

1 Like
10

We can only speculate how much the impact will be and how that would affect certain individuals.
However, I do agree that for most Roon users, it is likely to be neglecable.

Noticed that WMWare already released a patch, imagine the impact in already over provisioned ESX clusters!
Even 5% could make a huge impact (or cost to mitigate impact) for such clusters and for Cloud Services in general.

11

Given that the exploits require local access, and you can’t do that on ROCK, I’m not patching until things calm down. This problem is most critical for cloud providers right now as they sell local access to their machines. It doesn’t really change the security story for ROCK too much (for now).

8 Likes
12

MS have released an out of band patch for this issue on windows 10 1709 and Server 2016 1709;

https://support.microsoft.com/en-gb/help/4056892/windows-10-update-kb4056892

Note that there are a few known issues for the update at the moment so proceed with caution.

I have installed on my Roon server and one Roon controller, all is ok so far and I havent noticed a drop in performance. Passmark benchmark shows no difference in performance either.

13

I wouldn’t worry about the security risk, on a consumer device. The vulnerability seems challenging to exploit, there are other targets that better justify the effort. Like cloud servers…

EDIT I don’t mean that it is t3chnically challenging. It certainly is, but such exploits get published on the web, or sold on the dark web, ready for mass exploit by organized crime.

It’s because the exploit is very targeted, and generally overkill. On a consumer machine, (it seems) the exploit looks like this:

  1. Get unauthorized software to run on the consumer machine, through an email, phishing attack,etc.
  2. Run the new attack to snoop in kernel memory to find passwords or crypto keys.
  3. Analyze the haul to figure out what you got, which key the lock fits.
  4. Go after the asset thus exposed.

On a consumer machine, step 1 maybe enough.
In any case, all those steps fit a high value target.
Like compromising a cloud provider’s entire infrastructure…

1 Like
14

With ROCK the risk of these attacks is about 0. There is no general purpose computing going on so virtually no way to add attack software. Yes I am sure that it could be exploited but it is not a target. I would not overplay these flaws or the potential impacts until the software and security folks get a lot more time on them.

Lets let the ROON folks decide what to do here.

Bob Fairbairn
CISSP
CISM (Retired)

2 Likes
15

Things is that unless one branch off a build and keep it like that, the fix will sooner or later become part of the OS.
So while the risk of an attack is close to zero, the risk of a slight to moderate performance impact is not unlikely.

16

ROCK is a Linux subset, effectively a branch, maintained by Roon. A fix will only propagate into ROCK if and when Roon decide to include it.

17

Danny already said he will wait and from a security risk point that makes perfect sense to me.
However, In the long run, I don’t think Roon want to maintain their own kernel and other part of OS that may be affected by a fix.

18

I’ve been doing a bit of reading on Meltdown and Specter. Meltdown is pretty exotic in that in involves exploiting debris left in the machine state by speculative execution of code. Modern processors have sophisticated branch prediction logic and will execute the leg of a branch predicted to be taken. If the prediction is wrong, the processor abandons the results in place in the micro-architecture and begins executing the code in the other leg of the branch. There is a window in which the abandoned data is in place in the micro-architecture but it will be overwritten in short order.

This sort of out of order execution relies on the micro-architecture having a larger register file than that needed for the programmer-architecture visible register file, register remaining logic so it knows which micro-architecture register is serving as which programmer register and which are free, and logic for tracking which registers have been changed and need to be preserved.

To exploit the abandoned information produced by out of order execution takes a very sophisticated exploit that can inspect the micro-architecture hardware resources implementing the program-visible architecture, run down and dereference pointers, etc. The information needed lives in kernel space which is mapped into all processes. Typically, the most significant bit of the address is 1 for kernel space and 0 for user space. Since the exploit is looking at micro-machine state, the exploit can occur from any process but the time window for exploitation is very short as the micro-architecture registers are continually being reused. Figuring out what the debris might be is a non-trivial undertaking.

Given the difficulty of exploiting the machine below the programmer-visible architecture, only the best systems programmers will be developing exploits for meltdown. Because this is high difficulty time consuming work, I expect only espionage having a high payoff will exploit meltdown.

19

By contrast Spectre uses the same CPU behaviour to infiltrate the user memory space (rather than the kernel), can be readily exploited, doesn’t require high privilege access and will live with us all for a very long time since it can’t be patched out, at least not at the OS level anyway.

High risk applications such as web browsers will have to implement their own defences to prevent Spectre exploits from ransacking memory for keys, passwords and other sensitive information that is cached by the application. Performance will be sacrificed here too.

1 Like