The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

20.01.2018 10:44  Red Hat отменил обновление микрокода с устранением уязвимости Spectre

Компания Red Hat отозвала обновление пакетов с микрокодом (microcode_ctl и linux-firmware), выпущенное 16 января для устранения второго варианта уязвимости Spectre (CVE-2017-5715). В качестве причины отмены обновления называются проблемы со стабильностью, которые были выявлены в результате дополнительного тестирования и жалоб клиентов. На некоторых системах обновление микрокода приводило к невозможности загрузки.

Для блокирования CVE-2017-5715 пользователям рекомендуется использовать обновление прошивок, предоставленных для конкретных систем производителями CPU и оборудования. Напомним, что уязвимость Meltdown (CVE-2017-5754) и второй вариант уязвимости Spectre (CVE-2017-5715) могут быть целиком закрыты на уровне операционной системы (патчи KPTI и retpoline). Второй вариант Spectre также устраним на уровне обновления микрокода. Для устранения первого варианта Spectre (CVE-2017-5753) необходима пересборка приложений и ядра модифицированным компилятором с поддержкой подстановки опкода LFENCE. Компания Intel проинформирована о возникновении проблем с новым микрокодом и пытается разобраться в их причинах.

  1. Главная ссылка к новости (https://ma.ttias.be/red-hat-re...)
  2. OpenNews: Эксплоиты и тесты производительности, связанные с уязвимостями Meltdown и Spectre
  3. OpenNews: Раскрыты подробности двух атак на процессоры Intel, AMD и ARM64
  4. OpenNews: Разработчики Linux и Windows работают над закрытием огромной уязвимости в процессорах
  5. OpenNews: Обновление микрокода Intel приводит к перезагрузкам систем с CPU Broadwell и Haswell
  6. OpenNews: Ошибка в обновлении ядра в Ubuntu 16.04 приводит к сбою загрузки системы
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: spectre, redhat
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (-), 11:29, 20/01/2018 [ответить] [показать ветку] [···]    [к модератору]
  • –4 +/
    Так может быть полностью закрыт Spectre или нет?
     
     
  • 2.2, werwolf (?), 11:32, 20/01/2018 [^] [ответить]    [к модератору]
  • +19 +/
    может, обновлением микрокода, которое intel написали левой пяткой и оно чуть ли не хуже чем сама уязвимость.. ждём нового обновления
     
  • 2.3, Аноним (-), 11:32, 20/01/2018 [^] [ответить]    [к модератору]
  • +18 +/
    Надо узнать у Михаила Шигорина, я думаю они уже закрыли уязвимость в Альте.
     
     
  • 3.4, Michael Shigorin (ok), 11:33, 20/01/2018 [^] [ответить]    [к модератору]
  • +2 +/
    Нет.
     
     
  • 4.6, Аноним (-), 12:30, 20/01/2018 [^] [ответить]    [к модератору]
  • +90 +/
    ШИГОРИНА ОТВЕТ
     
  • 3.5, Sluggard (ok), 11:47, 20/01/2018 [^] [ответить]    [к модератору]  
  • +16 +/
    Давно в Альте пишут микрокод для процессоров от Intel?
     
  • 2.16, bircoph (ok), 16:34, 20/01/2018 [^] [ответить]    [к модератору]  
  • +13 +/
    Spectre — это целый класс уязвимостей, и сами авторы двух опубликованных CVE указывают, что это лишь два наиболее очевидных вектора атаки, а менее очевидных может быть ещё очень много:
    https://spectreattack.com/spectre.pdf

    Текущие исправления софта и микрокода лишь немного затыкают опубликованные CVE, не решая всей проблемы. Мало того, исправление софта — это не замена одного лишь ядра или glibc, необходимо пересобирать абсолютно весь софт пропатченным или обновлённым (в зависимости от ветки) gcc. И вся суть этих изменений в обмане предсказателя ветвей процессора за счёт использования return + trampoline вместо обычных косвенных переходов. И даже это не всем поможет, т.к. последнее поколение процессоров Intel сшиком умное и его уже не обмануть столь простыми средствами.

    Короче говоря, это костыль на грязном хаке, который лишь усложняет опубликованные способы атак. Реальным исправлением будет выпуск новых процессоров, где аппаратно данная проблема устранена. Но на разработку нового чипа нужно 2-3 года, поэтому раньше, чем через 1.5 года решения проблемы не будет.

     
     
  • 3.17, Аноним (-), 17:28, 20/01/2018 [^] [ответить]    [к модератору]  
  • +/
    >  последнее поколение процессоров Intel сшиком умное и его уже не обмануть столь простыми средствами

    ну обновление микрокода делает процессор более тупым..

    в частности говоря про "load fence"

     
     
  • 4.34, bircoph (ok), 03:12, 21/01/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    > ну обновление микрокода делает процессор более тупым..
    > в частности говоря про "load fence"

    Безусловно. Но load fence лишь усложняет подобные атаки, но не делает их невозможными.

     
  • 3.32, Аноним (-), 01:20, 21/01/2018 [^] [ответить]     [к модератору]  
  • +3 +/
    Т е процессоры выпускались со спекулятивным выполнением, чтобы конвейеры не про... весь текст скрыт [показать]
     
     
  • 4.35, bircoph (ok), 03:19, 21/01/2018 [^] [ответить]    [к модератору]  
  • +6 +/
    > Т.е. процессоры выпускались со спекулятивным выполнением, чтобы конвейеры не простаивали
    > и считали несколько веток,

    Не совсем, обе ветки сразу считать — это предикатное выполнение. На интелах (кроме Itanium) предикатного выполнения нет. Спекулятивное — это когда на основе ранее собраных процессором данных делается предсказание более вероятной ветки и она считается, и всё, что за ней следует. Это и позволяет заполнить конвеер.

    > а сейчас софт переписывают под особенности процессоров,
    > чтобы последние "промаргивали" возможное выполнение веток, отличных от текущей?

    Да, именно так. Притом потери быстродействия сильные и компилятор пытается угадать, где нужно дурить предсказатель ветвей, а где нет. Результаты ошибок при попытках угадать мы уже видели, дежавю. Так что уязвимости класса Spectre в том или ином виде будут ещё долго встречаться.

    > Ну отличненько,
    > чё. Делайте аппаратный флаг, разрешающий/запрещающий это самое спекулятивное выполнение.

    Ну так это нужно все процессоры менять, что дорого и зачастую просто невозможно. Если уж менять что-то в процессорах аппаратно, то лучше модифицировать предсказатель ветвей, например, добавить для него собственный некеширующий буфер, чтоб результаты вычислений не попадали в общий кеш до выполнения проверки условия ветвления.

     
  • 3.37, Аноним (-), 06:01, 21/01/2018 [^] [ответить]     [к модератору]  
  • +4 +/
    Спорные заявления И Meltdown и Spectre трудно заткнуть без полноценного механиз... весь текст скрыт [показать]
     
     
  • 4.38, КО (?), 10:48, 22/01/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    В этом нет никакой проблемы Это проверяется и код не выполняется - два раза Од... весь текст скрыт [показать]
     
     
  • 5.42, J.L. (?), 16:17, 24/01/2018 [^] [ответить]     [к модератору]  
  • +/
    gt оверквотинг удален спасибо, теперь стало понятно в чём конкретно ошибка тое... весь текст скрыт [показать]
     
  • 5.43, Anonymoustus (ok), 19:49, 24/01/2018 [^] [ответить]     [к модератору]  
  • +/
    После всех этих историй с, назывём вещи своими именами, жульничеством ради повыш... весь текст скрыт [показать]
     
  • 2.41, Andrew Kolchoogin (ok), 13:48, 22/01/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    Нет, без изменения архитектуры CPU отказа от спекулятивного исполнения закрыть... весь текст скрыт [показать]
     
  • 1.7, Аноним (-), 13:05, 20/01/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    А что там со Spectre V1? Есть какие-нибудь патчи? С ядром 4.14.14 PoC все еще работает.
     
     
  • 2.14, Аноним (-), 16:22, 20/01/2018 [^] [ответить]     [к модератору]  
  • +/
    Надо пересобирать ядро с gcc 7 3 или gcc 7 2 repoline патчи Релиз кандидат вы... весь текст скрыт [показать]
     
  • 1.9, Аноним (-), 14:26, 20/01/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Автору - из заголовка нельзя понять: отменил для устранения уязвимости или обновление микрокода для устранения уязвимости.
     
  • 1.10, Аноним (-), 14:45, 20/01/2018 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    Всё перепутали Читайте mitigation https github com speed47 spectre-meltdown-... весь текст скрыт [показать]
     
  • 1.11, Аноним (-), 15:25, 20/01/2018 [ответить] [показать ветку] [···]     [к модератору]  
  • +3 +/
    Вообще опасность Spectre сильно преувеличена и искусственно раздута Если не счи... весь текст скрыт [показать]
     
     
  • 2.15, Аноним (-), 16:29, 20/01/2018 [^] [ответить]    [к модератору]  
  • +8 +/
    Интелу после их фундаментального срочно потребовалось найти хоть что-то, но чтоб у AMD тоже.
     
     
  • 3.31, Аноним (-), 01:12, 21/01/2018 [^] [ответить]    [к модератору]  
  • +/
    Просто линукс-конспирология уже не возбуждает. Нужна витиеватая линукс-конспирология. Такая, с подвывертом.


     
  • 2.18, Аноним (-), 17:41, 20/01/2018 [^] [ответить]     [к модератору]  
  • +1 +/
    в браузерах прибили -- ну молодцы, right а кто будет прибивать менее популярны... весь текст скрыт [показать]
     
     
  • 3.19, Аноним (-), 18:15, 20/01/2018 [^] [ответить]    [к модератору]  
  • +/
    В компиляторы патчи прилетят со временем (от Spectre v2 уже в gcc 7.3). Просто оно не так опасно, ну подумаешь local root. Удалённо Lua- и PSQL-код просто так не исполняется.
     
     
  • 4.22, Xasd (ok), 18:51, 20/01/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    > В компиляторы патчи прилетят со временем

    это не избавит от v1 -- автоматичкски. (вообще говоря v2 можно даже и не испавравлять -- толку от его исправления.. самоё стрёмное это v1 )

    разумеется всякие новые конструкции типа __builtin_load_no_speculate() -- помогут авторам реализовать исправления (v1) в их программах...

    ...но сами собой-то вызовы __builtin_load_no_speculate() не вставятся. :-)

    их люди должны вручную понавставлять в свои программы (заместо spectre-подверженных блоков) в те места где они должны быть по смыслу

     
  • 3.39, Аноним (-), 12:17, 22/01/2018 [^] [ответить]    [к модератору]  
  • +/
    > в браузерах прибили -- ну молодцы, right..

    и то слегка криво: https://support.mozilla.org/en-US/questions/1198266

     
  • 2.21, лж (?), 18:39, 20/01/2018 [^] [ответить]    [к модератору]  
  • +/
    >остаётся что-то уровня local root, которых в год с десяток находят

    Только их закрывают за минимальное время и с минимальными усилиями. А тут дырка останется и пол ядра переписали (сколько ещё дыр вылезет на этой почве?)

     
     
  • 3.23, iPony (?), 19:01, 20/01/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    нужно глубже! https://skyfallattack.com
     
  • 1.20, manster (ok), 18:32, 20/01/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • –2 +/
    Теперь кроме "не выбрасывайте старые железки", можно вполне добавить: "не выбрасывайте старые ядра" ....

    По крайней мере - выборочно не удалять и оставлять в качестве альтернативной загрузки.

     
     
  • 2.24, Xasd (ok), 19:01, 20/01/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    > Теперь кроме "не выбрасывайте старые железки", ...

    ну и с какой же это целью их следует не выбрасывать? :-)

    (про ядра я даже молчу -- кому в голову придёт не обновиться)

     
  • 2.27, Аноним (-), 22:29, 20/01/2018 [^] [ответить]    [к модератору]  
  • –2 +/
    Причём здесь ядра, если речь о микрокоде? Ядра-то по умолчанию старые ни в одном дистре не удаляются (по крайней мере n штук последних).
     
     
  • 3.28, pavlinux (ok), 23:18, 20/01/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    микрокод без ядра бесполезен, ядро без микрокода тоже.
    Вывод: c 3 января ничего не поменялось

     
  • 1.44, AnoNe01eX (?), 19:21, 25/01/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Z80 наше всё. :-)
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor