Intel bug incoming.

So, the Pi2 v1.1 has the A7, which was NOT on the list that was published yesterday. The Pi3 has the A53 (also not on the list). I guess I'm doing OK with the Pi2 boards and the Odroid XU4 boards, (8 cores: 4 cores are A15 (on list), 4 cores are A7 (not on list)). I've turned the four big cores off, since for net browsing they aren't needed. It looks like my C1 boards are OK as A5s are not on the list.

Edit: Now the ARM affected list is active:

https://developer.arm.com/support/security-update

I'm reading various places that there are two main gaffs - "meltdown" and "spectre", with spectre being less immediately worrisome but harder to fix. A small number of ARM cores were said to be susceptible to spectre. Apparently only the Cortex A75 is susceptible to meltdown. A note on the linked page seems to indicate they're not very worried about the A15, but it's not clear to me. We are looking at the early reports, so this could all be wrong. My other machines are all AMD. I stopped using Intel a long time ago. Happy for that.
 
ShelLuser said:
Don't know if you already saw this article but AMD and Arm also seem to be affected, according to El Reg of course but they're usually right about these things.
Click to expand...
Afaik in general the Intels are affected by the Meltdown bug and all cpu's are affected by the Spectre bug. There is also a list on the Intel website with the unfortunate cpu's:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr
Seems that my machine is too old. But I'm still not 100% sure though.
 
Maybe it is a silly question but there is so much information regarding this topic and it was quite unclear.

What does the fix released for other OSs solve? I mean only Meltdown or both Meltdown and Spectre? Because I have read that Spectre could be harder to patch
 
Apparently, the thinking is that Spectre requires a hardware change on most platforms to fix - so no patch. Meltdown can be patched. This is the stuff that's being put out there. Interestingly; the link in my last post shows a Spectre patch on the page, so I'm confused.
 
The solution for now is "kernel page table isolation", but that only works against Meltdown. And that is what all os's are implementing now. Drawback of this patch is that it probably makes the os slower. For Spectre isn't a solution yet.

The only real solution is swap the chip for one that doesn't have the bugs.

Note that what's also confusing is that there are multiple teams that investigated the same bugs at the same time. But I think the two sites where it all comes together are:
- https://googleprojectzero.blogspot.nl/2018/01/reading-privileged-memory-with-side.html
- https://meltdownattack.com/
 
From FreeBSD News Flash:
4 January: About the Meltdown and Spectre attacks: FreeBSD was made aware of the problems in late December 2017. We're working with CPU vendors and the published papers on these attacks to mitigate them on FreeBSD. Due to the fundamental nature of the attacks, no estimate is yet available for the publication date of patches.

Two questions:
- why it was known to other OS vendors in July and FreeBSD made aware in late December?
- can FreeBSD just copy the technique went into Linux kernel a while ago? Do they differ a lot in this subject?
 
robert1307 said:
- why it was known to other OS vendors in July and FreeBSD made aware in late December?
Click to expand...
How much money do Intel (and AMD) make from FreeBSD? How many FreeBSD (or *BSD in general) developers does Intel have on staff? I think the answer is: a little bit, and zero. For Linux the answer is: many billions of $, and thousands. That in and of itself is the core of the answer to your question.

The other issue is this: Since Intel (and RedHat and Microsoft and HP and IBM and Oracle and ... you name it) have thousands of Linux developers on their staff, and since those developers are either under normal trade secret protection or are willing to sign NDAs, the information about bugs like that is easier to distribute to them, without lawyers making a mess of things. The extreme example of this is OpenBSD: No OpenBSD will ever sign an NDA (that's explicitly verboten by Theo), therefore OpenBSD developers will never get information about touchy subjects until it is out in public. This is both good and bad; in the current situation it is bad for the development schedule of a fix.

- can FreeBSD just copy the technique went into Linux kernel a while ago? Do they differ a lot in this subject?
Click to expand...
They are very different. The general idea can be copied, but the implementation has to be wholly separate.

By the way, I feel much more comfortable and safe running a well-managed FreeBSD system that is not fixed against Meltdown/Spectre, then running a Linux system that has been secured against them, but is badly managed (most Linux sytems are, to some extent because Linux has become so complex and byzantine that it is hard to manage cleanly and well, see the discussions about systemd being a mystery to most people). That would be even more true for OpenBSD (alas, I no longer user OpenBSD, although not for reasons that should be interpreted as a criticism of OpenBSD). Here's why: Both these bugs are fundamentally a door to privilege escalation: Once an attacker is already running programs on your computer (in user mode), they can get into kernel mode (or at least read kernel mode memory). But if only trustworthy people even run programs on my computer, then it doesn't matter much that those trustworthy users could do nasty things, since by design they are trustworthy. And I think that the *BSD systems are much less vulnerable to malware, and to unauthorized access.
 
ralphbsz said:
But if only trustworthy people even run programs on my computer
Click to expand...
I am not sure that I'd trust all the javascripts and web workers that run on my browsers.
There will be hectic activity in the scripter scene to make 1-day exploits, I guess.

Maybe it's not overly paranoid to at least block ads, avoid porn sites and the like until we got our fsckwit pendant.
 
Ah, good point. My FreeBSD machine is only a server, has no user interface (console in text mode doesn't count), and never browses the web.
 
robert1307 said:
From FreeBSD News Flash:
4 January: About the Meltdown and Spectre attacks: FreeBSD was made aware of the problems in late December 2017. We're working with CPU vendors and the published papers on these attacks to mitigate them on FreeBSD. Due to the fundamental nature of the attacks, no estimate is yet available for the publication date of patches.
Click to expand...

I guess that I am fortunate to be running AMD on my Windows system and both of my FreeBSD systems. My OpenBSD system is not vulnerable to any of these exploits because it's a SPARC machine. Come to think of it, the two firewall machines are also AMD. I just hope that the *BSD developers do what was done in Linux...which is to check the CPU vendor before applying the fix.
 
How about this for a quick fix: All variants depend on accurate timing of events. Couldn't we just mung the clock so that microsecond timing is not accurate anymore?
Imagine just rounding the HPET to millisecond and adding an incrementing value to keep it going up. It would certainly break these attacks!
What else would break by this approach?
 
Maelstorm said:
I guess that I am fortunate to be running AMD on my Windows system and both of my FreeBSD systems. My OpenBSD system is not vulnerable to any of these exploits because it's a SPARC machine. Come to think of it, the two firewall machines are also AMD. I just hope that the *BSD developers do what was done in Linux...which is to check the CPU vendor before applying the fix.
Click to expand...
Are you sure? All cpu's with branch prediction are vulnerable for the Spectre variant. I think most of the cpu's in the last 20 years or so have that.
 
aribi said:
Couldn't we just mung the clock so that microsecond timing is not accurate anymore?
Click to expand...
No, the timing used here is much more accurate than microsecond timing; it's the CPU's internal cycle counters.
And one can't just break the clock, because programs are capable of making their own clock. They can for example have a separate thread that runs on a separate core, and which does nothing but regularly issue slow but steady operations (like long floating-point divides) that have predictable performance, and count how many get done.

Imagine just rounding the HPET to millisecond and adding an incrementing value to keep it going up. It would certainly break these attacks!
What else would break by this approach?
Click to expand...
Good question. Normal user-level code (things like awk, sed and grep, or analytics or data bases) don't measure timing of operations accurately, since they care to get work done, not so much how long the work takes. There are certainly micro-benchmarks that measure timing to microsecond level; for example doing performance studies of disk drives needs to be that accurate when dealing with SSDs. If those benchmarks average over long enough periods, they should be OK, since they operate on time differences, which eventually have to smooth out. So people would do precision benchmarks would notice that their measurements have much more variance, but the long-term average is still right.

I know that there are programs that change their behavior based on performance measurements. One example are big data bases, which measure how fast the disk subsystem is (both random and sequential) compared to memory accesses, and adjust their query optimization strategies based on that (whether to build temporary tables and temporary indices, and whether to process them random or sequential). Another example are storage systems that track disk performance to call for preventive maintenance, and to steer workload to faster disks. Deliberately breaking timing could theoretically disrupt these techniques, but I think people who write such high-precision measurement tools know how to guard against statistical fluctuations.
 
ralphbsz said:
No, the timing used here is much more accurate than microsecond timing; it's the CPU's internal cycle counters.
And one can't just break the clock, because programs are capable of making their own clock.
Click to expand...
You are right. But, the access to the RDTSC (read time stamp counter) instruction can be disabled, so that an attempt to read that results in an privilege exception.
Does there exist an option to disallow this instruction in user mode?
And regarding alternatives, like a second thread on another cpu, I am not sure whether such will be exact and fine-grained enough to be used for Spectre. Aside of the difficulty to set that up such from inside a browser.

ralphbsz said:
Deliberately breaking timing could theoretically disrupt these techniques
Click to expand...
Hmm. The examples you listed are typical for servers. These usually don't have to execute untrusted foreign code like browsers.
Maybe it would be sufficient to reduce the granularity from, say, 1 to 3 microseconds, to make the high res time counter functions unsuitable for bug exploiting, without taking away more precision than necessary.
 
Snurg said:
You are right. But, the access to the RDTSC (read time stamp counter) instruction can be disabled, so that an attempt to read that results in an privilege exception.
Does there exist an option to disallow this instruction in user mode?
Click to expand...
That might be possible (I don't know whether it is, haven't checked). But I think it's impractical, because then one would have to fix every harmless application that uses this technique for measuring time. And I'm sure that 99.9% of those uses (perhaps 100%) are not malicious.

But as you said, compromises might be possible.
 
aribi said:
How about this for a quick fix: All variants depend on accurate timing of events. Couldn't we just mung the clock so that microsecond timing is not accurate anymore?
Imagine just rounding the HPET to millisecond and adding an incrementing value to keep it going up. It would certainly break these attacks!
What else would break by this approach?
Click to expand...
That is similar to Mozilla fix in Firefox 57.0.4 :
mozilla said:
Since this new class of attacks involves measuring precise time intervals, as a partial, short-term, mitigation we are disabling or reducing the precision of several time sources in Firefox. The precision of performance.now() has been reduced from 5μs to 20μs, and the SharedArrayBuffer feature has been disabled because it can be used to construct a high-resolution timer.
SharedArrayBuffer is already disabled in Firefox 52 ESR
Click to expand...
 
You must log in or register to reply here.
Back
Top