News for hackers. Stuff that matters.
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by infinity0 on Thursday August 23, 2018 @01:43AM (#17824866)
> Another issue is whether the customer should install the fix at all. Many computer users don’t allow outside or unprivileged users to run on their CPUs the way a cloud or hosting company does. For them, these side-channel and timing attacks are mostly irrelevant, and the slowdown incurred by installing the fix is unnecessary.

lol, javascript

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by theprotocol on Thursday August 23, 2018 @02:22AM (#17825026)
>Another issue is whether the customer should install the fix at all

Microsoft will surely decide for me on my Windows 10 gaming PC. Better save my work (which I sometimes do even on a gaming machine) frequently lest the masters deem it fit to restart while I'm away having lunch if they decide I can live with the performance hit.

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by chrisper on Thursday August 23, 2018 @04:23AM (#17825521)
Just mark every 2nd Tuesday of a month as patch day and you won't have surprises!
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by theprotocol on Thursday August 23, 2018 @04:38AM (#17825584)
• Updates are not served to me at regular, known intervals. Perhaps it's due to a progressive rollout policy of some kind.

• Certain days come up that I, the paying user, do not want to patch on. Microsoft wins this disagreement and I lose. This occurs in a glib fashion with a message like "Hey, just a heads up, we are going to restart your computer" (whether I like it or not). It is my computer, there is no "we!"

It will absolutely close programs with unsaved work if I am not there.

• Maybe I don't want the performance hit on my gaming PC. This is another element of surprise: who knows how bad it'll be? Certainly not the users if Intel and Microsoft have their way.

• Yet another element of surprise: I've had hardware stop working after updates.

I cannot wait until it becomes viable to escape the toxicity of companies such as Intel and Microsoft.

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by jstanley on Thursday August 23, 2018 @06:27AM (#17826050)
It has actually been perfectly viable to escape Intel and (especially) Microsoft for a very long time. Lots of people on HN have done so.

Buy an AMD machine, install Ubuntu, and you're done.

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by moolcool on Thursday August 23, 2018 @09:49AM (#17827198)
>gaming PC

>Ubuntu

Hope he likes Mahjong and Tux Racer

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by btym on Thursday August 23, 2018 @02:22PM (#17829504)
WINE + DXVK can pretty much run any modern game (with varying performance).
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by chrisper on Thursday August 23, 2018 @10:01AM (#17827282)
Have you not heard of Valve's Proton? It's the next best thing!
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by moolcool on Thursday August 23, 2018 @01:36PM (#17829120)
It has potential, but when I want to unwind and fire up a game, the last thing I want to do is deal with the rigmarole of alpha software
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by holtalanm on Thursday August 23, 2018 @11:39AM (#17828137)
yeah.... OpenGL is so far from Dx in terms of performance that it is laughable.
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by SmellyGeekBoy on Thursday August 23, 2018 @05:04AM (#17825703)
> I cannot wait until it becomes viable to escape the toxicity of companies such as Intel and Microsoft.

This has been "viable" for a long time now. Ignore the FUD and just try it for yourself. You might be pleasantly surprised.

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by chrisper on Thursday August 23, 2018 @05:15AM (#17825750)
Especially now with Valve's Proton.
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by theprotocol on Thursday August 23, 2018 @07:25AM (#17826291)
I've been watching this very closely. I think this project will finally tip the scales and make it viable for me (I've had problems with many games when I attempted to switch in the past).
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by LeftTurnSignal on Thursday August 23, 2018 @09:18AM (#17826978)
You probably saw this, but this is a google doc of what games people have tried in proton.

https://docs.google.com/spreadsheets/d/1DcZZQ4HL_Ol969UbXJmF...

i'm pumped to try monster hunter. that game was the only reason I was going to use windows, so hope it runs well

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by harry8 on Thursday August 23, 2018 @04:52AM (#17825650)
You are best placed to make that assessment on your own needs. Know that many of us have done it and it turned out to be easier than we thought it would be. Good luck with the analysis!
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by ReverseCold on Thursday August 23, 2018 @10:18AM (#17827435)
Microsoft's stance on the issue:

Win10 is free* (so it does this) - Professionals who need to override these settings should get Win10 Pro.

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by 0xffff2 on Thursday August 23, 2018 @11:28AM (#17828037)
I have Win 10 Pro. AFAIK it handles updates the exact same way. How do I disable automatic reboots on my Win 10 Pro machine?
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by MadWombat on Thursday August 23, 2018 @11:33AM (#17828076)
Since when is Win 10 free? The Microsoft store seems to indicate $139.
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by dspillett on Thursday August 23, 2018 @06:06AM (#17825975)
> and you won't have surprises

They seem to be getting less aggressive, but I've had my machine reboot with less than half an hour of notice. No notice before leaving the machine, return 30 minute later to find it rebooted. So "just mark every 2nd Tuesday of a month as patch day and never leave your machine(s) unattended on that day and you won't have surprises!".

I've also had (in a recent month) them reboot overnight, aborting long running processes that I had to clean up and restart, after explicitly checking for updates before starting those processes (none being found), and making sure my "active hours" were set such that it shouldn't restart.

Earlier this year I had a patch mid-cycle (not close to the normal patch Tuesday) that caused a reboot too. IIRC it was a flash-for-edge/ie update. An update for a feature I don't use/want and can't remove caused a "random" reboot at an unpredictable time. Ta muchly...

I understand MS wanting to get away from their desktop OS's insecure reputation which is in part caused by people never installing updates meaning that worms and other malware were able to run rampant relatively unchecked, but they seem rather wrong headed about how pushy to be in fixing that.

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by jenscow on Thursday August 23, 2018 @08:56AM (#17826817)
There had been many times I've started in the morning, expecting to work on the results of whatever process I left to run, only to be greeted with an empty desktop.

When I review the update settings, they're as negative as I can make them.

I shouldn't complain too much, sometimes it kindly starts Visual Studio for me, saving me 20 seconds.

It could have asked, or even warned that I'd be wasting my time setting up the nightly job, only for it to be cancelled midway through for little reason.

Basically, it's just a consumer OS, and shouldn't be used for actual work.

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by JoeAltmaier on Thursday August 23, 2018 @09:03AM (#17826871)
My favorite story about that: I worked in furnace optimization, giant electric arc furnaces that use half the electrical capacity of a small town generation plant. These things use 'pencil leads' the width of a child, meters long, that strike an electric spark an inch or two in diameter and 12 inches long, from the probe to the pile of recycled steel in the crucible. Melt it for new steel.

Anyway we had a PC running an optimization on the arc length, probe distance etc to get the best instantaneous coupling, trying to save electricity by putting the energy into the steel (to melt it) instead of burning up the probe, creating heat etc.

One morning the plant called, had run overnight but sometime in the late night the thing stopped adjusting, ran 20 minutes before they noticed without moving the probe or adjusting the current. Just sat there burning up carbon and making heat.

You can see where this was going. Investigated, and the PC had gone into 'power save' mode, suspended the app, gone dark. Leaving the probe at whatever setting it was at.

I estimated at the time, that the power wasted during those 20 minutes was more than all the electricity ever saved worldwide by Windows 'power save' feature. Yes, it would have been better had Microsoft Never Invented Power Save, than to have had that incident.

You can say it was our fault, guy installing didn't remember to disable power save. But still, people do things like that. I prefer to blame the computer.

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by api on Thursday August 23, 2018 @09:46AM (#17827175)
I love this story and it underscores something I've come to believe very strongly as an engineer:

Complexity is evil.

The benefits of adding complexity rarely outweigh the downsides, especially when the "embodied energy" of both creating and maintaining that complexity and the follow-on complexity it adds to other systems is considered. Making things a lot more complex to save energy is usually a wash (or worse) because of the energy you spend creating and maintaining complexity.

Complexity usually creeps into systems as a result of piecemeal solutions to problems, marketing driven feature-itis, or attempts by engineers to be overly clever and show off. The latter is incredibly common in IT and programming.

http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer....

Complexity is evil for efficiency, but it's even more evil for security. The number of states a system can enter is an exponential function of the number of variables and linkages in a system. More complex systems are just exponentially more likely to have vulnerabilities for unavoidable combinatorial reasons. The motive for complexity addition doesn't matter, meaning that complexity increases to mitigate security can easily backfire. Furthermore as systems become more complex they become too big to be analyzed, making it much more likely that major security issues are hiding in plain sight and waiting to be discovered. Black hats always have the advantage here because when you attack a system you get instant feedback about whether your attack worked, while security auditing offers no feedback as to whether or not you've closed all the holes.

Complexity tends to accumulate until systems collapse. Getting rid of it is very hard, since users/customers start depending on every feature and nothing can be removed without breaking something.

The x64 architecture seems to be teetering on the brink. AMD's architecture seems better but we'll see.

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by beavis2 on Thursday August 23, 2018 @09:27AM (#17827052)
I like those stories.

Although in this case, it's possible to disable power saving.

(or have they stopped that, too?)

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by dhimes on Thursday August 23, 2018 @07:57AM (#17826447)
This doesn't work. They can hit on other days too- with no warning.

Maybe best to disconnect from the internet when not using- putting to sleep doesn't do it.

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by blauditore on Thursday August 23, 2018 @02:16AM (#17825006)
Have timing attacks been done successfully in JS? I imagine it's much harder since you have much less low-level control and the engine might impose too much noise. However, wasm is a different story.
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by extrapickles on Thursday August 23, 2018 @02:33AM (#17825065)
Yes, Someone did an ASLR bypass in JavaScript, and a key component was being able to measure time accurately.

https://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pd...

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by josefx on Thursday August 23, 2018 @03:05AM (#17825180)
I think browsers currently have to limit the precision of their built-in timer APIs and they had to kill shared mutable state support for their thread APIs so attackers couldn't implement their own.
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by infinity0 on Thursday August 23, 2018 @02:18AM (#17825013)
web search "spy in the sandbox"
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by xref on Thursday August 23, 2018 @01:55AM (#17824917)
but the sandboxes, think of the inescapable sandboxes!
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by kbenson on Thursday August 23, 2018 @01:58AM (#17824935)
"Many customers" meaning people and orgs running server software on direct hardware. Does your caching or database server run user provided code? Is it accessible to the outside in any way? If not, then maybe it doesn't need the patch.
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by infinity0 on Thursday August 23, 2018 @02:18AM (#17825016)
The article says "Many computer users" not "Many customers". Furthermore when the article mentions "customers" elsewhere we can probably assume it means "Intel customers" which is a much greater subset than the group you're talking about, and which would be probably less than 1% as numerous as the "Many computer users" that run javascript.

lol, javascript

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by kbenson on Thursday August 23, 2018 @11:18AM (#17827960)
> which would be probably less than 1% as numerous as the "Many computer users" that run javascript.

So? Many does not mean most. There's a choice to be made, apply the security patch and accept the performance loss, or don't. Some people may not need to to remain close to as safe as they were previously based on their configuration for some of their systems, and I would guess the number of systems easily numbers in the millions. This is a benefit for those people, and worth mentioning, even if it's not nearly a large a number as the total number of CPUs or customers.

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by infinity0 on Thursday August 23, 2018 @10:21PM (#17832299)
In this case, many does mean most.
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by cosmojg on Thursday August 23, 2018 @04:51AM (#17825646)
Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by kbenson on Thursday August 23, 2018 @11:28AM (#17828035)
Are you trying to imply that because somehow ASLR can't protect you and they show and example in the context of Javascript that somehow that means your Postgres server/service is immediately at risk?

At least, that's all I can think you are trying to imply, because you didn't actually say anything, you just dropped a link. It's hard to have a useful conversation when that happens.

Re:Intel Publishes Microcode Patches, No Benchmarking or Com... by shawn-butler on Thursday August 23, 2018 @03:01AM (#17825164)
My opinion of Bruce Perens just decreased markedly.

Hopefully he will edit this blog post with better advice to the "casual" computer user.