Linux Kernel Hardens Sound Drivers Against Spectre V1 Vulnerability

[mastermind]

The kernel needs to be gradually rewritten in a language like this:

[starshipeleven]

Missing a "/s"?

A bit exaggerated, but not totally sarcastic. You do have a too low idea of the quality standards there.

Torvalds would reject AND shout profanities at anyone that tries sending what you were worried about, and the other top-level maintainers (and probably also other maintainers as well) will also reject it because that would be an ugly hack.

If they were allowing these shitty practices at all, the kernel would have become a bloody mess a while ago.

[leigh123linux]

I hope these changes don't add any latency

[cl333r]

I do not understand why sound drivers need protecting against Spectre, etc. I do not think that sound drivers use passwords and I assume that this does not protect audio recordings made with the sound hardware. Could someone please say where the risk is with sound drivers?

Sounds that have hi pitches may cause audio driver buffer overflow which is why so many people listening to dubstep have been infected with viruses lately.

[cybertraveler]

Your lack of faith in kernel devs is disturbing. Repent asap or face the consequences of your sin.

Missing a "/s"?

The function used here for mitigating speculative vulnerabilities (Spectre) is into ifdefs (conditional macro code) and enabled/disabled with _LINUX_NOSPEC_H config. It's also sitting in its own file called "nospec.h", and there is a text file in the docs to explain what is this about https://github.com/torvalds/linux/bl...peculation.txt

Most other stuff about speculative vulnerability follows the same criteria, and it usually contains "nospec" in the name. https://github.com/torvalds/linux/se...q=nospec&type=

Note that commenting may not be very verbose as you can look up the git history of the file with all the commits to it and the descriptions from there.

Thanks for the high quality info. Appreciated. I'm glad to see they're doing it right.

[Vistaus]

Typo:

it has uncovered hundreds of potential areas where the kernel's C could could

One could is sufficient.

More is better better.

[starshipeleven]

I wonder if the kernel source code is now littered with code designed to mitigate these issues. I hope that they're making decent use of conditional macro code chunks so they can easily disable this stuff in the future. I hope they're commenting their changes well too.

Your lack of faith in kernel devs is disturbing. Repent asap or face the consequences of your sin.

The function used here for mitigating speculative vulnerabilities (Spectre) is into ifdefs (conditional macro code) and enabled/disabled with _LINUX_NOSPEC_H config. It's also sitting in its own file called "nospec.h", and there is a text file in the docs to explain what is this about https://github.com/torvalds/linux/bl...peculation.txt

Most other stuff about speculative vulnerability follows the same criteria, and it usually contains "nospec" in the name. https://github.com/torvalds/linux/se...q=nospec&type=

Note that commenting may not be very verbose as you can look up the git history of the file with all the commits to it and the descriptions from there.

[Xaero_Vincent]

It looks like the Spectre / Meltdown speculative execution flaw fun isn't over yet! 8 new security vulnerabilities found in Intel processors. Xorg server security is beginning to look like an armed fortress in comparison to CPUs.

https://www.neowin.net/news/more-flaws-discovered-in-intel-chips---some-serious-expect-patches-soon

[cybertraveler]

I wonder if the kernel source code is now littered with code designed to mitigate these issues. I hope that they're making decent use of conditional macro code chunks so they can easily disable this stuff in the future. I hope they're commenting their changes well too.

[starshipeleven]

I do not understand why sound drivers need protecting against Spectre, etc. I do not think that sound drivers use passwords and I assume that this does not protect audio recordings made with the sound hardware. Could someone please say where the risk is with sound drivers?

Spectre (and Meltdown) aren't about passwords, but about exposing memory to processes that should NOT have access to it.

One of the things done by the kernel is segregating applications in RAM, denying them access to areas of RAM that is allocated by something else (or by the kernel for itself). The ability to break this segregation is bad.

To exploit this you would need to craft malware that interacts with these drivers, as explained by pali above.