Intel bug incoming.

nimmr

New Member

Thanks: 2
Messages: 3

Unfortunately, it is. For now, just be careful what you run or run on AMD hardware. There's a lot of rework in the way the kernel handles paging to resolve this issue. It's really tricky code that hasn't been touched it years.
Yeah I can imagine it being very tricky to fix. Why are you specifically mentioning AMD here? Are the microcode updates from Intel enough? I thought they where withdrawed because they caused reboots.
 

Maelstorm

Well-Known Member

Thanks: 129
Messages: 326

Yeah I can imagine it being very tricky to fix. Why are you specifically mentioning AMD here? Are the microcode updates from Intel enough? I thought they where withdrawed because they caused reboots.
There are two flaws... Spectre allows a hosted system running inside a virtual machine to read information from the hypervisor. This affects pretty much any CPU out there. Meltdown affects *ONLY* Intel CPUs (and some ARM chips) and it allows arbitrary reading of physical memory.

Of the two, Spectre is the least dangerous, harder to exploit, and can be mitigated by software. The big concern is web browsers, but most of the vendors have already issued updates. Meltdown is very dangerous because you can read any physical memory, even memory belonging to the kernel or other processes using a side-channel attack. It's easily exploitable, but it is also easily remedied by software using kernel page table isolation (KPTI). This one does not affect AMD CPUs and therefore AMD chips will not suffer the performance hit that Intel chips do.

The Linux folk had a different name for KPTI: Forcefully Unmap Complete Kernel With Interrupt Trampolines, also known as FUCKWIT, which I think is actually appropriate, but I don't develop for Linux.
 

nimmr

New Member

Thanks: 2
Messages: 3

Pretty hard for us to "be careful". We run PHP websites for customers in jails, and these webapps are regularly hacked by automated scripts because they themselves handle the framework upgrades (I only upgrade the platform stack). This is a nightmare for me to say the least, and having to live with much of this until late june is making it much worse.
 

Snurg

Aspiring Daemon

Thanks: 326
Messages: 794

nimmr

I do not believe that FreeBSD will get more acceptance at hoster companies.
This is indeed a genuine nightmare for every hoster.
Sort of meltdown of another kind.

You might consider migrating to DragonFly BSD, too, just to sleep better the next half year.
The DragonFly chief developer took his job seriously. He fixed the issue in just two days.
After Intel released the new microcodes on Jan 9, he posted an impact analysis next day already.

And when I look at the priorities the FreeBSD developers have, I can just shake my head in disbelief.
(Just see yourself the threads which were closed the last days, as I do not dare to be more explicit in fear of being banned and this thread closed also.)
 

Dendros

New Member


Messages: 10

I'm confused about something. How exactly is Meltdown mitigated? From what I read, fixing Meltdown requires a kernel modification (KPTI or its equivalent) and a microcode update from Intel. Did I understand it correctly? I ask because if it's so and coupling this with what someone on this thread said (that Intel will not release microcode updates for older CPUs), it would mean that Meltdown is in fact unmitigable for older CPUs due to missing microcode updates. That's worrying for those that have and use older machines.
 

MarcoB

Well-Known Member

Thanks: 92
Messages: 334

That would be 11.2-RELEASE. I wouldn't be suprised if that is released earlier than planned. Or maybe they release a 11.1.1?
 

Snurg

Aspiring Daemon

Thanks: 326
Messages: 794

Is more work to be done? I guess the question I should ask is in what release of RELEASE will FreeBSD be fully patched?
Yes, there is probably more work to be done. Trampolines have not been mentioned in the revision note, only table isolation.
I guess this is the reason why FreeBSD didn't publicly announce that kernel revision as "fix" like OpenBSD and Linux, where trampolines and retpolines are already implemented.

Furthermore, there are at least two serious bugs in the FreeBSD microcode uploader.
I will do some PRs at the weekend, as my attempt to alert the devs via mailing list was unsuccessful.
There I will also post a patch for the first of these bugs which is very simple (fix use of uninitialized register).
The second bug involves incorrect usage of reserved register bits, would require larger changes in devcpu-data, of which I am not in the mood to do, as devcpu-data is obsolete anyway due to Intel's microcode file format change. Personally I'll use my own updater which uses the new microcode format and doesn't have these bugs.
(As long as Intel still provides the microcodes in the legacy format in addition to the new format, devcpu-data can still be used).
 

Maelstorm

Well-Known Member

Thanks: 129
Messages: 326

So why wasn't is announced? More work to be done?

Yes, there is probably more work to be done. Trampolines have not been mentioned in the revision note, only table isolation.
I guess this is the reason why FreeBSD didn't publicly announce that kernel revision as "fix" like OpenBSD and Linux, where trampolines and retpolines are already implemented.
I guess that answers that question. The thing about KPTI is that it makes it way harder for an attacker to locate where things are in memory. The Meltdown bug allows arbitrary reading of physical memory. By being able to read kernel memory, an attacker can locate the memory space of any process running on the machine. With that in mind, reading the process memory of something like sshd can reveal crypto keys and such. For a browser, passwords to your bank account. Other scenarios come to mind.
 

Snurg

Aspiring Daemon

Thanks: 326
Messages: 794

So there only remain two production candidates (Coffee Lake), all others are either fixed or stopped.
But no new microcode download since Mar 12 yet :(
 

bookwormep

Active Member

Thanks: 109
Messages: 192

lebarondemerde ..you should be given extra vote of thanks as the original author of this post/thread, making us aware of the Intel bug fiasco..and hopefully remedy!
 

Crivens

Moderator
Staff member
Moderator

Thanks: 623
Messages: 1,570

To quote a good SciFi:
"There is always hope"
"Only because nobody has figured out how to kill it - yet".

I would not hope too much on a remedy, intel will do what is profitable, not what is right (unless that is equal).
 

Trihexagonal

Daemon

Thanks: 549
Messages: 1,074

Most the CPUs listed above are oldies that went on sale between 2007 and 2011, so it is likely few remain in normal use.

http://www.theregister.co.uk/2018/04/04/intel_spectre_microcode_updates/
Says who? That encompasses all 8 of my laptops, 7 of which use Intel processors and 4 of those were business lease returns. So maybe less people are using them, but that's spin in my book.


I recently noticed that NoScript, that browser extension I'm always ranting about, is making the following claim on their website:
NoScript's unique whitelist based pre-emptive script blocking approach prevents exploitation of security vulnerabilities (known, such as Meltdown or Spectre, and even not known yet!) with no loss of functionality...

https://noscript.net/
I thought I had seen a github page that has a test for the vulnerabilities linked to here, but I don't now. (A lot of those tests you need to allow scripting for.}

While looking for other tests I did see where one claimed:
To exploit the vulnerabilities, attackers must get you to execute program code on your computer.

https://www.ashampoo.com/en/usd/pin/1304/security-software/spectre-meltdown-cpu-checker]
So is that really all there is to it? Not allowing scripting to run when you surf the web?

It sounds stupid to even ask if it's that simple, and admittedly I haven't been following this like I should, but I already block scripting.
 
Top