'Kernel memory leaking' Intel processor -- a serious cpu bug!?!

[PurpleSunray]

Regarding passwords: you know exactly how this works so why ask stupid questions?

To get stupid answers from you.

The point is the text is transmitted in the open in userspace, so whether it's in the kernelspace or not is irrelevant at that point. The real threat is via the less severe issue it is possible for javascript in your browser to potentially implement a keylogger. Some browsers have already been patched.

If you can convice the system run your code on ring 0 (via i.e. meltdown), you ARE THE KERNEL.
The memory is your's now - access whatever you want, nobody will stop you from it (including stuff on ring 3, aka your app, that has the password on user-space .. where user-space is nothing else than a memory page.. fully accessible from ring 0).

[aciddose]

You're just worsening the situation regarding confusion of these two very separate issues.

Browser patching seems equally speculative though ... we know this is a timing issue so we'll make our timers less accurate ... and dance around a fire and hope that works for the time being.

Yes... although any timing attack requires accurate timing and control over program flow. There are few tasks that require timing accuracy in the uS, so by increasing the resolution of JS timers it makes these attacks impossible without some other timing source.

Add this to the list of "shit JS shouldn't be doing in the first place" and put it up on the "why web 3.0 is a f**king stupid idea" bulletin board.

A browser isn't an OS, and web pages are not programs

[EvilDragon]

So after some encouraging results from people at VI-C and GS, I pulled the patch. I did a DAWbench VI in Reaper before the patch and after, and I'm getting much the same numbers: 820 voices at 128 samples buffer with my RME UFX+, and with the factory library on Samsung 850 EVO. i7-6700K at 4.5 GHz here.

So, it seems that ASIO performance wasn't affected one bit (at least as far as Reaper is concerned). Looks like DAW users fall into "average workload" crowd.

[PurpleSunray]

u're just worsening the situation regarding confusion of these two very separate issues.

ahaha, I don't think so, confusion is at max already

So what problem are you talking about?
I'm on the one where my code, that should run on ring 3, is executed speculatively or out-of-order on ring 0 .. because Intel forgot to handle GP(0) exceptions properly on their out-of-order execution engine.
So my code that is supposed to on user-mode, now suddlenly runs on kernel mode, inlcuding all privileges.

[lnikj]

So after some encouraging results from people at VI-C and GS, I pulled the patch. I did a DAWbench VI in Reaper before the patch and after, and I'm getting much the same numbers: 820 voices at 128 samples buffer with my RME UFX+, and with the factory library on Samsung 850 EVO. i7-6700K at 4.5 GHz here.

So, it seems that ASIO performance wasn't affected one bit (at least as far as Reaper is concerned). Looks like DAW users fall into "average workload" crowd.

Good to hear !

[PurpleSunray]

A browser isn't an OS, and web pages are not programs

V8 (the JScript engine underknee many browsers) is not interpreting JScript, but it is compling JScript to x86 instructions and then executes it. So your webpage is in fact a programm like any other too.
If you know about how V8 translate JScript to x86 instructions, you can do same hacky stuff as with a C compiler (ok not same - direct memory access is not possible - but it is important to understand that JScript is not interpeted as on back in old days, but it is compiled and executed nowadays).

[aciddose]

PurpleSunray:

I thought you said you didn't consider your DAW to be in need of extreme security features. That you don't care. So your issue is simply that you're bored?

The Intel flaw is a much larger scale issue that doesn't affect small time users running DAWs and such.


EvilDragon:

Yes there is no reason to expect processor intensive tasks would be affected by this issue at all. There is some possibility disk-streaming might be, but that's extremely unlikely too because the number of kernel-space / user-space switches are minimal where efficiency is important because calling the OS functions to handle streaming was already expensive enough, so these calls are minimized.

The real issues are more on a scale of what will happen to the PC market due to our niche depending upon huge server farms and office PCs to provide us with scale for the market leading to ultra-cheap hardware.

[aciddose]

A browser isn't an OS, and web pages are not programs

V8 (the JScript engine underknee many browsers) is not interpreting JScript, but it is compling JScript to x86 instructions and then executes it. So your webpage is in fact a programm like any other too.
If you know about how V8 translate JScript to x86 instructions, you can do same hacky stuff as with a C compiler (ok not same - direct memory access is not possible - but it is important to understand that JScript is not interpeted as on back in old days, but it is compiled and executed nowadays).

Yes I knew you would jump on that. I should have followed my instinct and written "web pages SHOULD NOT BE programs".

"Web assembly" and the like are the stupidest idea ever. They're just inventing new attack vectors for everyone to turn the web into a massive botnet.

See here: http://motherfuckingwebsite.com/

[PurpleSunray]

I thought you said you didn't consider your DAW to be in need of extreme security features. That you don't care. So your issue is simply that you're bored?

No, I did not mention security at all.
There is no extreme security for me, either something needs to be secure or not. What's the difference half-secure vs extremly secure?

I don't care about because I'm don't feel affected by it.
I will continue to enter passwords on my DAW, since securty flaw is fixed by kernel patch.
Kernel patch has no negative effect for me, since by DAW will do lot of user-mode number crunching mainly and not much of kernel interaction.

So the "I don't" is not "I don't because my DAW can be unsecure", but it is "I don't care because by DAW is secure again after patch and performace degrade does not affect me when producing music".

[aciddose]

Well, just wait and see next time you want to upgrade your hardware, or when you're forced to because everyone is running Arm now...

[PurpleSunray]

"Web assembly" and the like are the stupidest idea ever. They're just inventing new attack vectors for everyone to turn the web into a massive botnet.

One more topic we disagree.
I actually like what they are doing.
Flash, Silverlight, Pepper-API, NCAPL and all that bullshit plugins stuff was (and still is) a huge attack vector.
Happy they closed it by simply dropping that shit and adding the missing features to HTML5.

People want to watch video and play games and run HTML5 DAWs on their browser or whatever.. so there needs to be a solution for it. Drawing a 3D-open-word game, running on an interpreted JScript with emulated OpenGL won't work.... this needs native performance.
And there I clearly prefer HTML5 features as webasm, webgl & co over crappy closed-source flash & co plugins where nodoby know what they are actually doing on your system.

[aciddose]

Did you see: http://motherfuckingwebsite.com/

[PurpleSunray]

Nope, I'm at work and the "sophos web protection" thing blocks access to this page.

[Burillo]

"Web assembly" and the like are the stupidest idea ever. They're just inventing new attack vectors for everyone to turn the web into a massive botnet.

actually, of the whole "new Browser API allows access to USB dildos and buttfuck you" variety, WebAssembly is the one good idea. it will basically allow to ditch that JavaScript abomination and write safer and more performant web code (i.e. write it in Rust, for example). anything that relegates JavaScript to being a relic of the past is a good thing. the problem isn't WebAssembly - it's the new API's that attempt to replace the OS.

[aciddose]

They're a horrible idea for the same reason everyone using Chome is a horrible idea: it means in order to access a page you'll be required to give permission to run arbitrary code on your machine. In the past before it was possible to include javascript from 100s of servers and obfuscate its actions that way, javascript was a reliable way to achieve simple tasks.

A large number of pages are already only possible to load from Chrome and no other browser.

See: http://xhip.net/effects/ (note the only JS is inline, it's trivial to see exactly what it does if you auto-format the text and the page works fine without it, just without the JS enabled non-critical features such as image "zoom".)

Once "web assembly" is commonplace it won't be possible to view anything on the web without handing over full control of your processor to arbitrary agents across 100s of servers, exactly like the situation with JS right now.

In combination with these types of exploit, that means you have zero ability to ensure the code comes from a trustworthy source and zero ability to ensure your system is secure (the code is sand boxed) when running it.

Running Chrome means you hand over all sorts of information and control to Google which will eventually lead to "Chrome 6.0", remember "IE 6.0" ?