Linux Kernel Hardens Sound Drivers Against Spectre V1 Vulnerability

[Vistaus]

Typo:

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

One could is sufficient.

More is better better.

[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.

[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.

[leigh123linux]

I hope these changes don't add any latency

[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.

[mastermind]

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

[cybertraveler]

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

You're mistaken. I expressed an absence of knowledge about how they implemented these fixes, an understanding that there is potential for low quality solutions to be implemented and a hope that the devs had implemented high quality solutions.

I appreciate the information you provided that demonstrated the Linux devs took a high quality approach to the problem.

[RSpliet]

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

Well, academics are interested in this idea, but I personally think there's two problems with such an approach. Firstly, a functional language wouldn't've helped against Spectre, as program checkers don't formally model details required to catch timing-based side-channel attacks on architectures. That tends to be way too much detail needed for validating *program* correctness...
Second problem is that very few programmers think in terms of mathematics. Especially in kernel device drivers, we just want to execute a sequence of operations. Although this is not forbidden by functional languages, it's often more tedious to write such sequential bits of code. It will most likely result in less-readable and thus less maintainable code, in turn leading to fewer kernel contributors.

[Leopard]

More is better better.

You are right indeed indeed.

[Leopard]

I quit as typo reporter for a few days until my ISP fixes a major connection problem within the area.

Don't worry , we got you covered covered.