Processador Vulnerabilidade MeltDown / Spectre (aka Kaiser bug)

[Dark Kaeser]

we were given an opportunity to sit down with Lisa Spelman, VP of Intel’s Data Center Group and General Manager of Xeon Products, about the new processors.

IC: On the roadmap slide we did see mention of Spectre and Meltdown mitigations. (LS: It said hardware security mitigations!) Are we expecting a hardened design?

LS: Yes that is definitely the intent. So you see everything that we learned even ahead of the release of those and starting to work back in changes you would make inside the silicon. So we did software mitigations, then working back to hardware as soon as we could, and we were able to intercept timing for Cascade Lake in order to get it in. That will continue through.

IC: So you are already at a point in the design of Cascade Lake where you could re-architect parts of the core to have the relevant mitigations?

LS: Yes. Ronak (Singhal), one of our lead CPU architects, led that effort. We had to make choices in order to do that. To keep everything on the best case schedule we had to make a choice to intercept and stop tape-ins to make sure that we put this in. So we had to do the engineering work and then get it in. It was our belief that that is what we had to do, and the right decision for our customers in the ecosystem.

https://www.anandtech.com/show/1320...tels-dcg-discussing-cooper-lake-and-smeltdown

 

[Dark Kaeser]

OpenBSD chief slams Intel, says more CPU flaws likely to be found
https://www.itwire.com/security/840...-more-intel-cpu-flaws-likely-to-be-found.html

 

[blaster_00]

E a AMD continua a passar "entre os pingos da chuva" ?

benches phoronix:
https://www.phoronix.com/scan.php?page=article&item=l1tf-foreshadow-xeon&num=1

 

[Dark Kaeser]

Até ver... +e que tirando as diferenças de arquitectura e o modo de funcionamento do front-end dos CPU, parte disto resulta de ir testando métodos semelhantes a outras áreas do CPU, claro que a Intel ter oferecido um "Bug Bounty" apenas faz com que isto acabe por isto acrescentar ainda mais atenções.

Já agora:

Variant 1 is still to be tackled at the OS level, with variants 3a and 4 through firmware and OS updates. Variants 2, 3, and 5, will be solved in hardware, requiring no extra additions.

So while the new processors have fixes in place, not all of them will be hardware fixes. The firmware fixes might as well be hardware, given that the system will launch with these by default, but the OS fixes will have to be pushed before platforms are released. The non-hardware fixes have the potential for performance regression, however as stated above, the platform as a whole should be at a higher performance level than Skylake.

https://www.anandtech.com/show/13239/intel-at-hot-chips-2018-showing-the-ankle-of-cascade-lake

 

[Nemesis11]

A Intel lançou novo microcode, devido a todos estes problemas de segurança, mas a licença, além de não permitir redistribuição, que faz com que não seja possível colocar o microcode em repositórios de distribuições de Linux, também tem outra pérola. Não permite comparações nem benchmarks.

You will not, and will not allow any third party to (i) use, copy, distribute, sell or offer to sell the Software or associated documentation; (ii) modify, adapt, enhance, disassemble, decompile, reverse engineer, change or create derivative works from the Software except and only to the extent as specifically required by mandatory applicable laws or any applicable third party license terms accompanying the Software; (iii) use or make the Software available for the use or benefit of third parties; or (iv) use the Software on Your products other than those that include the Intel hardware product(s), platform(s), or software identified in the Software; or (v) publish or provide any Software benchmark or comparison test results.

https://perens.com/2018/08/22/new-intel-microcode-license-restriction-is-not-acceptable/
https://www.theregister.co.uk/2018/08/21/intel_cpu_patch_licence/

Começou a fase do desespero.
Alguém na Intel não conhece o "Streisand Effect".

 

[skandal]

Acho piada fabricantes colocarem licenças que provavelmente não são validas em tribunal.

Sai um update de BIOS com esse microcode, ou a Microsoft incluí no W10. Eu não posso fazer benchmarks em casa a comparar? Por alma de quem?

Acho piada quem dá as noticias nunca referir o facto da "clausula" ser potencialmente ilegal.

 

[Nemesis11]

Não sei se é assim tão "limpo" que esta licença não é válida em tribunal. Isto porque, as leis mudam de território para território e esta licença tem o seguinte ponto no fim:

APPLICABLE LAWS. This Agreement and any dispute arising out of or relating to
it will be governed by the laws of the U.S.A. and Delaware, without regard to
conflict of laws principles. The Parties to this Agreement exclude the
application of the United Nations Convention on Contracts for the International
Sale of Goods (1980). The state and federal courts sitting in Delaware, U.S.A.
will have exclusive jurisdiction over any dispute arising out of or relating to
this Agreement. The Parties consent to personal jurisdiction and venue in those
courts. A Party that obtains a judgment against the other Party in the courts
identified in this section may enforce that judgment in any court that has
jurisdiction over the Parties.

https://paste.ubuntu.com/p/z2F3Cj6R8Q/

Por isso, não me admirava que no Delaware, houvesse alguma coisa que permita as clausulas desta licença.

Eu não quero tornar isto numa discussão jurídica, até porque isso nos levaria mesmo muito longe. Eu não acredito que a Intel alguma vez vá processar alguém por quebrar esta licença. O mundo ia-lhes cair em cima. Eu até penso que quando perceberem a borrada que estão a fazer, vão alterar de novo a licença.
Mas não seria preciso processar alguém, para esta licença "assustar" toda a gente. Se a Intel decidir não fazer mais negócios com alguém, por quebra da licença, continuaria a ser terrível para muita gente.

Enfim. As empresas não aprendem com o passado e continuam a fazer os mesmo erros continuamente.

 

[skandal]

Por isso, não me admirava que no Delaware, houvesse alguma coisa que permita as clausulas desta licença.

Então levem-me a tribunal no Delaware, boa sorte

 

[Nemesis11]

Bem, tal como me parecia, a Intel quando se apercebeu que alguém fez borrada ou copy/paste de uma licença qualquer, mudou-a a rapidamente. Nova licença:

Copyright (c) 2018 Intel Corporation.
All rights reserved.

Redistribution.

Redistribution and use in binary form, without modification, are permitted, provided that the following conditions are met:

• Redistributions must reproduce the above copyright notice and the following disclaimer in the documentation and/or other materials provided with the distribution.
• Neither the name of Intel Corporation nor the names of its suppliers may be used to endorse or promote products derived from this software without specific prior written permission.
• No reverse engineering, decompilation, or disassembly of this software is permitted.

“Binary form” includes any format that is commonly used for electronic conveyance that is a reversible, bit-exact translation of binary representation to ASCII or ISO text, for example “uuencode.”

DISCLAIMER.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

https://01.org/mcu-path-license-2018

Enfim. A Intel não costuma ser anti open source. Bem pelo contrário. Os drivers das gráficas são open source e até têm uma distro (Clear Linux).
Apenas um lapso.

 

[skandal]

Isso ou algum advogado se lembrou de lhes dizer que a licença era ilegal

 

[Nemesis11]

O Theo de Raadt tem um post de hoje interessante. O post, basicamente, reforça a ideia que o utilizador deve desabilitar Hyperthreading na Bios. SMT não é em si inseguro. A implementação da Intel, na opinião do Theo, é.

Para quem estiver fora deste mundo, o Theo é o lider do projecto OpenBSD. A quota de mercado do OpenBSD, no total, é minúsculo, mas é bastante usado em alguns mercados, como em equipamentos de rede (Normalmente firewalls, mas não só) e servidores. É um projecto que se diferencia de muitos outros de várias formas, como a simplicidade das diversas aplicações, mas um dos seus pontos fortes é a importância que dá à segurança.

Além disto, eles desenvolvem projectos muito importantes, como o openssh, pf, dhcpd, openntpd, libressl, iscsid, tmux, snmpd, etc.

Aqui segue o post:

Subject: Disable SMT/Hyperthreading in all Intel BIOSes

Two recently disclosed hardware bugs affected Intel cpus:

- TLBleed

- T1TF (the name "Foreshadow" refers to 1 of 3 aspects of this
bug, more aspects are surely on the way)

Solving these bugs requires new cpu microcode, a coding workaround,
*AND* the disabling of SMT / Hyperthreading.

SMT is fundamentally broken because it shares resources between the two
cpu instances and those shared resources lack security differentiators.
Some of these side channel attacks aren't trivial, but we can expect
most of them to eventually work and leak kernel or cross-VM memory in
common usage circumstances, even such as javascript directly in a
browser.

There will be more hardware bugs and artifacts disclosed. Due to the
way SMT interacts with speculative execution on Intel cpus, I expect SMT
to exacerbate most of the future problems.

A few months back, I urged people to disable hyperthreading on all
Intel cpus. I need to repeat that:

DISABLE HYPERTHREADING ON ALL YOUR INTEL MACHINES IN THE BIOS.

Also, update your BIOS firmware, if you can.

OpenBSD -current (and therefore 6.4) will not use hyperthreading if it
is enabled, and will update the cpu microcode if possible.

But what about 6.2 and 6.3?

The situation is very complex, continually evolving, and is taking too
much manpower away from other tasks. Furthermore, Intel isn't telling
us what is coming next, and are doing a terrible job by not publically
documenting what operating systems must do to resolve the problems. We
are having to do research by reading other operating systems. There is
no time left to backport the changes -- we will not be issuing a
complete set of errata and syspatches against 6.2 and 6.3 because it is
turning into a distraction.

Rather than working on every required patch for 6.2/6.3, we will
re-focus manpower and make sure 6.4 contains the best solutions
possible.

So please try take responsibility for your own machines: Disable SMT in
the BIOS menu, and upgrade your BIOS if you can.

I'm going to spend my money at a more trustworthy vendor in the future.

https://marc.info/?l=openbsd-tech&m=153504937925732&w=2

Eu não espero que outros projectos "peçam" a mesma coisa, a não ser que exista alguma grande bronca e que muitas pessoas fiquem prejudicadas.

 

[miguelbazil]

Eu não conheço muito destes mundos em termos humanos, portanto agradeço sempre que postam aqui este tipo de coisas. Por agora ainda não houve um ataque a sério que usasse estas vulnerabilidades, e a intel vai escapando. Mas o mercado empresarial começa a fugir e procurar alternativas, isto não poderá ser eventualmente um rombo económico para a intel?

 

[Dark Kaeser]

Enquanto o mercado de servidores estiver em expansão, é capaz de não se notar muito, até porque a Intel tal como no mercado doméstico foi esticando os preços, assim mascara a situação de menos unidades vendidas pelo maior preço a que vende.

O problema maior da Intel é agora haver uma alternativa, ainda por cima a menor preço.

 

[miguelbazil]

E estas falhas de segurança não provocaram muitas saídas?

 

[Dark Kaeser]

O problema é para quem tem milhares de servidores não pode simplesmante tirá-los e trocá-los, é bom para a Intel a curto prazo, mas com a AMD a conseguir convencer alguns players que já tem EPYC (Azure da Microsoft, Baidu e a Yahoo) no médio prazo, quando for necessário construir novos ou fazer update aos que têm, se calhar haverá mais players que vão olhar com outros olhos para o EPYC, e a AMD já tem EPYC 7nm na calha para sair mais para o final do ano, o mais tardar inicío do próximo, e a Intel só terá 10nm para 2020, algures.

 

[filipeck]

E estas falhas de segurança não provocaram muitas saídas?

É complicado. É um mercado menos volátil e que preza a estabilidade. Sem validações feitas sobre o hardware, que demoram o seu tempo, não investem. Mas os EPYC estão pouco a pouco a ganhar marketshare.

 

[Dark Kaeser]

John Masters, Computer Architect at Red Hat @frOSCon2018

The list of publicly disclosed vulnerabilities includes (Jan-Aug):
● Spectre-v1 (Bounds check bypass)
● Spectre-v2 (Branch target injection)
● Meltdown (Rogue data cache load)
●"variant 3a” (Rogue system register read)
●“variant 4” (Speculative store bypass)
●Lazy FPU save/restore
●“Variant 1.x” (Bounds check bypass store)
●“TLBleed” (TLB side-channel introduced)
●“NetSpectre” (Spectre over the network)
●“Foreshadow” (L1 Terminal Fault)

http://people.redhat.com/jcm/talks/frOSCon_2018.pdf

 

[Dark Kaeser]

- Linux Kernel Developer Criticizes Intel for Meltdown, Spectre Response

Kroah-Hartman is one of the world's leading Linux kernel developers, with responsibility for maintaining the stable Linux kernel, and is employed by the Linux Foundation as a Fellow. During his talk, Kroah-Hartman detailed the root impact and the response of Linux kernel developers for seven variants of Meltdown and Spectre, though he saved his strongest criticism for Intel's initial disclosure.

http://www.eweek.com/security/linux-kernel-developer-criticizes-intel-for-meltdown-spectre-response

E já agora mais uns testes

The Performance Cost Of Spectre / Meltdown / Foreshadow Mitigations On Linux 4.19

On the Intel side the relevant mitigations include page table isolation (PTI/KPTI) for Meltdown and then the various Spectre speculative execution mitigations including __user pointer sanitization, full generic Retpolines via IBPB IBRS_FW, speculative store bypass disable via prctl and seccomp, and for L1TF/Foreshadow is PTE inversion and conditional cache flushes for VMs. By default the Linux kernel doesn't enforce the "full" mitigation of disabling Intel HT/SMT support, so keep that in mind if you are running VMs and whether untrusted code/users have access to the VM that if you opt for the full mitigation where SMT is disabled the performance impact will be a lot more noticeable due to halving the number of threads available.

On the AMD EPYC side the default mitigations are just for their relevant vulnerabilities with __user pointer sanitization for Spectre V1, AMD Retpoline IBPB for Spectre V2, and speculative store bypass disable (SSBD) for Spectre V4.

https://www.phoronix.com/scan.php?page=article&item=linux-419-mitigations&num=1

 

[muddymind]

Ainda é uma talhada considerável de performance nos intel...

EDIT: Se quiserem ver valores absolutos: http://openbenchmarking.org/result/1808296-RA-SMELTDOWN82&obr_imw=y

 

[miguelbazil]

@Dark Kaeser esse link do eweek está-me a dar forbidden. Consegues abri-lo?