L1d Flushing Patches Revived After It Was Rejected From Linux 5.8 As "Beyond Stupid"

[skeevy420]

If you are on Windows, sure. This is basically a DoS switch that allows any userspace application to make the whole system's performance tank hard.

I wouldn't say reacting badly to its introduction is a weird thing.

But it really isn't though. For people like us, worst case scenario is we update our kernel command lines to force disable any l1d flushing.

[starshipeleven]

But it really isn't though. For people like us, worst case scenario is we update our kernel command lines to force disable any l1d flushing.

Yeah, me, you and a few others, most others won't know and it will blow up in their face if stupid distros like Ubuntu enable this by default (I'm confident OpenSUSE won't).

I've been bitten enough times by situations where you need to be a sysadmin with 10 years of experience to operate a fucking PC without it blowing up unexpectedly, and I am some form of IT guy with 20+ years of experience. I understand if someone isn't cheering for the introduction of more stuff you must know beforehand so you can work around it.

[skeevy420]

Yeah, me, you and a few others, most others won't know and it will blow up in their face if stupid distros like Ubuntu enable this by default (I'm confident OpenSUSE won't).

I've been bitten enough times by situations where you need to be a sysadmin with 10 years of experience to operate a fucking PC without it blowing up unexpectedly, and I am some form of IT guy with 20+ years of experience. I understand if someone isn't cheering for the introduction of more stuff you must know beforehand so you can work around it.

Ditto.

[DanL]

None should worry about it, the kernel can read CPU ID on its own.

That would be the developers part of my statement then. The kernel does not magically develop itself.

[r08z]

Seriously without Torvalds, the kernel would be shit.

[carn]

Seriously without Torvalds, the kernel would be shit.

I really hope this was sarcasm... (I really can't tell from just reading the text).

[intelfx]

Well, quite a few phoronix users seem to be "beyond stupid", as the article clearly states in the second paragraph: "The overall concept of this new L1d flushing work remains the same is [sic] that it's entirely opt-in". Yet, someone was stupid enough to demand that this feature should be opt-in, not opt-out, and 6 people were stupid enough to like that comment.

It's opt-in by software and opt-out by administrator, while it should be opt-in by administrator.

[Azrael5]

kernel ignores mitigation code if the CPU isn't in the list of CPUs that need it. The kernel checks CPU ID.

None should worry about it, the kernel can read CPU ID on its own.

thanks for the answer. Are you sure about this workaround applied by the kernel systematically? Because the post talks about the new release of the fix able to be applied only for those CPUs affected by the specified vulnerability. So before the new release, the fix would have been applied to all CPUs without any distinction.

[Azrael5]

Users? They should be the last ones worrying about this kind of technicality. Developers, kernel distributors, and server admins (in respective order of preference) should be worrying about this.
https://www.kernel.org/doc/html/late...ted-processors

Do you mean that end-users are not affected by these fixes which make slower their own machines? Many users are selecting the CPUs to buy evaluating risks, benefits and capabilities. Many end-users are gamers. Do you think that they prefer a whole potential CPU or a CPU affected by many vulnerabilities which hurt the performance of their machine?

[DanL]

Do you think that they prefer a whole potential CPU or a CPU affected by many vulnerabilities which hurt the performance of their machine?

I don't think they care about that specifically, especially gamers. It's about performance/price. In other words, if CPU A outperforms CPU B at a given price, CPU A wins, even if it has some mitigations that B doesn't. Few people are going to buy CPU B just based on the "principle" that it doesn't have mitigations, or care if CPU A could be 0.5% faster without them.