Auteur Sujet: Spectre et Meltdown: Grave problème de design des CPU Intel depuis 10ans  (Lu 22148 fois)

0 Membres et 1 Invité sur ce sujet

zoc

  • Client Orange Fibre
  • *
  • Messages: 3 059
  • Antibes (06)
Grave probleme de design des CPU intel depuis 10ans
« Réponse #24 le: 05 janvier 2018 à 08:03:50 »
Intel avait justement annoncé que ca ne pourrait pas être fixé par une mise à jour du microcode...

Il est possible de mettre à jour le microcode sur tous les processeurs à architecture CISC, et pas que les récents...

vivien

  • Administrateur
  • *
  • Messages: 35 583
    • Twitter LaFibre.info
Grave probleme de design des CPU intel depuis 10ans
« Réponse #25 le: 05 janvier 2018 à 08:47:49 »
Seuls les CPU de moins de 10 ans peuvent voir leur microcode mis à jour (CPU lancés en 2007 et plus récents)

J'ai un Intel Xeon E5620 @ 2.40GHz, CPU lancé au 1er trimestre 2010, sur un IBM System x  x3550 M3 7944 K3G. Le BIOS n'a pas été mis à jour (UEFI Version 1.14 du 02/02/2012) => on a donc un microcode de 2011. Je suis étonné de ne pas voir de mise à jour du microcode par le système d'exploitation. Je me demande si certains BIOS ne bloquent pas les mises à jour de microcode.

Sinon pour répondre à Leon, les hyperviseurs bloquent pour que des OS invités ne mettent pas à jour le microcode.

Attention, le microcode ne se met pas à jour une fois pour toute, c'est à chaque démarrage qu'il est mis à jour, ce n'est pas dans une mémoire flash.

Pour Windows, c'est complètement transparent pour l'utilisateur, ce sont les mises à jour Windows Update qui apportent les mises à jour de microcode.




Sinon, pour vous faire peur, un système d’exploitation peut rendre un BIOS inutilisable.
Plusieurs distributions linux qui fournissent un noyaux Linux récent sont impactés par ce bug :
Incompatibility with BIOS in certain Lenovo, Acer systems

A bug in the Linux 4.13 kernel shipped in Ubuntu 17.10 can leave users unable to update any of their BIOS settings, including their system’s boot order, after booting this version of Ubuntu.

A kernel with a fix for this issue will be available in zesty-updates shortly, but, the Ubuntu 17.10 installer images still contain the kernel with this bug. Users with affected systems should not upgrade to Ubuntu 17.10 or boot an Ubuntu 17.10 installer image until this issue as resolved. Doing so may result in your computer requiring professional servicing in order to restore BIOS functionality.

A full list of known affected models can be found in 1734147.

If you have already installed Ubuntu 17.10 on an affected system, you may not immediately notice this problem because Ubuntu will continue to boot from disk. To verify whether your system has been affected by this bug, create a USB stick with the Ubuntu 16.04 desktop image and try to boot it. If you are able to boot it, your system has most likely not been impacted by this bug.

Source : Wiki Ubuntu

Ubuntu 17.10 n'est plus disponible au téléchargement depuis deux semaines pour cette raison. J'ai vu des correctifs, mais je pensent qu'ils veulent être sur de valider la chose avec Lenovo avant de proposer de nouvelles images ISO d'Ubuntu 17.0.

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 796
  • 73
    • La compression de zéro
Grave probleme de design des CPU intel depuis 10ans
« Réponse #26 le: 05 janvier 2018 à 09:27:55 »
Du coup, est-ce qu'il faut comprendre qu'un logiciel (l'OS) est capable de mette à jour le microcode?
Est-ce que seuls les logiciels type "OS" ont cette possibilité? Mais alors quid des logiciels que l'on boote sans OS sur un CD/clef USB? (logiciel de clonage de HDD). Quid des trucs qui se lancent parfois avant l'OS?
C'est fait "une fois pour toutes"? Ou alors à chaque démarrage?
Où est stocké ce microcode sur les CPU modernes? En interne dans une petite mémoire Flash?

Si un logiciel (l'OS) est capable de mettre à jour le microcode, est-ce que ça ne pose pas un énorme problème de vulnérabilité? Ca veut quand même dire que l'on peut modifier le comportement des instructions du CPU, c'est assez énorme!  :o

La mise à jour du microcode est possible au démarrage, depuis l'OS hôte. Cela se fait en chargeant un payload chiffré ou obfusqué au démarrage. Il existe plusieurs papiers récents sur le sujet (que je n'ai pas lus entièrement mais les deux derniers semblent être assez exhaustifs) :
À priori, Intel utilise RSA+SHA et AMD utilise une routine d'obfuscation que les chercheurs ont pensé poli de ne pas dévoiler.

Sur les Linux récents la mise à jour du microcode Intel est incluse de base ou fortement recommandée, depuis la découverte de bugs présents dans les architectures Haswell et Broadwell. Cf. https://wiki.archlinux.org/index.php/microcode

Thornhill

  • Client SFR fibre FTTH
  • *
  • Messages: 3 289
  • Saint-Médard-en-Jalles (33)
Grave probleme de design des CPU intel depuis 10ans
« Réponse #27 le: 05 janvier 2018 à 10:15:13 »
Les mises à jour de microcode pour atténuer une partie des failles arrivent :


https://access.redhat.com/errata/RHSA-2018:0040
RHSA-2018:0040 - Security Advisory
Security Fix(es):

• An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited. Variant CVE-2017-5715 triggers the speculative execution by utilizing branch target injection. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall and guest/host boundaries and read privileged memory by conducting targeted cache side-channel attacks. (CVE-2017-5715)


Note: This is the microcode counterpart of the CVE-2017-5715 kernel mitigation.


Red Hat would like to thank Google Project Zero for reporting this issue.

shroeder

  • Client Free adsl
  • *
  • Messages: 14
Grave probleme de design des CPU intel depuis 10ans
« Réponse #28 le: 05 janvier 2018 à 14:59:39 »
Seuls les CPU de moins de 10 ans peuvent voir leur microcode mis à jour (CPU lancés en 2007 et plus récents)
IBTD.
Le Pentium Pro (ce qui nous ramène il y a 22 ans tout de même -11/1995-) avait déjà cette capacité cf. http://datasheets.chipdb.org/Intel/x86/Pentium%20Pro/PPPBIOS.PDF.
On peut supposer que cette décision fut prise pour éviter de renouveler le fiasco du du bug FDIV de l'année précédente .
Le µcode peut être chargé par le BIOS ou l'UEFI, auquel cas il est actif dès le POST, soit être chargé par l'OS (sous Windows 95->2003, dans le fichier update.sys, au dessus dans mcupdate_*.dll).
Cette dernière possibilité peut d'ailleurs être désactivée, cf. https://docs.google.com/viewer?url=patentimages.storage.googleapis.com/pdfs/US7660977.pdf, ce qui pourrait expliquer le comportement de ton x3550.

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 4 483
Grave probleme de design des CPU intel depuis 10ans
« Réponse #29 le: 05 janvier 2018 à 18:46:00 »
Les mises à jour de microcode pour atténuer une partie des failles arrivent :
Dans ce cas, comment ça se passe à votre avis?

Est-ce que c'est Intel et AMD qui fournissent à RedHat le fichier du nouveau microcode?
Est-ce que ce fichier du nouveau microcode (crypté) est public, librement disponible, intégrable dans n'importe quel OS / hyperviseur?

Leon.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 605
  • La Madeleine (59)
Grave probleme de design des CPU intel depuis 10ans
« Réponse #30 le: 05 janvier 2018 à 18:56:08 »
En parlant de microcode, voici la dernière maj:
intel-microcode (3.20171215.1) unstable; urgency=high

  * Add supplementary-ucode-CVE-2017-5715.d/: (closes: #886367)
    New upstream microcodes to partially address CVE-2017-5715
    + Updated Microcodes:
      sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
      sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
      sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
      sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
      sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
      sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
      sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
      sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
      sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
      sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304
  * Implements IBRS and IBPB support via new MSR (Spectre variant 2
    mitigation, indirect branches).  Support is exposed through cpuid(7).EDX.
  * LFENCE terminates all previous instructions (Spectre variant 2
    mitigation, conditional branches).

 -- Henrique de Moraes Holschuh <hmh@debian.org>  Thu, 04 Jan 2018 23:04:38 -0200

Leon: le microcode est un simple blob, qui est passé par le kernel au CPU très tôt à chaque boot (grep microcode dans ton dmesg après reboot)
Pour autant que je sache, et comme le dit Marin, le blob est complétement opaque. Je suppose qu'il n'y a aucun action de faite sur ce dernier au niveau du kernel, et que les fichiers sont donc utilisables par n'importes quel OS (qui ne sert donc que de "passe-plat")

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 4 483
Grave probleme de design des CPU intel depuis 10ans
« Réponse #31 le: 05 janvier 2018 à 19:10:06 »
Leon: le microcode est un simple blob, qui est passé par le kernel au CPU très tôt à chaque boot (grep microcode dans ton dmesg après reboot)
Pour autant que je sache, et comme le dit Marin, le blob est complétement opaque. Je suppose qu'il n'y a aucun action de faite sur ce dernier au niveau du kernel, et que les fichiers sont donc utilisables par n'importes quel OS (qui ne sert donc que de "passe-plat")
OK, mais est-ce que c'est fourni librement à n'importe qui le demande? N'importe qui qui voudrait coder un OS ou un hyperviseur? Est-ce le microcode (crypté) est fourni de manière totalement libre, publique, par Intel et AMD ?

Leon.

vivien

  • Administrateur
  • *
  • Messages: 35 583
    • Twitter LaFibre.info
Grave probleme de design des CPU intel depuis 10ans
« Réponse #32 le: 05 janvier 2018 à 19:13:16 »

vivien

  • Administrateur
  • *
  • Messages: 35 583
    • Twitter LaFibre.info
Grave probleme de design des CPU intel depuis 10ans
« Réponse #33 le: 05 janvier 2018 à 19:19:48 »
Firefox 57.0.4 est sortie hier et intégre uniquement deux fixes to address the Meltdown and Spectre timing attacks. Le correctif est détaillé sur https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ et vise a atténuer le risque d'une attaque via une page web.


Ubuntu distribuera les correctifs kernel, mardi prochain : (on ne sais pas si la mise à jour du micro-code sera de la partie, il aiment bien que le microcode soit testé longtemps en pré-prod avant une large distribution)

Unfortunately, you’ve probably already read about one of the most widespread security issues in modern computing history — colloquially known as “Meltdown” (CVE-2017-5754) and “Spectre” (CVE-2017-5753 and CVE-2017-5715) — affecting practically every computer built in the last 10 years, running any operating system.  That includes Ubuntu.

I say “unfortunately”, in part because there was a coordinated release date of January 9, 2018, agreed upon by essentially every operating system, hardware, and cloud vendor in the world.  By design, operating system updates would be available at the same time as the public disclosure of the security vulnerability.  While it happens rarely, this an industry standard best practice, which has broken down in this case.

At its heart, this vulnerability is a CPU hardware architecture design issue.  But there are billions of affected hardware devices, and replacing CPUs is simply unreasonable.  As a result, operating system kernels — Windows, MacOS, Linux, and many others — are being patched to mitigate the critical security vulnerability.

Canonical engineers have been working on this since we were made aware under the embargoed disclosure (November 2017) and have worked through the Christmas and New Years holidays, testing and integrating an incredibly complex patch set into a broad set of Ubuntu kernels and CPU architectures.

Ubuntu users of the 64-bit x86 architecture (aka, amd64) can expect updated kernels by the original January 9, 2018 coordinated release date, and sooner if possible.  Updates will be available for:
- Ubuntu 17.10 (Artful) — Linux 4.13 HWE
- Ubuntu 16.04 LTS (Xenial) — Linux 4.4 (and 4.4 HWE)
- Ubuntu 14.04 LTS (Trusty) — Linux 3.13
- Ubuntu 12.04 ESM** (Precise) — Linux 3.2
Note that an Ubuntu Advantage license is required for the 12.04 ESM kernel update, as Ubuntu 12.04 LTS is past its end-of-life

Ubuntu 18.04 LTS (Bionic) will release in April of 2018, and will ship a 4.15 kernel, which includes the KPTI patchset as integrated upstream.

Ubuntu optimized kernels for the Amazon, Google, and Microsoft public clouds are also covered by these updates, as well as the rest of Canonical’s Certified Public Clouds including Oracle, OVH, Rackspace, IBM Cloud, Joyent, and Dimension Data.

These kernel fixes will not be Livepatch-able.  The source code changes required to address this problem is comprised of hundreds of independent patches, touching hundreds of files and thousands of lines of code.  The sheer complexity of this patchset is not compatible with the Linux kernel Livepatch mechanism.  An update and a reboot will be required to active this update.

Furthermore, you can expect Ubuntu security updates for a number of other related packages, including CPU microcode, GCC and QEMU in the coming days.

We don’t have a performance analysis to share at this time, but please do stay tuned here as we’ll followup with that as soon as possible.

Thanks,
@DustinKirkland
VP of Product
Canonical / Ubuntu


Source : Canonical, le 4 janvier 2018

jeremyp3

  • Pau Broadband Country (64)
  • Client Orange Fibre
  • *
  • Messages: 481
  • FTTH 1Gb/s sur Pau (64)
Grave probleme de design des CPU intel depuis 10ans
« Réponse #34 le: 06 janvier 2018 à 03:59:33 »
bonjour,

le kernel de jessie 3.16 sera-t-il mis a jour ? oui oui je sais, je suis en retard :D j'ai déjà installé sur mon serveur jessie intel-microcode (de sid), mais je sais pas si ça suffit.

jerem

vivien

  • Administrateur
  • *
  • Messages: 35 583
    • Twitter LaFibre.info
Grave probleme de design des CPU intel depuis 10ans
« Réponse #35 le: 06 janvier 2018 à 07:27:49 »
Le Kernel 3.16 de Debian sera mis à jour.

Le Kernel 3.16 pour Ubuntu non : Le Kernel 3.16 est celui d'Ubuntu 14.10 qui as été proposé sur Ubuntu 14.04 LTS pour avoir les dernières technologies, mais avec un support de 18 mois seulement. Le Kernel 3.16 ne reçois plus aucune mise à jour de sécurité depuis août 2016.

Il est impératif de passer sur un Kernel avec un support long terme (jusqu'à avril 2019 pour Ubunu 14.04 LTS).

Au choix :
- Le Kernel 3.13 (celui d'origine de Ubuntu 14.04 LTS)
- Le Kernel 4.4 (celui d'origine de Ubuntu 16.04 LTS)

Je pense que tu vas choisir le kernel 4.4 pour éviter de passer sur un kernel plus ancien.

Pour un Ubuntu avec interface graphique, il faut taper en ligne de commande sudo apt-get install --install-recommends linux-generic-lts-xenial xserver-xorg-core-lts-xenial xserver-xorg-lts-xenial xserver-xorg-video-all-lts-xenial xserver-xorg-input-all-lts-xenial libwayland-egl1-mesa-lts-xenial

Pour un Ubuntu server, il faut lancer : sudo apt-get install --install-recommends linux-generic-lts-xenial



A noter que pour Ubuntu 16.04, il n'y a plus de risque d'être sur un kernel non supporté, si on choisit d'être sur un Kernel récent qui n'a pas un support jusqu'à avril 2021, les mises à jour de sécurité  entraînent un changement automatique de Kernel.


 

Mobile View