Processor kernel vulnerabilities

PowerPC/X360

Damn. Somebody bring back the 6502, which was simple to use and understand and didn’t suffer weird side effects of doing things nobody told it to do (is this the first step of self aware AI?).

Well, quite apart from the rather large size¹ of the, erm, “patch(es)” it seems that MS may not have done much testing either because there’s a few AMD processor users been a little bit upset with the automatic update doing something not nice to their machine.

¹The description from the server boys about the patch size was “that’s not a patch it’s whole f’ing OS”

it seems that MS may not have done much testing either because there’s a few AMD processor users been a little bit upset

Given the Microsoft/Intel conjunction, I wonder if MS tested on any AMD hardware at all? Clearly if it isn’t compatible with Intel, it’s the processor at fault… [and yes, I know where x86-64 came from ⚋]

I have just received and installed a half gigabyte update for my S7. It is still Android 7.0, this time with a patch date last October, so I doubt it has mitigation for the current “OMG!” issues.
It’s a shame Samsung don’t provide a basic change list because as far as I can determine, it’s half a gigabyte to make my overlaid notification icons a sort of dirty sea green colour…
Plus it would be really nice to see your favourite pet bug nailed to the wall, something like:

• Fixed sporadic system crashes when trying to register cat paws with the fingerprint sensor.

there’s a few AMD processor users been a little bit upset with the automatic update doing something not nice to their machine.

I have little sympathy with any users who let automatic updates change anything.

At the very least all updates should be set to ask first – stating why and how big a change. (and not proceed without a positve permission. Giving the user a chance to run a backup.

I’d say it was the season for bugs and fixes, but the WD NAS bug appears to be one that was fixed in the code they seem to have borrowed from DLink in a 2014 version of the DLink code.

What’s wrong with a password of abc12345bca anyway? You won’t find it in a dictionary :)

Plus it would be really nice to see your favourite pet bug nailed to the wall,

There’s a list of things I’d like to see nailed to the wall, but bugs come further down the list than the reproductive bits of a few different people.

The description from the server boys about the patch size was “that’s not a patch it’s whole f’ing OS”

Sounds like they grabbed the “OS build” version of the patch, not the “Security-only” version. I hope they updated the AV software first, otherwise the patch won’t install.

Meanwhile a fun read from Linus Torvalds on Meltdown/Spectre fixes ;-) getting really angry on Intel “morons”, how he calls them. Link

Somehow it seems to me that issue will be a long story until it’s fixed properly…

No, Kuemmel… Morons is not the word that should be in quotes, fixes is, as it seems to me (and Linus, one presumes) that Intel is more interested in “fixing” liability than “fixing” the processor.

The actual fix is a harder thing to consider… but then I’m not a processor designer. It seems to me that instead of having hidden caches or separate kernel/user caches, it might be much simpler to have the processor automatically invalidate cache lines used by the speculative execution unit for the path not taken. I’ll await Jeffrey telling me why such a thing won’t work. ;-)

BTW, there’s a beautiful part in the linked message that is begging to be repeated (with my asterisks):

BULL****.

Have you _looked_ at the patches you are talking about? You should have – several of them bear your name.

Sweet.

No, Kuemmel… Morons is not the word that should be in quotes, fixes is, as it seems to me (and Linus, one presumes) that Intel is more interested in “fixing” liability than “fixing” the processor.

I rather got the impression that Linus wants to get to the Intel design team and ‘rip them a new one’ as the saying goes. It certainly seems that anyone who acts an an apologist for Intel is subjected to a preliminary tearing.

Can’t help thinking that if you were a motor manufacturer and you produced a vehicle that didn’t perform as advertised when adhering to standards then you’d be replacing the vehicles or paying substantial amounts to the users in compensation to allow them to purchase a vehicle from someone else who did make compliant vehicles.
The Intel¹ version leaving it to OS and application authors to fix is rather like VW insisting the petrol companies need to produce a better diesel grade or explain why the VW doesn’t work properly.

¹ and other processor designers to different extents

I think they are in a real dilemma. When you read Intel’s FAQ about it here
…you clearly think a lawyer wrote that:

Is this a bug in Intel hardware or processor design?

No. This is not a bug or a flaw in Intel® products. These new exploits leverage data about the proper operation of processing techniques common to modern computing platforms….

Because I really think it is a bug or they just forgot to address the consequence of the possible data leaks from the cache due to speculative execution. It’s like creating a fast monster and let it do what it wants on it’s own a little bit too much without thinking thourougly…and now they don’t want to admit it due to the obvious financial consequences…but I’m pretty sure the engineers for the next gen CPU’s are getting a very busy time from their management to get rid of that problem.

@Steve: I also thought about the comparison with the diesel scandal…only difference is that VW cheated very much on purpose and I think Intel didn’t do that. But the major difference will be that Intel by no means will be sued for that by their own US government…the loser will be again and always the end user :-) …I wonder if some lawyers pick it up and get Intel to take the CPU’s back from the end user as they are slower after the fix as far as I read about it.

The Intel version leaving it to OS and application authors to fix is rather like VW insisting the petrol companies need to produce a better diesel grade or explain why the VW doesn’t work properly.

I disagree. Red Hat recently pointed out that the microcode is a signed blob, and, as such, nobody but the processor manufacturers can provide it – even if anyone else had the technical capability to write appropriate microcode.

All the OS vendors can do is pass on the microcode given to them by the chip manufacturers, and I entirely understand that it must be so.

I disagree. Red Hat recently pointed out that the microcode is a signed blob, and, as such, nobody but the processor manufacturers can provide it

Fair enough on that simile. Pick another product where the user has some negative effect from use of that product vs. the similar product from a different manufacturer. The user expects a fully working replacement/substitute and/or financial recompense.

I wasn’t suggesting that people like MS should be shelling out cash¹ in fact I think Intel have handed MS etc the sh** end of the stick².

¹ The effort they are putting in on patching and testing their OS and apps must be costing them significant amounts

it might be much simpler to have the processor automatically invalidate cache lines used by the speculative execution unit for the path not taken. I’ll await Jeffrey telling me why such a thing won’t work. ;-)

The problem with that approach is that the ‘invalidated’ cache entries will already have evicted previous cache entries which can be picked up on.

And so it goes…

https://www.theregister.co.uk/2018/02/14/meltdown_spectre_exploit_variants/

On and on and on…

https://www.theregister.co.uk/2018/07/23/spectre_return_stack_buffer/

I wonder if Linus is going to get all shouty again…?

Meanwhile a new publication shows a lot more variants of Spectre/Meltdown being possible. Table 5 shows the vulnerability in respect to Intel/ARM/AMD…that issue is far from being solved…