Google Posts KVM-CPUFreq Driver To Dramatically Boost VM Performance, Power Efficiency

[cl333r]

Whenever I read "Google works on driver x", I end up thinking, "I wonder what PRISM-style backdoor they've added to it, and how long it will take to find it and to find out how much damage it did?"

It would almost be better if Snowden had never red-pilled the world and I could live in ignorant bliss. Like Cypher in the original Matrix movie - it would be nice to be able to just plug back into the Matrix and enjoy juicy steak dinners.

OT, that steak from the movie was the juiciest one I ever saw. Also, some say we're in a simulation so we could be in like a Matrix within a Matrix within a Matrix, at least that's how really old religions tell it: we're not real, we're a dream of a God that is asleep and we're in his dream, and that God is not real either - he's in a dream of the parent God of all Gods who sees that God in his dream [1].

[1] https://www.youtube.com/watch?v=lGB79MupJDU

[mercster]

Whenever I read "Google works on driver x", I end up thinking, "I wonder what PRISM-style backdoor they've added to it, and how long it will take to find it and to find out how much damage it did?"

It would almost be better if Snowden had never red-pilled the world and I could live in ignorant bliss. Like Cypher in the original Matrix movie - it would be nice to be able to just plug back into the Matrix and enjoy juicy steak dinners.

Just, uhh... read the source?

[archkde]

Just, uhh... read the source?

I really doubt any of their Linux kernel contributions contain surveillance software. They probably contribute so that their actual surveillance software runs faster or on less electricity.

[robclark]

Well, they offered a chromebook example (which are power/battery constrained).

exactly this :-)

[marlock]

I really doubt any of their Linux kernel contributions contain surveillance software. They probably contribute so that their actual surveillance software runs faster or on less electricity.

it's a good assumption in general, but they did push Speck (cryptographic algorythm) into the linux kernel for use in weaker android devices, and Speck was authored by NSA, and it was provenly weak (albeit resource-efficient for its strength tier), so...

anyway, kernel devs and cybersecurity companies from all over the world are checking mostly everything since that USA university professor tried to push vulnerabilities into the upstream kernel on purpose... "for science" the jack...s said... (he got the entire university banned off linux kernel contributions for the forseable future due to his unethical social experiment and the kernel is still standing)

and the current code is explicitly not meant for upstreaming, only for testing and iterating upon... it's basically a "request for comment" code drop

[Jumbotron]

I kinda like what that university professor did. I'd rather have him wake up the community than a Uni Prof from China, Russia or North Korea.

[marlock]

yeah, i'm also glad the kernel devs now trust university contributors as little as everyone else... the extra trust these entities enjoyed would eventually be used as a door for malicious contribuitions (exactly what that professor did)

i especially like the kernel devs reaction to the university's messed up ethical oversight process (they OKed the professor's actions without any course-correction, which is totally nuts)

i also like how the professor's justifications for his actions had zero weight in the code review that ensued, so it didn't matter if he was (at long last) honest about it, or if he was (as suspected by several) using the research and the neutral changes as a cover (plausible denial) for actually inserting breaches into production kernels so some priviledged outsider could use them knowing in advance they'd be put there

anyway, we went sort of off-topic, but this and the Speck cases are worth keeping in mind lest we start downplaying the tangible risk of malicious contribuitions by high-visibility entities engaged in long-term colaboration efforts to the kernel... "came from [email protected]" is not a replacement for code safety reviews...

...and "came from google" is not a reason for automatically discarding a code contribution... more often than not their upstreaming efforts are ok to use after a couple rounds of review and we routinely criticize google for not submitting more of their android/chromebook kernel stuff upstream and prioritizing the use of upstream kernel in their OSs, so they have to be able to do (with proper peer review like everyone else) what we demand them to do...

[JosiahBradley]

Something something side channel cross VM hopping now that it can read freq response from the host in mixed VM environments. Shielding this will be fun.

[marlock]

JosiahBradley, good point! allowing extra info to be exchanged between host and VMs is never trivial in the world of side channel attacks

[Scramblejams]

Regarding desktop usage, I am curious whether this has the potential to reduce or eliminate the need to isolate and pin CPU cores to avoid stuttering in GPU passthrough gaming applications. I've imagined that could be improved if the host and guest cooperated on CPU scheduling needs, and this looks like some version of that...