メインコンテンツにスキップ
ブログLinodeインテルのL1TF CPU脆弱性とLinode

インテルのL1TF CPU脆弱性と Linode

IntelL1TFVulnerability_1200x631

今週初め、インテルはL1 Terminal Fault (L1TF)と呼ばれる新しいクラスのプロセッサーの脆弱性を一般に公開しました。L1TF のバリアントは一部を含む多くのシングルテナントおよびマルチテナント環境及び、Linode のインフラと Linode自体に影響があります。

我々は対応に向けた努力を開始し、今後数週間以内に当社フリートの完全な対応を予定しています。お客様の実行中システムを中断することなく、またお客様側での調整を必要とせずに達成できると信じています。しかしまだ状況が変化しているため、時間が経つにつれてわかってくるはずです。初動の結果は前向きです。

私たち側の保護は行う一方で、お客様におきましては対策を備えた Linux カーネルを実行していることを確認して下さい。カーネルのアップグレードに関するガイドをご覧ください。

今後数週間で対策が進むにつれて、ブログにて情報を提供していきます。お待ちください!


コメント (8)

  1. Author Photo

    Thanks for the hard work in dealing with this. Though I am not sure it’s enough to just update the Kernel on OS side, need microcode updates – I guess from host node OS level too https://www.linode.com/community/questions/17120/how-is-linode-handling-l1tf-what-actions-can-we-take-to-mitigate#answer-66869 ?

    Wouldn’t the microcode updates require host node level reboots ?

  2. Christopher Aker

    You are correct! We’re able to transparently move VMs to patched infrastructure using live migrations.

  3. Author Photo

    Ah sweet – live migration feature is awesome. One of many reasons I have stuck with Linode for 4+ yrs now 🙂

  4. Author Photo

    What are your plans regarding HyperThreading?

    One of the things that has me shocked about L1TF is that there does not yet appear to be any publicly-available, complete mitigation to either of the major open-source hypervisors (KVM and Xen) that does not require HyperThreading to be disabled.

    L1TF is not fully mitigated if unrelated guests can run as hyper-siblings (or if an untrusted guest–which is all guests for a cloud VM provider–can run as a hyper-sibling of a hypervisor thread). Technically, this could be enforced by a scheduler, but the most unequivocal statement of a scheduler that will do so comes from, of all places, Microsoft, and therefore Azure (https://blogs.technet.microsoft.com/virtualization/2018/08/14/hyper-v-hyperclear/).

    Google also indicates that individual cores are never concurrently shared between VMs (https://cloud.google.com/blog/products/gcp/protecting-against-the-new-l1tf-speculative-vulnerabilities). Certainly, they have the wherewithal to pull this off with custom internal kernel changes, so there’s no particular reason to doubt them. (I didn’t find any clear statement from AWS on shared cores, but they already have their custom Nitro hypervisor, so plausibly they have a custom modification.)

    Unfortunately, the current docs applicable to KVM don’t provide any good solution for a cloud VM provider other than disabling HyperThreading: https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html

    Am I wrong about this?

  5. Author Photo

    I too would like to know more about the hyperthreading story. We have multiple internal deployments of openstack and vmware that would suffer if we have to disable HT. Did Linode disable HT?

    I am very happy with Linode being able to live migrate things with no downtime to customers. That is a massive improvement over the past migration queues.

  6. Author Photo

    Thanks for implementing these security fixes.

    The new “live” migrations is certainly interesting – is this a new feature that you’re now able to use? It’s certainly much less painful than existing migration queues and forced downtime.

    Futhermore, will live migration be introduced for other server moves, such as upgrades and downgrades?

  7. Author Photo

    Our current plan for L1TF mitigation is to disable HyperThreading.

    Yes, live migrations are a feature that we are now able to use. We are evaluating the different use cases for this one, but currently it cannot be used for upgrades/downgrades with plan resizing.

  8. Author Photo

    Thanks for keeping us informed and patching the hosts. We appreciate the effort and due diligence. I’m sure these projects at large scale are never fun.

コメントを残す

あなたのメールアドレスは公開されません。必須項目には*印がついています。