
Microsoft disables Spectre mitigations as Intel’s patches cause instability - tomtoise
http://www.securityweek.com/microsoft-disables-spectre-mitigations-due-instability
======
zingmars
These updates most definitely could've been handled better. I was having a
busy week with exams and I get a call about around 10 machines not booting
(this was before the announcement). Sure enough, last thing everyone reported
was updating. I call the supplier and apparently they have reports of at least
2000 machines (at that moment) that had to be reimaged across the city (from
what I could tell, all were older AMD PCs) because of this dumb update. I was
used to not being to able to trust software, but if I can't trust hardware now
either, farming does suddenly appear much more appealing.

~~~
InvisibleCities
Trust me, if you don't like the idea of your entire livelihood hinging on
weather or not a piece of equipment boots up, farming is NOT the career for
you.

~~~
noiv
I like the idea of Internet Weather. Seems probability of rain is currently
increasing. And so does anticipation of floods and surges.

~~~
saym
Do you think there's a market for "Cloud Meteorologists"?

~~~
platz
Such data lake. Such pastoral, idyllic landscape.

------
tjoff
I lost many hours over this last week. The system was unable to boot and
finally a thread on reddit came to the rescue (
[https://www.reddit.com/r/techsupport/comments/7sbihd/howto_f...](https://www.reddit.com/r/techsupport/comments/7sbihd/howto_fix_inaccessible_boot_device_caused_by/)
).

This actually made the system boot but there are some leftovers being
installed on first boot that I've been unable to disable that also causes the
system to be unable to boot.

So now, the machine is running but as soon as it is restarted we have to re-
image the disk, go through the process of manually removing patches, and then
pray that we don't have a power shortage as we'd have to do everything yet
again on next boot.

I'm not convinced that this patch will solve the issue either, because if this
updates requires a reboot the fix won't be installed if we can't boot. I might
try to install this update from the recovery console see if that works.

Quite frustrating.

~~~
thanksgiving
Speaking of which, why do so many things require reboot to update on Windows?

~~~
beagle3
There is a very fundamental difference between how Unix and Windows view open
files:

On Windows, once the file is open, it is that _filename_ that is open; You
can't rename or delete it; Therefore, if you want to replace a DLL (or any
other file) that is in use, you have to kill any program that uses it before
you can do that; And if it's a fundamental library everything uses (USER32.DLL
COMCTL.DLL etc), the only effectively reliable way to do that is reboot.

On Unix, once you have a handle=descriptor of the file, the name is
irrelevant; You can delete or rename the file, The descriptor still refers to
the file that was opened. Thus, you can just replace any system file; Existing
programs will keep using the old one until they close/restart, new programs
will get the new file.

What this means is, that even though you don't NEED to restart anything for
most upgrades in Unix/Linux, you're still running the old version until you
restart the program that uses it. Most upgrade procedures will restart
relevant daemons or user programs, or notify that you should, (e.g. Debian and
Ubuntu do).

You always need a reboot to upgrade a kernel (kernel-splice and friends not
withstanding), but otherwise it is enough in Unixes to restart the affected
programs.

~~~
mehrdadn
> On Windows, once the file is open, it is that filename that is open; You
> can't rename or delete it;

This is wrong... there's no clear-cut thing like the "file name" or "file
stream" that you can specify as "in-use". It depends on the specifics of how
the file is opened; often you can rename but not delete files that are open.
Some (but AFAIK not all) in-use DLLs are like this. They can be renamed but
not deleted. And then there's FILE_SHARE_DELETE which allows deletion, but
then the handle starts returning errors when the file is deleted (as opposed
to keeping the file "alive").

To make it even more confusing, you can pretty much always even create
hardlinks to files that are "in use", but once you do that the new name cannot
be deleted unless the old name can also be deleted (i.e. they follow the same
rules). This should also make it clear that it's not the "name" that's in use,
but the "actual file" (whatever that means... on NTFS I'd suppose it
corresponds to the "file record" in the MFT).

The rule that Windows always abides by is that _everything that takes up space
on the disk must be reachable via some path_. So you can't delete in-use files
entirely because then they would be allocated disk space but unreachable via
any path.

> What this means is, that even though you don't NEED to restart anything for
> most upgrades in Unix/Linux, you're still running the old version until you
> restart the program that uses it.

What I expect it also means is that you'll get inconsistencies when doing
inter-process communication, since they'll be using different libraries with
potential mismatches. Is this correct? Because it seems to me that the Windows
method might be less flexible but is likely to be more stable, since there's a
single coherent global view of the file system at any given time.

~~~
tialaramex
Yes, in principle what you've said about the Unix approach here is correct, if
you upgrade one half of a system and not the other half and now they're
talking different protocols, that might not work.

But keep in mind that if your system can't cope with this what you've done
there is engineer in unreliability, you've made a system that's deliberately
not very robust, unless it's very, very tightly integrated (e.g. two sub-
routines inside the same running program) the cost savings had better be
_enormous_ or what you're doing is just amplifying a problem and giving it to
somebody else, like "solving" a city's waste problem by just dumping all the
raw sewage into a neighbouring city's rivers.

Now, the "you can't delete things because then the disk space is unreachable"
argument makes plenty of sense for, say, FAT, a filesystem from the 1980s.

But (present year argument) this is 2018. Everybody's main file systems are
journalled. Sure enough, both systems _can_ write a record to the journal
which will cause the blocks to be freed on replay and then remove that journal
entry if the blocks actually get freed up before then. The difference is that
Windows doesn't bother doing this.

~~~
mehrdadn
Aaaaaand here comes the Linux defending! OK...

> But keep in mind that if your system can't cope with this what you've done
> there is engineer in unreliability

It's weird that you're blaming my operating system's problems on _me_. "My
system" is something a ton of _other people_ wrote, and this is the case for
pretty much every user of every OS. I'm not engineering anything into (or out
of) my system so I don't get the "you've made a system that [basically,
sucks]" comments.

> [other arguments]

I wasn't trying to go down this rabbit hole of Linux-bashing (I was just
trying to present it as as objective of a flexibility-vs.-reliability trade-
off as I could), but given the barrage of comments I've been receiving: I
don't know about you, but it happens more often than I would like that I
update Linux (Ubuntu) and, lo and behold, I can't really use any programs
until I reboot. Sometimes the window rendering gets messed up, sometimes I get
random error pop-ups, sometimes stuff just doesn't run. I don't get _why_ it
happens in every instance, and there might be lots of different reasons in
different instances. IPC mismatch is my best guess for a significant fraction
of the incidents. All I know is it happens and it's less stable than what you
(or I) would hope or expect. Yet from everyone's comments here I'm guessing I
must be the only one who encounters this. Sad for me, but I'm happy for you
guys I guess.

~~~
rlpb
> ...but it happens more often than I would like that I update Linux (Ubuntu)
> and, lo and behold, I can't really use any programs until I reboot...

Ubuntu developer here. This doesn't happen to me in practice. Most updates
don't cause system instability. I rarely reboot.

Firefox is the most noticeable thing. After updating Firefox (usually it's a
security update), Firefox often starts misbehaving until restarted. But I am
very rarely forced to restart the login session or the entire system. I
should, to get updates to actually take effect, but as a developer I'm usually
aware of the specifics, so I can afford to be more selective than the average
user.

Are you sure you aren't comparing apples to oranges here, and are actually
complaining about the stability of updates while running the development
release, which involves ABIs changing and so forth?

~~~
mehrdadn
Development release? Currently I'm on 16.04, and I've never been on a
development release of anything on Ubuntu. I'm just describing the behavior I
usually see in practice (which it seems someone attributed to "D-BUS" [1]).
Obviously the logon session doesn't get messed up if all I'm updating is
something irrelevant like Firefox, but if I update stuff that would actually
affect system components then there's a good chance I'll have to reboot after
the update or I'll start seeing weird behavior. This has generally been my
experience ever since... any Ubuntu version, really. It's almost ironic that
the most robust thing to update in practice is the OS kernel.

[1]
[https://news.ycombinator.com/item?id=16257060](https://news.ycombinator.com/item?id=16257060)

~~~
rlpb
All I can say is that, based on everything I know, that's not the current
experience of the majority of users, so it doesn't seem fair for you to
generalize this to some architectural problem. I don't know if you unknowingly
have some edge case setup or what.

~~~
mehrdadn
Also, FYI, update: apparently I'm not the only person in the world
experiencing this [1].

But we _are_ the only 2 people in the world experiencing this, so never mind.

[1]
[https://news.ycombinator.com/item?id=16257935](https://news.ycombinator.com/item?id=16257935)

------
cesarb
In a related development, there are proposed patches to the Linux kernel (not
yet merged) to blacklist the broken microcode updates:
[https://www.spinics.net/lists/kernel/msg2707159.html](https://www.spinics.net/lists/kernel/msg2707159.html)

That patch disables the use by the kernel of the new IBPB/IBRS features
provided by the updated microcode, when it's of a "known bad" revision. Since
Linux prefers the "retpoline" mitigation instead of IBRS, and AFAIK so far the
upstream kernel (and most of the backports to stable kernels) doesn't use IBPB
yet, that might explain why Linux seems to have been less affected by the
microcode update instabilities than Windows.

Also interesting: that patch has a link to an official Intel list of broken
microcode versions.

~~~
Valmar
> In a related development, there are proposed patches to the Linux kernel
> (not yet merged) to blacklist the broken microcode updates

Linus probably won't pull it until it's truly known to be stable, because of
his attitude towards having decent quality code and not causing needless
system instability.

Without Linus... who knows what would have happened by now.

~~~
cesarb
They are on the "tip" tree
([https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/...](https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/pti)),
so they'll probably be sent to Linus as soon as the merge window opens (Linux
4.15 has just been released, so the merge window should open soon). I expect
these patches to be on 4.16, and also to be backported to the stable releases
(4.15.x and others).

But yeah, upstream Linux kernel development is taking it slow. As far as I can
see, variant 3 mitigations (PTI) are already in, variant 2 mitigations are
partially in (retpoline) and partially not (the microcode dependent ones), and
variant 1 mitigations are still under discussion.

~~~
jerf
"But yeah, upstream Linux kernel development is taking it slow."

Taking it slow seems very appropriate to me. This seems to me to have been a
case of everybody grossly overestimating the short-term portion of the
catastrophe, and underestimating the long term.

In the short term, the only people who were going to be plausibly affected in
the next three to six months are people on shared hosting of some sort where
you may share a server with somebody else's untrusted code, where an
accelerated fix is in order, but also something that can be centrally handled.
I'm not that worried in the next three to six months that my personal desktop
is somehow going to be compromised by either Meltdown or Spectre, and
personally, if I see a noticeable performance issue I may well revert the
fixes (I'm on Linux), because first you have to penetrate my defenses to
deliver anything anyhow, then you have to be in a situation where you're not
going to just use a root exploit, which probably means you're in a sandbox or
something which means it's that much more difficult to figure out how to
exploit this. For most users, uses, and systems, spectre and meltdown aren't
_that_ immediately pressing.

Meanwhile, in the long term this may require basically redesigning CPUs to a
very significant degree; there is no software patch that can fix the
underlying issues. It is difficult to overstate the long term impact of this
class of bugs. IMHO the real problem from the jousting match with Linus and
Intel last week isn't that Intel's patches today aren't quality code, but that
it makes me concerned that they're just going to sweep this fundamental
problem under the rug. As I said in another post on HN, I fully understand
that remediating this is going to be years, and I don't expect Intel to have
an answer overnight, or a full solution in their next "tock". But if they're
not taking this seriously, we have a very large long-term problem. We're only
going to see more leaks in the long term.

~~~
Mister_Snuggles
I read somewhere that people have developed POCs of these using JavaScript. At
minimum, you'll want to keep your browser up to date as there are mitigations
happening there too. Who knew that exposing high precision timers to untrusted
JavaScript would be a bad idea?

Apart from browsers, it's fortunately pretty easy to avoid running code you
don't trust on your devices.

~~~
jerf
What I've seen that the POCs can actually do is not worth running around with
your hair on fire, from what I've seen.

Note I did not say there is _no_ reason to be concerned about Meltdown and
Spectre... just that for most users, uses, and systems, it's not _that_
important. In the next three-to-six months, if you care about security at all,
unless you are already running a tip-top tight operation, your money and
effort is better spent defending against the many already-realistic threats,
rather than worrying about the vector that may someday be converted into a
realistic threat. Meltdown isn't what is going to drag your business to a halt
next week; it's that ransomware that one of your less-savvy employees opened
while mapped to the unbacked-up world-writable corporate share that has all
the spreadsheets your business runs on. At the moment, the net risk of
applying the Meltdown fix comfortably exceeds by several orders of magnitude
the risk that Meltdown itself poses.

And my point is precisely that for most users and uses, that panic was not
justified. Those for whom that is not true (VM hosting companies) already know
they need to be more aggressive. There was no point in pushing out patches
that nearly bricked some computers.

~~~
Mister_Snuggles
I agree with your points. In fact, I made the same argument about removing a
Heartbleed/Spectre-related patch that caused issues for one of our
applications - "the machine doesn't execute any untrusted code, so this patch
isn't strictly necessary."

------
ComodoHacker
>However, Intel does not appear too concerned that the incident will affect
its bottom line - the company expects 2018 to be a record year in terms of
revenue

There is an interesting paradox in our industry. If you pay enough attention
(read: money) to security, you will be late to the market, your costs will be
high and you lose profit. If you don't pay enough attention, you take the
market, get your profits, but your product (be it hardware or software) and
reputation will be screwed later. And worst of all: there's never enough
attention to security.

So by simple logic, an optimal strategy is to forge your product quickly, take
your profits within a [relatively] short period and vanish from the market. I
guess we'll see this strategy executed from IoT vendors when market start to
punish them for their bad sec.

For Intel, that "long period" just happened to be REALLY long.

~~~
_jal
Intel is TBTF. Like the banks but in via different mechanism, they appear to
have reached consequence-immunity by becoming critical infrastructure.

~~~
curun1r
The same could've been said about Microsoft 10-15 years ago. Now, we could
probably get by without them.

Intel may be too big for an abrupt failure, but they can absolutely fail in a
decade-long slide into obscurity.

------
stinos
"Here's a patch" \- "Here's a patch to disable that other patch" \- ...

What's next? Repeat? Sounds like this could turn into a maintainance nightmare
quickly. Also because I've introduced things like that myself in the past, and
that was for normal applications and not a kernel or OS. Somewhere, someday,
there's usually this one exception for which none of your rules hold true and
the thing blows up in your face. Anyway, I'd love to see the actual code for
this. Not a chance probably?

~~~
hishnash
Im really wanding they had more than 6months to do these patches and they did
not bother testing on a good number of systems. Its not like MS + Intel dont
have enough money to buy a few 1000 testing machines and get some testers on
it.

~~~
x0x0
I came here to ask the same thing. How did these folks squander six months?

~~~
peoplewindow
I think Spectre may have appeared later, after Meltdown? Remember the
investigations into what's possible were proceeding in parallel with the
attempted fixes.

Also, CPU design changes take a long time. 6 months may seem a long time from
the perspective of HackerNews node.js type hackers, but it's a bit harder to
patch decades worth of CPU microcode than a website.

~~~
hishnash
Reading over googles project0 page it reads as if they told AMD about the
issues on 2017-06-01 why would they do this if it were meltdown only?

also look at the exploit numbering:

Variant 1: bounds check bypass (CVE-2017-5753) Variant 2: branch target
injection (CVE-2017-5715) Variant 3: rogue data cache load (CVE-2017-5754)

according to
[https://cve.mitre.org/cve/identifiers/](https://cve.mitre.org/cve/identifiers/)
this is sequence based so `Variant 2` was recorded to CVE before v1 and v3.

I get it may take a long time (that is fine even if the patches took a few
more days), what I don't get is that they released it to production (server)
envs seemingly without testing. Surely even rudimentary testing (deploying on
a few 1000 different server platforms for a few hours at least should be
something that Intel does for all microcode updates, after all they are rather
more important than js Node packages as you point out)

~~~
peoplewindow
I haven't heard of microcode updates that hurt stability before. Presumably
the collapse of the embargo caused them to do an accelerated release, skipping
their usual long testing cycle.

------
PerusingAround
I'm amazed on how Intel's stock price still keeps going UP, despite all these
problems... just WOW.

~~~
ggregoire
Do you know someone who is going to stop buying Intel's CPUs?

~~~
tyfon
I know in my company this has indeed resulted in a full stop in buying Intel
and going AMD instead. There is also an active "project" to replace the Intel
servers.

I work in a bank and they are terrified of the possibility of user processes
reading privileged memory. Not necessarily out of actual fear but out of the
insane amount of paperwork this will require to satisfy the auditors that it
is still safe.

Anecdotally, but you asked for "someone" and here is someone :)

~~~
tobyhinloopen
Wasn’t AMD also affected?

~~~
tyfon
Not by Meltdown which enabled user processes to read kernel memory. And as
we've seen in the aftermath, they have not nearly as much trouble with their
patches for Spectre as Intel has had.

------
HugoDaniel
So much for the embargo period. I guess the bsd people were not so wrong after
all. They might as well just had published it as soon as it was found.

~~~
Valmar
Intel has had literally months upon months to test and stabilize their
microcode and kernel-side patches for Meltdown/Spectre... but it seems like
Intel just doesn't give half a shit, if they're having major issues now.

Intel's actions seem to shout that they have cared far more about releasing
Kaby/Skylake X and Coffee Lake in short order, as a response to
Ryzen/ThreadRipper, than actually really digging into fixing their major
security flaws. Their actions speak of them preferring to keep their market
and mindshare over actually fixing any security issues.

Intel is still so deeply entrenched that they likely believe that they can get
away with their lazy approach. They make millions upon millions, if not
billions of dollars ~ why should they give a shit, when their monopoly and
half-hearted attempt at a solution will get them by? Intel is being strangled
by their shitty management, seemingly...

------
tallanvor
By my reading of the article, Microsoft is disabling some mitigations for
Spectre due to instabilities that Intel's microcode update have been causing.

Intel certainly isn't making any friends these days...

~~~
hishnash
I would love to see the message log between MS Apple and Intel on this.

------
notspanishflu
It is not only Microsoft reverting this patch. HP, Dell or Red Hat are doing
that as well.

[https://www.bleepingcomputer.com/news/microsoft/microsoft-
is...](https://www.bleepingcomputer.com/news/microsoft/microsoft-issues-
windows-out-of-band-update-that-disables-spectre-mitigations/)

------
mosselman
So what can I do for my next self-built pc? Get some AMD equipment, or is that
not enough?

~~~
avtar
I'm eyeing Threadripper for my next build but beyond that I'm going to choose
a motherboard vendor based on the level of support they offer in this
scenario. Some observations that I'm making:

* How promptly did they address the issue via official channels, i.e. did they leave users in the dark as they appealed to vendors in their forums (hint: most of them seem to have gone down this route) or did they share updates directly on their official sites, social media accounts, etc.

* Did they provide some estimates as to when users could expect patches?

* How much of their product catalogue were they willing to cover with security updates? Since this is a unique security issue with high impact I would have expected them to cover motherboards at least 4-5 years old.

~~~
ShroudedNight
For those in the market for an X399/TR4 motherboard, have you come to any
conclusions?

~~~
avtar
MSI seems [1] to be fairly proactive right now with patches going back to
several X99 motherboards. Asus for example has so far only committed to
provide updates for two X99 motherboards.

[1]
[https://www.msi.com/news/detail/7yJ7XCklfBXt8mFhG8nkfSurJUz3...](https://www.msi.com/news/detail/7yJ7XCklfBXt8mFhG8nkfSurJUz3q1A6IXPT4QtmCFh1LubZaZoplvysc-5THpt0K3BM1MTYlMvOQ97-Snztbw~~)

------
megaman22
I've not been impressed with my Windows 10 installations of late. All my
machines that don't have the Long Term Servicing Branch have had wild
instabilities and performance issues the past few months - crazy things, like
the task manager taking minutes to launch, and the whole shell periodically
crashing. The Fall Creators Update was so bad I had to wipe and start over on
some boxes. It's not engendering a lot of confidence in their competence of
late.

~~~
dimmuborgir
Creators Updates (1703 / 1709) are the culprits. LTSB (1607) has not been
upgraded to Creators Update yet and it runs like butter.

------
nippples
Gee, if only they had a Linus Torvalds type around to block irresponsible
commits.

~~~
duncan_bayne
They did, once upon a time, after a fashion:

[https://www.joelonsoftware.com/2006/06/16/my-first-billg-
rev...](https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/)

[https://www.wired.com/2002/01/bill-gates-trustworthy-
computi...](https://www.wired.com/2002/01/bill-gates-trustworthy-computing/)

~~~
kyberias
I had to read that billg-review thing one more time. It's such a wonderful
story.

------
Thimothy
I never got them. The last update in my windows is from Dec 2017. My antivirus
is compliant, the registry key correctly set up and yet it refuses to update.

I still haven't had the time to debug it, but I wonder how many people are out
there with their OS silently refusing to update.

~~~
epistasis
I had huge problems with Win 10. Updates wold fail and install again and again
without actually getting installed. Sometimes I would get an opaque error
number but web searches revealed nothing for that number, and it was rare that
I would be able to find even an error number. I don't do Windows, and just
installed it for VR, and didn't spend that much time in Windows, so I would
spend 15-30 minutes looking a month, before realizing I had spent more
debugging time than VR time that week.

After probably 9 months of this, and with Windows doing ever more intrusive
pop overs whenever I launched it for updates that don't take, I wiped all boot
sectors everywhere and installed from scratch. That seemed to work, but it was
incredibly frustrating that the boot process was so buggy as was error
reporting. I've never encountered a situation like it in the past 15 years of
heavy Linux use. Problems there are usually solvable with a couple web
searches, even for extremely obscure kernel bugs with obscure packages.
Windows refused to tell me anything as did the web.

~~~
whywhywhywhy
I built a Windows machine for 3D work and VR just over a year ago, after being
a Mac only user for 15+ years. Honestly my Win 10 experience has been the
total opposite, it's been stable, fast, minimum update nagging. Overall I've
actually been shocked how stable and hassle free the experience has been.

Maybe I just got lucky with the right combination of hardware.

------
speedie
So , Linus was right for cursing at Intel ?

~~~
akerro
UTTER GARBAGE

~~~
dang
Please don't do this here.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
akerro
Dont do what
[https://hn.algolia.com/?query=UTTER%20GARBAGE&sort=byPopular...](https://hn.algolia.com/?query=UTTER%20GARBAGE&sort=byPopularity&prefix&page=0&dateRange=all&type=all)

?

------
ohiovr
My brother was hit by a recent update to Windows 7 that prevented the machine
from booting. He went to Microcenter to buy a hard drive. There were a lot of
people doing the same thing for the same reason when he was there.

~~~
quiq
I don't use the windows side of my machine very often, but decided to update
it last night. Booted fine (OS on SSD), but one of the HDDs with all of the
windows files was corrupted. No go with ntfsfix, chkdsk, partition table
destroyed. Reformatted it as ext4 and windows doesn't get to touch it anymore.
Haven't tested it too much yet but seems to be working fine.

Remember to use backups!

~~~
ohiovr
My brother did have major data loss. And no real backup strategy.

------
shultays
Amount of fuck-up in this whole issue is mind blowing. I am getting more
surprised with every new I get

~~~
dotdi
Intel has been called out by Linus Torvalds several days ago for the crappy
fixes they delivered for GNU/Linux. I would be very surprised if Intel
actually shipped proper fixes for Windows. It's a shame, really.

~~~
watwut
Those were not delivered fixes, that was work in progress that is still work
in progress. And the dude who was "called out" works for Amazon.

~~~
mrmondo
FYI - The “dude” from Amazon worked for Intel for 8 years before joining
Amazon UK just over a year ago.

~~~
numbsafari
The “dude” is also probably working under an insane amount of pressure and
being made to feel like he is somehow responsible or at fault for the whole
situation. Best not to make it personal from the peanut gallery.

~~~
sundarurfriend
> Best not to make it personal from the peanut gallery.

That's a very uncharitable interpretation of your parent comment, which was
simply pointing out his connection and history with Intel.

~~~
FPGAhacker
Are you sure it is not you that has made the uncharitable interpretation?

I read the peanut gallery comment as an agreement that the guy knows what he’s
talking about.

~~~
mrmondo
FWIW - I took it as a somewhat rude reply but hey it’s the internet so no big
deal.

------
bartl
>Intel, AMD and Apple face class action lawsuits over the Spectre and Meltdown
vulnerabilities.

I sure hope Intel will face a class action suit over this botched update. Many
professionals have wasted countless hours dealing with this junk.

------
cjsuk
Not what I wanted to wake up to this morning. I suspect we’re in for a rough
ride for a long time thanks to this mess.

~~~
kzrdude
Your comment is even more fitting today (politics)

------
chrisper
Just checked for Updates, but there don't seem to be any?

~~~
thg
Just in case you, like me, missed the memo where Microsoft said they'd stop
supplying security updates if you have no AV / AV incompatible with the
patches installed. The fix to the former is creating the registry entry
manually.

[https://support.microsoft.com/en-
us/help/4072699/january-3-2...](https://support.microsoft.com/en-
us/help/4072699/january-3-2018-windows-security-updates-and-antivirus-
software)

~~~
morsch
Bizarre.

 _Customers without Antivirus_

 _In cases where customers can’t install or run antivirus software, Microsoft
recommends manually setting the registry key as described below in order to
receive the January 2018 security updates._

~~~
testplzignore
Sounds like Microsoft can't tell the difference between "has AV installed that
will break" and "has no AV installed", which makes sense. It's probably
infeasible to reliably fingerprint all existing AV software.

~~~
Slansitartop
> Sounds like Microsoft can't tell the difference between "has AV installed
> that will break" and "has no AV installed", which makes sense. It's probably
> infeasible to reliably fingerprint all existing AV software.

For something like this, I think best-effort bad-AV detection would have been
best. Seems pretty insane to disable security patching because they can't be
100% certain that you have a compatibly AV.

~~~
anonymfus
Incompatibility here means unbootable state.

~~~
Slansitartop
But it also means that people with perfectly acceptable configurations are
left in an _insecure_ state, without an unexpected magic incantation (a
registry hack) that most probably will never know about.

Disabling security patches is not acceptable in current year without A LOT of
nasty and annoying warnings.

------
mm-vorticesoft
Linus was right

~~~
cm2187
I thought he was angry about the mitigation being disabled by default, not
being unstable.

~~~
icebraining
Nah, it was more than that: _The patches do things like add the garbage MSR
writes to the kernel entry /exit points. That's insane. That says "we're
trying to protect the kernel". We already have retpoline there, with less
overhead._

~~~
rocqua
That was about patches to the linux kernel, not the microcode patches.

~~~
icebraining
Yes, but as far as I know Linus has made no comment on the microcode patches,
so mm-vorticesoft is probably referring to the Spectre patches in general.

~~~
jononor
The microcode patches are binary blobs against a proprietary and secret ISA,
how can anyone comment on their quality?

~~~
mjevans
When I read it I believed that Linus was implying that the suggested
mitigation was so insane that it seemed like Intel MIGHT be hiding how broken
they believed their hardware was with such over-the-top reactions. As well as
indirectly asking if they believed the currently accepted mitigation method
(retpoline) was considered ineffective.

------
debt
I mean, is this an unmitigated disaster on Intel's part? It's like a train
wreck in slow motion.

A part of me feels this stories like this are going to keep getting worse
until Spectre is finally used in the wild.

------
dsign
What a mess!

The day this blew up we rented our first physical server for the express
purpose of running secure critical workloads in unpatched environments. Yes, I
know that there is nothing secure, but not everything we do is running a chunk
of logic uploaded by an attacker, so we will take our chances.

------
hi41
What does the Spectre bug mean for a person planning to buy a new windows
computer? Should I buy an AMD CPU based computer instead of an Intel based
computer?

------
Roritharr
I'm pretty sure these patches were responsible for my notebook crashing
everytime i hooked it up to our Thunderbolt 3 Dockingstations.

------
kuon
Anybody know what is the status of FreeBSD? I googled a bit and found nothing
except "we wait", is it still the case?

------
mehrdadn
Anyone know if people who had disabled the mitigations via
FeatureSettingsOverride = 3 were still affected?

------
mark_l_watson
A more accurate title would be that Microsoft disabled the specter
mitigation’s due to a flawed Intel update, right? I thought this was all
Microsoft’s fault until getting half way through the article.

~~~
giancarlostoro
It's really telling that even Linus Torvalds was not happy with their "fixes"
and now Microsoft. Intel needs to start taking the situation completely
seriously cause their actions don't imply they are.

~~~
segmondy
Intel doesn't care. What choice do we have?

~~~
giancarlostoro
Before Intel Core processors became the standard hot processor I was an AMD
guy. I'm heading back towards that route. This means no Macbook or Surfacebook
for my next development laptop for me. If anyone wants my money they better
build a developer worthy laptop with an AMD processor and a sweet AMD graphics
card. Also AMD is working on providing open source GPU Vulkan drivers.

~~~
AsyncAwait
This one [1] seems like a good choice in terms of performance, but certainly
no MBP in terms of portability.

[1] - [https://www.asus.com/uk/Laptops/ROG-Strix-
GL702ZC](https://www.asus.com/uk/Laptops/ROG-Strix-GL702ZC)

~~~
giancarlostoro
I already have an ASUS ROG laptop so this sounds like I'm sticking to them!
Thank you, was hoping they'd add in AMD.

------
rootw0rm
Ugh, is this the cause of the weird bugchecks I've been having this week? Just
gave myself 64gb page file and enabled full memory dumps so I could track it
down in WinDbg. I always forget something on fresh installs...

------
IanSanders
Meanwhile Intel stock is at 5 year highest

