Patch your things, and be prepared for some possible slowdowns in specific workflows as a result.

https://spectreattack.com for the easy to digest tech details/central location for news

https://xkcd.com/1938/ for a good summary

Make sure to thank your overworked IT professional this week. It's a mess out there in some environments as a result of these issues being broadcast by way of juvenile behavior before an NDA expired.

What I found to be most troubling is the possibility that this could get used for breaking out of a VM and reading the memory of the host machine. If true, an attacker could simply rent space on a rackmount server and run whatever code they wanted, so that it was able to retrieve kernel memory from the other VMs on the same host. It's only mentioned in passing here, and it seems like speculation by the way they're phrasing it. But scary.

Yep, VM issues among the many terrifying realities of this, and I've seen a VirtualBox proof of concept somewhere that I'll edit in later. The one that topped that for me was Firefox and IE6, err Chrome being vulnerable and leaking passwords via Javascript due to one of the flaws. Definitely upgrade your browser if you haven't yet.

On the plus side for the cloud, those folks know how to patch quickly and with minimal disruption. Was watching AWS alerts go out around 9PM PST on the 3rd announcing emergency updates with 2 hours notice. I didn't watch Azure as closely or other clouds, but saw hints of similar actions. I also forgot to set up a timelapse of Amazon HQ to catch how many more office lights were on after hours compared to average.

Meanwhile, folks still hosting their own stuff, especially on old Windows systems, have to wait for AV vendors to set a special registry key, to ensure the patch won't blue screen loop the boxes. Win 10 and Win 2016 users with only Microsoft Security Essentials were the only ones who could safely deploy when Microsoft also published their patches under emergency conditions. Microsoft's legacy continues to hold then back unfortunately.

Apple is still sorting out their status, with anyone on macOS 10.13.2 or iOS 11.2 being okay, and patched secretly in December. It's still unclear if an up to date 10.12 or 10.11 Mac is vulnerable under these 3 flaws. It's also unclear when Safari will be fully validated and fixed if vulnerable in the same way other browsers were.

Linux, well, not going to discuss that trampoline mess currently. Not a surprise their work was what set off the emergency scramble in the industry, and currently keeping me busy at work.

BSDs and other OSes, I've not dug into beyond seeing statements FreeBSD was aware and on the 3rd was still respecting the NDA some other folks disregarded.

What continues to intrigue me from a CPU architecture standpoint is why some ARM variants were also hit with Meltdown specifically, both a Cortex core, and some of Apple's cores. AMD dodged that one likely due to their past of acquiring DEC Alpha engineers who designed their memory pieces, though embarrassingly AMD also had a disclosed flaw in their TPM setup, oops. The good news is, Itanium seems to remain unaffected by all three of these when running in pure IA64 modes. It's a shame the industry told Intel they weren't willing to switch to a better architecture to break the 4GB RAM barrier.

Oh, this is on my reading list for the weekend, skimming it revealed some more good explanations of the flaws: https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

I'll caution everybody here that any given "not vulnerable" statement should be taken with many grains of salt. "Not vulnerable yet" is a better way to approach the problem, since there will be many new variations on these attacks discovered over time. AMD isn't necessarily safe.

Following the panicked rollout of info, PR spin, independant discoveries by those not previously disclosed, and theories of how bad it could be in real time was interesting. Revealed a lot about the different folks involved and what signals to follow. The Intel vs AMD PR releases reminded me of the good ole days of their early x86 design competition.

Someone guessed (likely well) that Spectre is going to change and be an issue for the entire field for the next ten years. At least. And it could disrupt some companies or systems folks previously thought were too big and solid to fall. I'll be curious to see the advancements from this too. The old Pentium FDIV bug helped lead to CPU microcode updates instead of having to fully scrap flawed silicon.

What's going on here is that these speculative execution attacks are a new generalization of timing attacks, which have been known for decades. The fact that code which wasn't executed can influence observable timing artifacts is crazy, but like all things crazy, once you get over the crazy it's just a new tool in the toolbox.

Google has already come up with a completely insane way of generating computed branches that will try to keep the CPU from speculating around it, which is itself sufficiently crazy that there's already a StackOverflow page that tries to explain it.

My gut reaction is that software patches for hardware problems are stopgap measures. This reminds me of an ancient MIPS bug where a branch delay slot, if it was on a different memory page that took a page fault, wouldn't actually get executed. The workaround was to hack the compiler not to split branch instructions and their delay slots across page boundaries, while the proper answer was to fix the damn hardware.

The problem here, unlike the aforementioned MIPS bug, is that there's a clear definition of what it means to fix the MIPS bug. Here's an input that causes non-compliant output. Fix it. With these speculative execution attacks, the only definition that really holds up is something called "non-interference", which is to say that nothing that happens "over there" can have any observable impact "over here" (for suitable definitions of "there" and "here"). When you want to encompass timing issues, in a world where CPUs play all kinds of optimization games that have side-effects in the cache, the TLB, the branch predictor, and so forth, you've got no hope of having real non-interference.

I've seen several security people using phrases like "this will be with us for another decade", and I don't doubt it.

Microsoft is being fairly transparent and has revealed the peformance impacts for Windows client OS users:
https://www.theverge.com/2018/1/9/16868290/microsoft-meltdown-spectre-firmware-updates-pc-slowdown

Essentially Win 10 users won't notice much, but Win 7 and 8 users on slightly older processors will likely notice slowdowns. Only solution there is to upgrade to Win 10. Seems some low level kernel font rendering optimizations in older Windows are really harmed by the fixes/mitigations.


Apple folks, patches went out yesterday on both iOS and macOS for further Spectre mitigations. It's still unclear on what risk 10.11 and 10.12 macOS users are facing, and some patches did go out to those systems too. https://support.apple.com/en-us/HT208401

Interesting. The conspiracy theorist in me wonders if that's merely Microsoft spinning this fiasco into a way to force more people to upgrade, since one of Microsoft's problems is that Win7 was so good that many people aren't bothering to upgrade it.

There are real reasons for the earlier versions being slower. Lots of graphics work, including rendering fonts, was done in the kernel in the earlier versions.

It is that jump from user space to kernel space and back that is now significantly more expensive. If you are rendering the text in the UI by calling out to the kernel that is going to have a much bigger impact than if you aren’t.

Not likely a practical thing to patch either.

One of the reasons for Windows 10 not being as slow, it that MS only permits it to be installed on (or is that merely "shipped with"?) quite recent processors. So it's faster to begin with (newer CPUs), and those newer CPUs have some features that help reduce the overhead of the bug workarounds.

Nothing of the sort from what I've seen.

Windows 7 also wasn't that good either kernel wise. It did bring in some changes Microsoft started with Longhorn, and they definitely patched a lot of holes between Vista and 7, but they never really got time to properly iterate after breaking down their internal silos. In 2018, that kernel looks absolutely ancient and is holding back performance on modern machines. Microsoft finally cut some legacy, and stopped trying to patch ancient kernels to take advantage of modern processors. Their only other viable choice in my mind was to hire a second kernel team, and let them focus on legacy improvements while allowing the main team to keep pushing Win10/Server2016 forward. And yes, please let them keep going, the work they did to enable WSL is amazing and useful, as well as using NVMe drives properly.

Back during the Vista development for example, the team building the new start menu had to wait 3 months to get new code from the kernel team to support them. If it was buggy, another 3 months would go by before the first attempted fix would land from the kernel team. From what I understand, this improved a little for some teams with 7 development, but not enough.

Windows 8/8.1 pushed the kernel more, but most of the efforts there went into the tablet stuff and not making the kernel/user swaps more efficient. At the time, that decision made sense for sure.

Windows 10 now, it's on a good path. Microsoft has the ability to patch the kernel in major ways on consumer machines every 6 months. Compare that to internal teams not getting updates every 3 months 10 years ago. The amount of effort MS had to go through to drag Windows into modern development practices is impressive, and they have my respect for enduring it while their users spin conspiracy theories

Ok, how's the rest of the industry doing on kernel updates? Well, Apple's been able to ship updates to it to customers reliably, since, umm, March 2001 when OS X launched. Linux, it is the kernel, and is hyper optimized to deliver updates. We all benefitted from that setup with prior community kernel patches and Mr Lord's Hijack work to unify them. To tie this back to Windows 7 kernel example, I highly doubt it's worth the effort to try and build a new empeg-car that can include current Hijack releases seamlessly, and instead start fresh with todays Linux kernels. I remember when kernel 2.2 was new and shiny, and a 2.4 future was opening up. Now those numbers seem like ancient memories, and ancient ways of doing things

Huh? Windows 7 and Windows 10 system requirements are identical. And it's leading to the patches causing further blue screen scenarios, like this one.

I'm guessing your impression may have been from seeing news like this where Microsoft started trying to drop their legacy kernels by not supporting Windows 7 on newer x86 SoC style processors.

Interesting research paper from *checks the calendar* 22 years ago possibly hinting at the trouble to come. https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf

This is giving me flashbacks to so many 90s era architecture discussions.

Ironically one of the reasons that Microsoft are more agile when it comes to delivering updates is thanks to Linus Torvalds;)

They moved the whole Windows development process over from their old internal source control tools to a system based on Linus’s git.

https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-largest-git-repo-on-the-planet/