Intelov "TLB"

[Sam633]

Izgleda da je i Intel dobio svoj, štonobisereklo, "TLB bug".

Pominje se na više mesta, obaranje performansi između 5% i 50%, negde i više u zavisnosti od scenarija.

Neki link-ovi od mnogih:

Intel bug incoming

The mysterious case of the Linux Page Table Isolation patches

Sve je pod embargom do 4.1.2018. u 13:00.

Xen Security Advisories

U svakom slučaju, biće veselo.

Jako veselo.

 

[Sam633]

'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign

 

[SlavenK]

Ne vredi, moram da pređem na amd

 

[Sam633]

 

[MasterBlaster]

Da li neko zna da li ovaj bug utice na gaming performanse ? I da li utice na starije intel procesore ? Moj drug ima Intelov procesor pa ga zanima ? Nije novije generacije tako da... Ima li sanse da ga ovo zaobidje ? Posto ce sigurno da skine update kad ga budu izbacili ,nebi se igrao sa privatnoscu !

 

[Sam633]

Intel Responds to Security Research Findings

Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.

 

[Sam633]

LKML: Linus Torvalds: Re: Avoid speculative indirect calls in kernel

From Linus Torvalds <>
Date Wed, 3 Jan 2018 15:51:35 -0800
Subject Re: Avoid speculative indirect calls in kernel

On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen <[email protected]> wrote:
> This is a fix for Variant 2 in
> Project Zero: Reading privileged memory with a side-channel
>
> Any speculative indirect calls in the kernel can be tricked
> to execute any kernel code, which may allow side channel
> attacks that can leak arbitrary kernel data.

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

- Intel never intends to fix anything

OR

- these workarounds should have a way to disable them.

Which of the two is it?

Linus

https://s21.q4cdn.com/600692695/files/doc_presentations/2018/Side-Channel-Analysis-Security.pdf

NOT a result of product errata; processors are operating to specification

Mitigations include updates to system software, firmware and future hardware

 

[Sam633]

Intel® Product Security Center INTEL-SA-00088

• Intel® Core™ i3 processor (45nm and 32nm)
• Intel® Core™ i5 processor (45nm and 32nm)
• Intel® Core™ i7 processor (45nm and 32nm)
• Intel® Core™ M processor family (45nm and 32nm)
• 2nd generation Intel® Core™ processors
• 3rd generation Intel® Core™ processors
• 4th generation Intel® Core™ processors
• 5th generation Intel® Core™ processors
• 6th generation Intel® Core™ processors
• 7th generation Intel® Core™ processors
• 8th generation Intel® Core™ processors
• Intel® Core™ X-series Processor Family for Intel® X99 platforms
• Intel® Core™ X-series Processor Family for Intel® X299 platforms
• Intel® Xeon® processor 3400 series
• Intel® Xeon® processor 3600 series
• Intel® Xeon® processor 5500 series
• Intel® Xeon® processor 5600 series
• Intel® Xeon® processor 6500 series
• Intel® Xeon® processor 7500 series
• Intel® Xeon® Processor E3 Family
• Intel® Xeon® Processor E3 v2 Family
• Intel® Xeon® Processor E3 v3 Family
• Intel® Xeon® Processor E3 v4 Family
• Intel® Xeon® Processor E3 v5 Family
• Intel® Xeon® Processor E3 v6 Family
• Intel® Xeon® Processor E5 Family
• Intel® Xeon® Processor E5 v2 Family
• Intel® Xeon® Processor E5 v3 Family
• Intel® Xeon® Processor E5 v4 Family
• Intel® Xeon® Processor E7 Family
• Intel® Xeon® Processor E7 v2 Family
• Intel® Xeon® Processor E7 v3 Family
• Intel® Xeon® Processor E7 v4 Family
• Intel® Xeon® Processor Scalable Family
• Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
• Intel® Atom™ Processor C Series
• Intel® Atom™ Processor E Series
• Intel® Atom™ Processor A Series
• Intel® Atom™ Processor x3 Series
• Intel® Atom™ Processor Z Series
• Intel® Celeron® Processor J Series
• Intel® Celeron® Processor N Series
• Intel® Pentium® Processor J Series
• Intel® Pentium® Processor N Series

 

[Sam633]

Opis Meltdown-a:

What’s behind the Intel design flaw forcing numerous patches?

Primena Meltdown-a:


Možebiti performanse nakon BIOS i OS patch-a:

 

[Sam633]

 

[Sam633]

 

[Sam633]

 

[Sam633]

Rezultat patchovanog BIOS-a (microcode), na sopstvenu ruku. Još jednom, vrlo jasno, na sopstvenu ruku.

http://bbs.ngacn.cc/read.php?tid=13199794

Pre:

Spojler

Izem ti XenForo i ko ga izmisli. Ova slika ide kao link:
http://img.ngacn.cc/attachments/mon_201801/06/9aQ5-7mcrZ1nT3cS12w-nm.png

Posle:

Spojler

 

[ThePocetnik]

A da li je toliko pad samo kada se instalira patch za Windows 10, posto se spominje da patch selektivno aktivira ono sto treba.

 

[Edgeman]

Koliko će efikasno da urade te patcheve. Intel je imao pola godine da smisli način kako ovo da zakrpi a da ne dođe do prevelikog pada u performansama.
Pitanje je da li su uspeli u tome.
Postavlja se pitanje ako CPU-u u cloud sistemimа udare u palfon onda će biti potrebno više takvih sistema za isti load. I koje je rešenje?
Isti ovi "topivi" procesori jer nema novih.

Avetinja na delu
Primer u C-u.
ErikAugust/spectre.c

 

[Sam633]

A da li je toliko pad samo kada se instalira patch za Windows 10, posto se spominje da patch selektivno aktivira ono sto treba.

Za sada, takozvani OS patch, donosi zakrpu za Meltdown i čini se da nije toliko pogubna za krajnjeg korisnika. Osim u pogledu velikih I/O poslova. Ista zakrpa služi i za Spectre, barem za jednu varijantu od dve, ako se ne varam. Ali OS zakrpa za Spectre ne radi, bez novog mikrokoda za CPU, koji opet verovatno donosi neko smanjenje performansi. I opet u pogledu I/O poslova.

Treba shvatiti da je sve ovo na samom začetku, bez obzira što su svi imali vremena.

Avetinja na delu
Primer u C-u.
ErikAugust/spectre.c

Upravo tako.

 

[hedgehog]

Azurirajte pretrazivace Meltdown, Spectre Can Be Exploited Through Your Browser
Firefox Browser Update Out Now With Fixes for Meltdown, Spectre Attacks

 

[Sam633]

ASUS Motherboards Microcode Update for Speculative Execution and Indirect Branch Prediction Side Channel Analysis Method

 

[Sam633]

Linux-Kernel Archive: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

Spojler

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation
From: Linus Torvalds
Date: Sun Jan 21 2018 - 16:36:05 EST

• Next message: Jes Sorensen: "Re: [PATCH] rtl8xxxu: Fix trailing semicolon"
• Previous message: Heiko Stübner: "Re: [PATCH 0/2] Input: auo-pixcir-ts: Adjustments for two function implementations"
• In reply to: David Woodhouse: "Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation"
• Next in thread: David Woodhouse: "Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Sun, Jan 21, 2018 at 12:28 PM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote:
>> All of this is pure garbage.
>>
>> Is Intel really planning on making this shit architectural? Has
>> anybody talked to them and told them they are f*cking insane?
>>
>> Please, any Intel engineers here - talk to your managers.
>
> If the alternative was a two-decade product recall and giving everyone
> free CPUs, I'm not sure it was entirely insane.

You seem to have bought into the cool-aid. Please add a healthy dose
of critical thinking. Because this isn't the kind of cool-aid that
makes for a fun trip with pretty pictures. This is the kind that melts
your brain.

> Certainly it's a nasty hack, but hey â the world was on fire and in the
> end we didn't have to just turn the datacentres off and go back to goat
> farming, so it's not all bad.

It's not that it's a nasty hack. It's much worse than that.

> As a hack for existing CPUs, it's just about tolerable â as long as it
> can die entirely by the next generation.

That's part of the big problem here. The speculation control cpuid
stuff shows that Intel actually seems to plan on doing the right thing
for meltdown (the main question being _when_). Which is not a huge
surprise, since it should be easy to fix, and it's a really honking
big hole to drive through. Not doing the right thing for meltdown
would be completely unacceptable.

So the IBRS garbage implies that Intel is _not_ planning on doing the
right thing for the indirect branch speculation.

Honestly, that's completely unacceptable too.

> So the part is I think is odd is the IBRS_ALL feature, where a future
> CPU will advertise "I am able to be not broken" and then you have to
> set the IBRS bit once at boot time to *ask* it not to be broken. That
> part is weird, because it ought to have been treated like the RDCL_NO
> bit â just "you don't have to worry any more, it got better".

It's not "weird" at all. It's very much part of the whole "this is
complete garbage" issue.

The whole IBRS_ALL feature to me very clearly says "Intel is not
serious about this, we'll have a ugly hack that will be so expensive
that we don't want to enable it by default, because that would look
bad in benchmarks".

So instead they try to push the garbage down to us. And they are doing
it entirely wrong, even from a technical standpoint.

I'm sure there is some lawyer there who says "we'll have to go through
motions to protect against a lawsuit". But legal reasons do not make
for good technology, or good patches that I should apply.

> We do need the IBPB feature to complete the protection that retpoline
> gives us â it's that or rebuild all of userspace with retpoline.

BULLSHIT.

Have you _looked_ at the patches you are talking about? You should
have - several of them bear your name.

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.

So somebody isn't telling the truth here. Somebody is pushing complete
garbage for unclear reasons. Sorry for having to point that out.

If this was about flushing the BTB at actual context switches between
different users, I'd believe you. But that's not at all what the
patches do.

As it is, the patches are COMPLETE AND UTTER GARBAGE.

They do literally insane things. They do things that do not make
sense. That makes all your arguments questionable and suspicious. The
patches do things that are not sane.

WHAT THE F*CK IS GOING ON?

And that's actually ignoring the much _worse_ issue, namely that the
whole hardware interface is literally mis-designed by morons.

It's mis-designed for two major reasons:

- the "the interface implies Intel will never fix it" reason.

See the difference between IBRS_ALL and RDCL_NO. One implies Intel
will fix something. The other does not.

Do you really think that is acceptable?

- the "there is no performance indicator".

The whole point of having cpuid and flags from the
microarchitecture is that we can use those to make decisions.

But since we already know that the IBRS overhead is huge on
existing hardware, all those hardware capability bits are just
complete and utter garbage. Nobody sane will use them, since the cost
is too damn high. So you end up having to look at "which CPU stepping
is this" anyway.

I think we need something better than this garbage.

Linus

• Next message: Jes Sorensen: "Re: [PATCH] rtl8xxxu: Fix trailing semicolon"
• Previous message: Heiko Stübner: "Re: [PATCH 0/2] Input: auo-pixcir-ts: Adjustments for two function implementations"
• In reply to: David Woodhouse: "Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation"
• Next in thread: David Woodhouse: "Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

 

[drfedja]

A da li je toliko pad samo kada se instalira patch za Windows 10, posto se spominje da patch selektivno aktivira ono sto treba.

A kako ćeš da menjaš patch za mikrokod u letu ? Ha ?

 

[Sam633]

Postoji mogućnost za to preko:

mcupdate_genuineintel.dll

Nego:

SgxSpectre Attack Can Extract Data from Intel SGX Enclaves

 

[Sam633]

Security | DMA | Hacking: Total Meltdown?

 

[Sam633]

Intel: No Microcode Updates for some older CPUs

Lista procesora koji će izvisiti za (dalji) MCU (microcode update):

- Bloomfield
- Bloomfield Xeon
- Clarksfield
- Gulftown
- Harpertown Xeon C0
- Harpertown Xeon E0
- Jasper Forest
- Penryn/QC
- SoFIA 3GR
- Wolfdale C0
- Wolfdale M0
- Wolfdale E0
- Wolfdale R0
- Wolfdale Xeon C0
- Wolfdale Xeon E0
- Yorkfield
- Yorkfield Xeon

 

[Sam633]

Eight new Spectre Variant Vulnerabilities for Intel Discovered - four of them critical

Malo šale:

Spojler

 

[Sam633]

Intel Has to Delay Patches for new Spectre-NG Vulnerabilities

Meltdown Patch in Windows 10 Can Be Bypassed