A new security flaw is revealed with 'BlindSide' on Linux affecting Intel and AMD

Interesting. IIRC, the spectre type mitigations we're rather theoretical (although still possible). This stuff is a little over my head, but how realistic if an attack vector is this? Like visiting a compromised website or downloading a compromised file?

With fill ASLR which is now the standard on most dostros the issue is greatly reduced (source : the end of the paper)

Thanks, I tried to read a bit, but it was way over my head. I'm seriously jealous of this of you who can program and understand this stuff

I'm seriously jealous of this of you who can program and understand this stuff

I'm a programmer since 10+ years and even I barely understand half of it

!To be fair, there are probably a shit ton of undiscovered vulns for Power9.


To be fair, there are probably a shit ton of undiscovered vulns for Power9.

!To be fair, there are probably a shit ton of undiscovered vulns for Power9.


To be fair, there are probably a shit ton of undiscovered vulns for Power9.

Actually, can you run steam games on powerpc with qemu usermod ?

Thanks, I tried to read a bit, but it was way over my head. I'm seriously jealous of this of you who can program and understand this stuff

To make it simple, all these attacks are based on finding bits and pieces of information left in the CPU state.
These information can be various things: the presence of anything (or its absence) in your L1/L2/L3 cache, the state of the branch predictor in some spectre attacks, the state even of some specific cache (the tlb). All those caches are made to usually accelerate your cpu, whenever you do something costly, such as translating virtual to physical address, you put it in a cache in the hope that you will reuse it later (preferably soon).

Now, the problem is that, to go as fast as possible, when a program that does not have the right to access the data in theses caches tries to access the data, it still procedes almost the same as if it had the right to. The only difference is that at the very end an error will be raised. But the speed at which this error occurs will be faster if the data was here, or if the branch would have been taken etc etc.

So now, imagine that you execute a program on the same core as the program you want to attack, you would indeed share all those caches. As such, you will be able to measure time you take to get refused access to various data, with different types of accesses (direct access, branches, etc etc).
The result is that you can then infer a lot of stuff on the program. For branches in particular let's the say you write a code like "if(data != 0) then smthg else another thing" . Then if you can recover the "state" of that branch (what the branch predictor was corrected with), then you can deduce that data is 0 or not.
With other attacks, if you try to branch depending on the value of a private data for example, you might be able to deduce the value too. for example, you try if (forbidden_data == 0), and then you measure time of execution, or you find the state of the branch predictor afterwards (by trying to take the same branch and see if "taken" or "not taken" path is faster), and you can deduce that forbidden_data is equal to 0 or not. If you proceed byte by byte, you should only have to test 255 values at worst for each bytes. If you search for a 256bits AES key, that makes it 32 bytes, so 32 times 255. Even if you need multiple tries in reality, that really really not a lot.

For one of the spectre attack, what you essentially did was just make an access like this one:
read(array[forbidden_data]) where forbidden_data is a byte. The access will be refused, but the value at array[forbidden_data] will be cached by the cpu. Then you just read back every indices of the array, and the index which was represented by forbidden_data will have an access time that will be slightly faster than the rest of the array, telling you the exact value of forbidden data. You do need a bit of setup between each runs of the attack, (you need to load a large piece of data to make the cache filled with something else), but that's actually fairly efficient, a rogue javascript script could have begun guessing at what other scripts (such as the one where you put your passwords / credit card number...) were having in memory.

Hope this clarifies a little bit. But yeah, this is not so much programmer stuff as CPU architect / OS engineers stuff.


Last edited by 3zekiel on 13 September 2020 at 11:09 am UTC

Actually, can you run steam games on powerpc with qemu usermod ?

Or a Wine accompaniment program called Hangover, IIRC. Although I don't personally have any interest in running proprietary gaming software.

Actually, can you run steam games on powerpc with qemu usermod ?

Or a Wine accompaniment program called Hangover, IIRC. Although I don't personally have any interest in running proprietary gaming software.

Yeah, Hangover is also based on qemu user mode. If it works that's very cool :)
For me, I think games are art, as such, they don't really enter the "proprietary software" category. For the privacy part, I run steam in a sandbox.
I'm way more concerned with what "ring -1" stuff my CPU runs behind my back, because no sandbox and pretty much no analysis can save you from that ...
I'm just concerned by how usable the platform would be (Power based I mean).


Last edited by 3zekiel on 13 September 2020 at 11:14 am UTC

Yeah, Hangover is also based on qemu user mode. If it works that's very cool :)
For me, I think games are art, as such, they don't really enter the "proprietary software" category. For the privacy part, I run steam in a sandbox.
I'm way more concerned with what "ring -1" stuff my CPU runs behind my back, because no sandbox and pretty much no analysis can save you from that ...
I'm just concerned by how usable the platform would be (Power based I mean).

Being totally open, here are the hurdles that I hit moving from Debian amd64 to Debian ppc64le:

1. Some Debian packages I use were not yet buildable for PowerPC (the PowerPC repository has successful builds for 95% of packages, compared to x86), so I must build the programs for source for now.

2. Firefox had to be updated to 68 before it was fully usable. This was only a problem for Debian 10.0 and 10.1.

3. Only the cli (whiptail "GUI") installer is available on the ppc64le image, although I always install from cli anyway. This might be an issue for most others however.

People are saying to stay up to date, but I don't see any patches announced in response to BlindSide.

Actually, can you run steam games on powerpc with qemu usermod ?

Or a Wine accompaniment program called Hangover, IIRC. Although I don't personally have any interest in running proprietary gaming software.

Yeah, Hangover is also based on qemu user mode. If it works that's very cool :)
For me, I think games are art, as such, they don't really enter the "proprietary software" category.

Yeah, I'm at least partly on board with this position. That said, a corollary is that it's a very good idea for game engines to be open source. Go Go Godot!