Если сообщения верны, Intel допустила весьма серьёзную уязвимость в своих центральных процессорах, и её нельзя исправить обновлением микрокода. Уязвимость затрагивает все процессоры Intel за последние лет десять как минимум.

Закрытие уязвимости требует обновления ОС, патчи для Linux уже вышли, Microsoft планирует закрыть её в рамках традиционного ежемесячного «вторника патчей». На данный момент детали уязвимости не разглашаются, но некоторые подробности всё-таки выплыли наружу благодаря Python Sweetness и The Register.

image

Уязвимость позволяет программам получать несанкционированный доступ к определённым данным в защищённой области памяти ядра. Предотвратить это можно, внедрив изоляцию памяти ядра (Kernel Page Table Isolation), которая сделает ядро «невидимым» для текущих процессов. Это не идеальное решение проблемы, но грядущие патчи для Windows, Linux и macOS будут использовать именно этот подход.

image

Однако подобное решение может очень серьёзно ударить по производительности. Падение производительности из-за изоляции может достигать 30 процентов. К счастью, последние модели процессоров Intel с технологией PCID (идентификаторы контекста процесса), возможно, позволяют уменьшить падение производительности, хоть и не избежав его совсем.

Уязвимость может эксплуатироваться в реальных условиях; под удар, в первую очередь, могут попасть компании, использующие виртуализацию.

«Разработка программного решения проблемы ведётся в срочном порядке, и уже недавно оно было внедрено в ядро Linux; в ядрах NT схожее решение начало появляться в ноябре,» — сообщает блок Python Sweetness. — «В худшем случае это повлечёт за собой серьёзное замедление в повседневных задачах.

»Есть повод подозревать, что уязвимы популярные окружения для виртуализации, включая Amazon EC2 и Google Compute Engine."

Microsoft Azure и Amazon Web Services уже запланировали временное отключение серверов на следующей неделе, хоть и не дают комментариев по поводу причины работ. Однако, вероятно, именно необходимость защититься от возможных атак с использованием найденной уязвимости является его причиной.

Заметьте, что AMD пока не упоминалась ни разу. Всё просто: процессоры AMD не подвержены данной уязвимости — а, следовательно, и не нуждаются в ресурсоёмкой защите от неё.

Томас Лендаки, участник работающей с Linux группы в AMD, сообщает:

«Процессоры AMD не подвержены атакам, от которых защищает изоляция памяти ядра. Архитектура AMD не позволяет получить доступ к данным при отсутствии соответствующих привилегий.»

image

К тому же, новые серверные чипы EPYC от AMD, а также их десктопные процессоры Ryzen Pro имеют технологию шифрования защищённой памяти, дающую дополнительную защиту от атак подобного рода.

Так или иначе, пока детали патчей не раскрываются, и Intel по понятным причинам предпочитает молчать, нам остаётся только ждать, когда можно будет полностью оценить серьёзность проблемы и угрозу, которую она несёт существующим компьютерным платформам. Но на данный момент всё это выглядит очень серьёзно. Патч с решением (kpti) для Linux добавил в ядро лично Линус Торвальдс.

Phoronix уже протестировали производительность при включённом kpti и пришли к выводу, что возможны просадки до 17-18 процентов.

Также сообщается, что патч для Linux будет по умолчанию включать kpti и на компьютерах с процессорами AMD, вызывая соответствующее падение производительности. AMD не рекомендует использовать kpti на компьютерах с процессорами AMD. Детали решения для Windows пока неизвестны.

Комментарии (479)


  1. Waki
    03.01.2018 13:31
    +1

    Хорошо год начался


    1. Kinokus
      03.01.2018 17:54

      И не поспоришь…


    1. Dmitri-D
      04.01.2018 02:54

      Intel по понятным причинам предпочитает молчать


      они всё-таки дают комментарии, но не торопятся
      Вот их заявление — в считанные часы после статей
      newsroom.intel.com/news/intel-responds-to-security-research-findings
      Другое дело, то вообще-то об уязвимости было известно уже в ноябре, и именно интел сообщил разработчикам, что фикса в микрокоде не предвидится.


      1. amarao
        04.01.2018 16:38

        Врут и передёргивают в каждом абзаце.

        Intel believes these exploits do not have the potential to corrupt, modify or delete data.
        (но позволяет читать чужие данные, включая пароли).

        Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
        (Все подвержены Spectre, но Meltdown — чисто интеловская проблема).

        Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
        (тормозит в IO, нормально в математике).

        Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.
        (без комментариев).


        1. iOrange
          04.01.2018 17:46
          +1

          Здесь пишут что Meltdown так же затрагивает и ARM64

          www.opennet.ru/opennews/art.shtml?num=47856


        1. Dmitri-D
          05.01.2018 00:05

          но позволяет читать чужие данные, включая пароли

          совершенно верно

          (Все подвержены Spectre, но Meltdown — чисто интеловская проблема)

          обе эти атаки — это по сути один трюк, с той лишь разницей, что при meltdown происходит переключение контекста на более привелигированный. Если AMD делает это медленнее или быстрее, то, соответственно, и алгоритм нужно адаптировать. И авторы честно об этом заявляют — что это вопрос оптимизации. Это же тайминговая задача.
          Практически — да, уязвимость meltdown продемонстрирована только на интеловских ( и на AMD в специальном режиме) Но, AMD всё-таки могло бы за эти 7 месяцев от демонстрации PoC (от 1 июня 2017го — был анонс PoC в адрес чипмейкеров, не публичный анонс, публично пошло вроде как в ноябре) найти и объявить какой конкретно механизм в AMD процессорах делает неуязвимым платформу этим атакам. Ничего не предъявлено. Поэтому рано говорить что проблема чисто интеловская.

          тормозит в IO

          IO — да, но насколько я понимаю — тормозит в любой задаче, требующей переключение контекста, в т.ч. и в тех математических, если такое переключение используется.


          1. amarao
            05.01.2018 11:31
            +1

            Я ещё не закончил читать их pdf'ку, но по квалифицированным комментариям в lwn.net, насколько я понимаю, разница между amd и intel состоит в том, что в спекулятивном исполнении intel сначала делает чтение, а потом проверяет права доступа, а amd сначала проверяет права, а потом читает. Таким образом, при не-выполнении спекулятивного кода intel позволяет прогревать кеш в соответствии с «запретными» данными. А amd спекулятивно готовится к сегфолту (который не происходит).


  1. lpwaterhouse
    03.01.2018 13:32

    «Это кривое и плохое со всех точек зрения решение, но вы жрите.»
    Интел кажется совсем поехал без конкуренции.


    1. 23derevo
      03.01.2018 16:45

      Обновления безопасности — это всегда слодные трейдоффы. Intel в данном случае решает сложную задачу, пытаясь балансировать между безопасностью и производительностью. Простых решений на таких масштабах не бывает.


  1. Mercury13
    03.01.2018 13:37

    А уязвим-то кто? Вот у меня Core i5 4-го поколения — с ним-то всё в порядке?


    1. Mercury13
      03.01.2018 13:46

      UPD. Чёрт, даже старичок Core2Duo уязвим??


      1. Ivan-P
        03.01.2018 17:54

        Откуда инфа?


      1. NiTr0_ua
        03.01.2018 20:12

        что-то думается, что там и пентиумы М, и даже пни 2 и 3 могут быть задеты. а возможно и нетбёрст…


      1. joann
        04.01.2018 13:57

        Сделал тест на своем Core 2 Duo (софт от интел) пишет что да дырка есть


        1. Akuma
          04.01.2018 14:11
          +1

          А где взять такой софт не подскажете?


          1. RAX7
            04.01.2018 16:24

            1. Vitalley
              05.01.2018 21:50

              А собранную никто не выкладывал? это как я понимаю только на спектр, а мельдаун?


              1. willyd
                06.01.2018 05:19

                gcc spectre.c -o spectre
                а то собранный эксплойт запускать у себя как-то боязно. не?


            1. Aqel
              06.01.2018 03:47

              И что с этим делать, есть готовое решение? То есть .exe файл для теста или исправления?


    1. Fearen
      03.01.2018 17:54

      Второе предложение в статье:

      Уязвимость затрагивает все процессоры Intel за последние лет десять как минимум.


      1. kafeman
        04.01.2018 13:17
        +1

        Как минимум с 1995-ого (источник).


  1. Barma2012
    03.01.2018 13:40

    Эх, вот не зря процы AMD мне всегда были более симпатичны, чем Intel )))))


    1. yurisv3
      03.01.2018 13:42
      +2

      Зашел увидеть этот коммент.


      1. evil_random
        03.01.2018 14:09
        +2

        Зашёл увидеть этот коммент.


      1. samodum
        03.01.2018 14:30
        -1

        Зачем это писать?


        1. RootHub
          03.01.2018 14:34
          +3

          они забыли что они не на Pikabu


          1. ITMatika
            04.01.2018 15:16

            А что такое Pikabu?


            1. DrPass
              04.01.2018 15:19
              +4

              Крупный научно-популярный портал Рунета.


        1. evil_random
          03.01.2018 16:19

          А зачем это писать? Тут вся ветка бессмысленная начиная с первого комментария.


          1. samodum
            03.01.2018 23:16

            Это точно не пикабу или фишки?


            1. devalone
              04.01.2018 16:24

              Никто не шутит про 49.5, не считает секунды и не кидает сиськи, поэтому нет, не пикабу.


          1. Psychosynthesis
            04.01.2018 02:06

            Извините, но к чему это вы?


    1. Tertium
      03.01.2018 14:08

      Да не, это от бедности нашей :)


      1. Barma2012
        03.01.2018 14:30

        Не обязательно. )))
        Скорее всего потому, что AMD — это не Intel. Поддерживать не флагмана, а его ближайшего конкурента — мне кажется, это правильно.


        1. ton1
          03.01.2018 15:36

          Viva la revolucion! Viva la Evolucion!


        1. vconst
          03.01.2018 15:36

          Если решение продиктовано не технологией, а идеологией — нет, не правильно.


          1. Areso
            03.01.2018 16:08
            +2

            С точки зрения потребителя, имеющего долгосрочную стратегию, с позиции маркетинга — это правильное решение.
            Ведь поддерживая флагмана можно получить монополию (поскольку конкурент умер, потому что его не покупали из-за того, что он не добрал каких-то N% в каком-нибудь бенче).
            А относительно технологии: припой под крышкой (не все любят риск и пойдут на скальпирование), разблокированные множители из коробки без доплаты производителю процессора, долгая поддержка сокетов (а не почти каждый год по новому, не совместимому сокету), отсутствие IME… Уверен, фанаты AMD смогут привести еще что-то полезное, сам пользуюсь Intel, но за каждый успех AMD я искренне радуюсь.


            1. sumanai
              03.01.2018 17:17

              отсутствие IME

              Не актуально.


              1. Areso
                03.01.2018 17:20

                Да, с Ryzen AMD вроде как внедрили аналог. Но сколько лет они сопротивлялись такому искушению)


                1. V1tol
                  03.01.2018 21:38

                  Кстати, на некоторых материнках под Ryzen его можно отключить )


                  1. navion
                    04.01.2018 07:53

                    Для Интела это тоже начинают вводить.


                    1. YuriM1983
                      04.01.2018 08:44

                      Пофиг. Достаточно использовать другую сетевую карту и уязвимости нет.


                      1. Tyrauriel
                        04.01.2018 10:20

                        Почему МЕ не может выйти в сеть через другую сетевую карту?


                        1. YuriM1983
                          04.01.2018 17:49

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


                          1. icCE
                            04.01.2018 21:50

                            Драйвера в другой ОС или ThreadX в Minix 3 который уже на ARC.


                            1. YuriM1983
                              04.01.2018 23:47

                              Спор ради спора.
                              Народ пробовал, не работает. Ни AMT/ME, ни уязвимость.
                              Официальный ответ интела такой же:
                              communities.intel.com/thread/114211


                              1. icCE
                                05.01.2018 01:09

                                а теперь набираем полной грудью воздух и скажите мне, в каком месте используются драйвера в intel AMT, когда на ПК нет ОС и я ее удаленно устанавливаю?


                                1. Tyrauriel
                                  06.01.2018 16:12

                                  В UEFI. Скорее всего там не будет драйвера на стороннюю сетевую карту.

                                  Но Intel ME это не только ценный мех, это еще и драйвер в операционной системе, которой является доверенным для любого антивируса.

                                  Чистая спекуляция.
                                  Что мешает получить нужные данные аппаратно, передать их драйверу intel me, тот вызовет драйвер сторонней сетевой карты и передаст по сети.


                  1. grozaman
                    04.01.2018 13:23

                    На большинстве, что обновляют. Возможность отключать добавили с последним обновлением AGESA.


                  1. h0t_max
                    04.01.2018 16:24

                    К сожалению, отключить полностью нельзя, как и в случае с МЕ.


                  1. kharkevich
                    04.01.2018 16:24

                    Судя по всему (http://blog.programster.org/stabilizing-ubuntu-16-04-on-ryzen) отключать нужно и многое другое


            1. Hardcoin
              03.01.2018 17:33

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


              сам пользуюсь Intel

              Об этом и речь. Хорошо, когда кто-то поддерживает конкурента, что б выбор оставался. Но самому-то разумно выбирать лучшее.


              1. evocatus
                03.01.2018 17:54

                То, что делает NVidia — это типичный захват рынка, который приведёт к монокультуре и монополии, а это плохо. Intel имела такое же положение на рынке процессоров — и вот результат.


              1. Areso
                03.01.2018 18:37
                +1

                Интересный ник. Глядя на него, мне вспомнилось…
                как мы с товарищем купили одновременно видеокарты в 2011 году. Он — AMD, я — nVidia. Он пошел майнить (благо у него совершенно случайно торчали провода от подъездного освещения в квартире), а я пошел ставить Linux и первые Linux игры, потому что майнинг на 560 Ti уже тогда смысла не имел (в отличие от AMD, что он купил за те же деньги). Сегодня у него квартира, машина и дача под Киевом, а у меня — как часы работающий Linux на nVidia и 230 Linux-совместимых игр в библиотеке.


                1. Barma2012
                  03.01.2018 21:14
                  +1

                  Сегодня у него квартира, машина и дача под Киевом

                  Это всё он намайнил за 6 лет на одной видеокарте?


                  1. tangro
                    03.01.2018 21:54
                    +1

                    В 2011 году на обычной видюхе можно было майнить 1 биткоин в день. В теории, если кто-то этим тогда занялся основательно и не повёлся на несколько волн паники в разные времена — то да, можно было и намайнить на одной видюхе.


                    1. Dmitry_Dor
                      04.01.2018 02:23
                      +1

                      В 2011 году за цену 560 Ti можно было купить четверть тысячи биткойнов, и если не повестись на несколько волн паники в разные времена, то безо всякого майнинга (и вообще без видюхи) сейчас можно было бы купить квартиру (в Лондоне), (автопарк) машин, и дачу (на Лазурном берегу).


                      1. Tsimur_S
                        04.01.2018 13:01

                        Можно, но это несравнимые вещи. То что вы описываете — это целенаправленная инвестиция и мало кто на такое отважился в 2011. А купить карту которая в любом случае нужна и майнить по ночам биткоины это другое. Потом достаточно было забыть о кошельке с десятком биткоином лет на 6 и однажды найти приятным бонусом $100 000.


                  1. Areso
                    04.01.2018 06:15

                    Ну, разве вы не в курсе, как это делалось? Покупалась видеокарта, отбивалась ее стоимость, продавалась. Покупалась предтоповая. Потом еще 1. Потом еще 1. Потом выходило новое поколение, они менялись. Потом у него был ASIC, вложения в который он также отбил. И все это на фоне условно-бесплатного электричества.
                    Понятно, что и у меня сегодня стоит не та же видеокарта, что и 6,5 лет назад.
                    Я просто к чему эту историю привел — вот, у нвидии есть PhysX, CUDA-вычисления и ML, а у AMD Radeon было и есть преимущество в фарме различных монеток.


                    1. alexs0ff
                      04.01.2018 08:18

                      del


                1. asoukhoruchko
                  03.01.2018 23:36

                  Вы понимаете, что оценка «лучше/хуже» вообще не применима без уточняющих вопросов? К примеру, под ваши цели видеокарты nVidia действительно подходили гораздо лучше.
                  А то, что получилось у вашего приятели подпадает под выражение «знал бы прикуп — жил бы в Сочи». И никакого отношения к качествам железа не имеет, если быть объективным.


                1. equand
                  04.01.2018 02:33

                  Чушь какая-то, еще в 2013 можно было майнить на 9600 радеоне по 0.3 битка в месяц, в 2011 без проблем можно было майнить даже соло хоть на кофейной машинке. Биткоин только зарелизился в паблик.


                1. maaGames
                  04.01.2018 07:39

                  Допустим, вы бы тоже купили AMD. У вас в квартире были провода, чтобы ВОРОВАТЬ электричество? Как-то часто разговоры о гигантских заработках на майнинге сводятся к «бесплатной» розетке, а по сути к воровству электроэнергии и/или оплате этой электроэнергии всеми жильцами дома. С тем же успехом можно гоп-стопить в подъезде, у каждого проходящего требуя по 100 рублей в день.)


                  1. Areso
                    04.01.2018 07:48
                    +1

                    Понимаете, это лишь влияет на окупаемость. Т.е. капитальные затраты (железо), операционные затраты на майнинг (электричество), операционный доход (продажа монеток). С ценой электричества, отличной от нуля, срок окупаемости растет, но с учетом невысоких цен на электричество (в сравнении с Германией/США, где тоже майнили монетки), это все равно было выгодно.
                    Ну и мой товарищ потом в качестве компенсации проспонсировал
                    работы по благоустройству, подарив приличную сумму денег их УК.
                    P.S.: сравнивать воровство, которое имело место быть в примере, и грабеж/разбой, ну даже не знаю...


                    1. maaGames
                      04.01.2018 07:52

                      Лишь? Хотя, в те года сложность майнига была ниже, это сейчас на большинстве карт майнинг будет в минус…
                      Если товарищ «компенсировал», то хотя бы не такой он падла, как выглядело из первого комментария. Хорошо, что вы уточнили, что он не совсем «сволочь со сволочной начинкой, облитый сволочизмом»(с). С другой стороны, мог бы просто из своей розетки питаться. Но это всякие глупости про облико морале.


                    1. alexs0ff
                      04.01.2018 08:22

                      качестве компенсации проспонсировал
                      работы по благоустройству, подарив приличную сумму денег их УК.

                      А чем он тогда отличается от типичного депутата? Сначала обваровывает всех (используя привилегерованные условия) — наживается на этом. А потом в качестве «доброй воли» делает спортивную площадку детям.


                      1. Areso
                        04.01.2018 08:25

                        Тем, что вернул больше, чем украл.


                        1. alexs0ff
                          04.01.2018 08:57

                          Не пойдет. Ключевое слово «украл». Если бы заработал честно и потом еще сделал добрые дела — тогда честь и хвала. А так я говорю — типичный чиновник с привелегиями.

                          А вот если бы с майнингом не вышло — вернул бы? что-то я сииильно сомневаюсь.


                          1. Areso
                            04.01.2018 08:59

                            Кому-то совесть позволяет красть, кому-то нет. Тем более, в массовом сознание нынче красть не зазорно — зазорно попасться. Мораль, честность, считается большинством ненужными пережитками, откровенно мешающими жить.


                    1. geher
                      05.01.2018 15:43
                      +2

                      Украл у соседей, которые оплачивали ОДН, а проспонсировал УК?


                  1. DrPass
                    04.01.2018 11:10

                    Как-то часто разговоры о гигантских заработках на майнинге сводятся к «бесплатной» розетке, а по сути к воровству электроэнергии и/или оплате этой электроэнергии всеми жильцами дома

                    А это неправда. Я не буду брать в расчет Европу, но например в Украине я ради интереса прошлой весной дома запустил майнинг эфирок на достаточно бывалой Radeon 7950. Чистый доход был порядка $8/месяц. С одной, достаточно прожорливой видеокарты. И это просто на эфирках по курсу примерно $50. Сколько там они стоят сейчас, $950? Вот если бы я их тогда не продал, я бы уже заработал с месяца майнинга $150. По-моему, вполне окупаемое занятие, не правда ли?


                    1. maaGames
                      04.01.2018 11:50

                      Эммм, нет. Потому что тогда — не сейчас. Ведь сейчас не по 150 долларов майнится чистыми, а те же условные 8, из-за выросшего курса. Опять же, прост окупив эфир по 50 тогда и продав сейчас по 950… Но это уже совсем оффтоп.)


                      1. Areso
                        04.01.2018 12:46

                        Понимаете в чем разница. Купив за деньги железку, вы получаете через пару месяцев (деньги И/ИЛИ коины) и железку на выходе.
                        А купив за деньги коины, вы получаете на выходе коины. Без железок, без денег.
                        Вероятно, потом, когда-нибудь, их можно будет продать с неким наваром, а вероятно и нет.
                        Поэтому люди массово уже тогда майнили, а покупать массово коины не покупали.


                      1. DrPass
                        05.01.2018 07:15

                        Эммм, нет. Потому что тогда — не сейчас. Ведь сейчас не по 150 долларов майнится чистыми, а те же условные 8, из-за выросшего курса.

                        Если нужно подобрать формально определение процессу, то да, наверное вы правы. Если же мы говорим о «выгодности майнинга», то суть в том, что вы потратили десять долларов за электроэнергию, а на выходе через полгода получили $150. И неважно, что значительная часть этой суммы отбита за счет роста курса криптоденюжки. Вы-то ничего для этого не делали, просто майните и ждете. Тем более что вообще нет смысла рассматривать доход от майнинга в отрыве от курсового дохода, учитывая нестабильность курсов криптовалют, и что этот самый курс десять раз изменится, пока вы майните 0,1 эфирку. Это два тесно связанных процесса в одном и том же бизнесе.


                    1. Barnaby
                      04.01.2018 13:45

                      Radeon 7950. Чистый доход был порядка $8/месяц.

                      Сейчас она почти $50 майнит. Карты все еще актуальны, хотя на них еще лайт с догами майнили.
                      В РФ электричество тоже дешевое и цены на него растут медленно. Например с тех пор как рубль подешевел в 2 раза у меня тариф на 40% подняли — в реальности стало еще дешевле.


                      1. saboteur_kiev
                        04.01.2018 16:35

                        Как бы весь этот тред вернуть в русло статьи?

                        Ну например — можно же потерять доступ к своему биткоин кошельку, случайно зайдя с майнинговой машины на левый сайт?


                1. zhukoffdenis
                  04.01.2018 18:27

                  Кто победил-то?


                  1. Areso
                    04.01.2018 18:38

                    Знаете, это история с открытой концовкой, и оба случившихся варианта имеют свои плюсы и минусы. Настоящая жизнь — не черно-белый мир. Каждый может решить для себя.
                    Если бы я мог отыграть назад и знать, что и как будет, я бы сделал как выше уже предложили — купить 250 битков и положить их в дальний угол. "Знал бы прикуп, в Сочи жил".
                    Как было бы правильно: купить AMD Radeon, а на намайненное (пусть и дольше, у меня "случайно" провода от подъездного освещения в квартиру не заходили) купить для nVidia 560 Ti, и осталось бы немного битков. В запас. Хоть экономика моя была бы и хуже, чем у товарища — наличие операционных затрат, трата на стороннее железо вместо реинвестирования. Зато совесть была бы чиста и в библиотеке у меня также бы водились Linux игры, а в карманах бренчали бы [s]биткоины[/s] кэш.


                    1. Stalker_RED
                      04.01.2018 21:12

                      биткоины
                      Вместо

                      [s]
                      используйте
                      <s>


                    1. Moog_Prodigy
                      05.01.2018 17:58

                      Я подозреваю, что даже в случае не воровства э\э оно бы окупилось. Так что про провода это лишние подробности. А так да, предыдущие ораторы все сказали верно, в том числе и про «прикуп в сочи».


            1. vconst
              03.01.2018 19:01

              Такие перспективы интересуют только большие корпорации, обычному пользователю надо лучше и быстрее прямо сейчас, а не через 20 лет.


      1. Dessloch
        04.01.2018 04:35

        Почему же от бедности? Это называется экономика) Я стал «фанатом» AMD после того как Intel облапошила с Hyper-threading, это стало своего рода принципом. И вот оно, вознаграждение за принципиальность)


        1. tbl
          04.01.2018 04:45

          Где можно узнать про то, что не так с hyperthreading? Помимо сегодняшнего, я из интеловских крупных хардварных багов я только про FDIV и Netburst знаю.


          1. m_a_p_a_c
            04.01.2018 18:27

            Подробно было тут:
            «Replay: неизвестные особенности функционирования ядра Netburst»


            1. a5b
              04.01.2018 19:02

              https://fcenter.ru/online/hardarticles/processors/12033-Replay_neizvestnye_osobennosti_funkcionirovaniya_yadra_Netburst "Replay: неизвестные особенности функционирования ядра Netburst" 25.02.2005


              Почему, несмотря на более высокую тактовую частоту и широко разрекламированные маркетинговым отделом Intel архитектурные особенности Net Burst (такие, как Trace Cache, Rapid Execution Engine, Quad-Pumped Bus, Hardware prefetch и даже Hyper-Treading), призванные увеличить число команд, исполняемых за такт, процессоры Pentium 4 умудряются часто проигрывать своим менее частотным собратьям и конкурентам в лице семейств Pentium M и AMD Athlon?

              С тех пор HypedThreading переделали...


              1. shurix83
                04.01.2018 20:57

                Ну, Dessloch вспоминает практически единственный случай, когда АМД со своими процами с открытыми кристалами обскакали Интел с их Пентиумом 4. Современную ситуацию с Ryzen не рассматриваю — как по мне, так еще рано анализировать, кто в этом раунде победил.


                1. Areso
                  05.01.2018 05:35

                  Если смотреть на Steam HW Survey, то связка Intel+nVidia. У Intel/AMD было 80/20, стало 91/9, с графикой еще более эпично. AMD с 24% скатился до 9%.


                  1. Dessloch
                    05.01.2018 13:27
                    +1

                    Сравнивая производительность Intel-AMD не стоит забывать про стоимость. Опросил несколько своих коллег-на работе все фанаты Intel, но дома у всех AMD. Вот так.


    1. Vorber
      03.01.2018 17:54

      Зря или не зря, но вот жрать последствия (судя по тексту новости) будут все пользователи, которые не собирают ядра вручную. Может конечно позже появится патч который будет работать избирательней, но тут именно, что «может».


      1. NiTr0_ua
        03.01.2018 20:23

        kpti отключается в параметрах ядра вроде как…


      1. Arekusei
        04.01.2018 18:27

        Патч уже имеется. В рассылке и новостях различных ресурсах упоминается так же.


    1. unwrecker
      03.01.2018 22:49

      При всей любви к AMD нельзя забывать об аналогичном факапе с первым Феномом: там хоть ошибка была связана не с безопасностью, а с арифметикой, но исправление через микрокод тоже существенно снижало производительность.


      1. Lennonenko
        04.01.2018 20:01

        это исправление заключалось в банальном отключении TLB, в котором была ошибка
        быстренько выкатили вторую ревизию, но первая успела разойтись, например, у меня на одной из машин стоит этот феном, и он даже с выключенным TLB изрядно нестабилен


    1. icCE
      04.01.2018 04:20

      Скорее всего AMD подвержена одной из двух уязвимостей.
      ARM уже честно отчитался — developer.arm.com/support/security-update
      Intel написала извините откровенную хуйню — newsroom.intel.com/news/intel-responds-to-security-research-findings

      Осталось еще вспомнить, что внутри intel есть еще arc процессоры под управлением ThreadX или minix 3, с которыми в общем мало, что понятно. Но там видимо своя дискотека.


      1. VlK
        04.01.2018 12:20

        На сайте с описанием уязвимости (https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html) указаны 3 варианта атаки, опирающихся на две уязвимости.

        Насколько понимаю, Интел подвержен всем, и еще ничего не исправлено, АМД же подвержен одной, самой слабой, и это пофиксили еще в осенних обновлениях прошивок.


        1. icCE
          06.01.2018 16:07

          >АМД же подвержен одной, самой слабой, и это пофиксили еще в осенних обновлениях прошивок.

          Spectre довольна серьезная ошибка. Мы еще с ней щей хлебнем. (из которых найдено две )

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


  1. alexkuzko
    03.01.2018 13:50

    Эпично. Вот теперь вопрос почти религиозный: можно ли гарантировать то, что патч НЕ будет установлен? Т.к. многие будут готовы пожертвовать гипотетической безопасностью ради существенного прироста (точнее, сохранения того что было) скорости.


    1. mad_celt
      03.01.2018 13:54

      Отключается в конфиге ядра.


      1. alexkuzko
        03.01.2018 13:56

        Я именно про осознанное отключение, инициированное пользователем. В маках или винде, насколько легко будет отключить? С линуксом-то понятно, хотя вопрос остается: будет ли эта настройка явно выведена где-то в дистрибутивах (в интерфейсе гнома, кде и т.п. синнамонов)?


        1. leggiermente
          03.01.2018 17:03

          Представил апплет с единственным Switch button «Security/Performance». А ещё лучше — отдельный тумблер на клавиатуре.


          1. PapaPadlo
            03.01.2018 17:08

            Заголовок спойлера
            image


            1. BubaVV
              03.01.2018 17:44
              +1

              Security включается правой кнопкой


            1. Exchan-ge
              03.01.2018 17:53

              О, мой первый системник.
              Спасибо за фото!


              1. Dvlbug
                04.01.2018 19:48

                А что делал замок? У меня был такой корпус, но был подростком и за попытку проверить оторвали бы голову.


                1. Lennonenko
                  04.01.2018 20:04

                  физически разрывал один из контактов в разъёме клавиатуры


          1. Akuma
            04.01.2018 14:14

            .


          1. Serge3leo
            05.01.2018 02:17

            В данном случае, не вопрос. Если я правильно понял методы атаки, сделать, как два пальца об асфальт. Аплет включает и выключает «Time Stamp Disable (bit 2 of CR4)» ;)


        1. pda0
          03.01.2018 17:52

          KPTI can partially be disabled with the «nopti» kernel boot option.
          en.wikipedia.org/wiki/Kernel_page-table_isolation


        1. fedison
          03.01.2018 17:55

          В тех же играх 30% сильно скажется, поэтому очень даже интересно, предусмотрят ли отключение в винде


          1. kekekeks
            03.01.2018 22:43

            30% там на syscall-heavy сценариях. Игры же в основном упираются в GPU, сисколов там не сильно много.


            1. DistortNeo
              03.01.2018 22:57

              То есть обычный процесс взаимодействует с видеокартой, минуя ядро?


              1. a5b
                03.01.2018 23:56

                Для вызовов отрисовки — да — http://dri.sourceforge.net/doc/dri_control_flow.html, см стрелки в обход kernel: Direct rendering program (3D):
                Direct rendering (3D data) -> 3D data -> Graphics Hardware


                https://en.wikipedia.org/wiki/Direct_Rendering_Manager / https://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure


            1. Mairon
              04.01.2018 02:11

              а если игра на новомодных vulkan, metal и d3d12?


              1. equand
                04.01.2018 02:36

                Там нет сисколлов, прямая работа с железом.


        1. Alcpp
          03.01.2018 23:36

          Учитывая, что это позволяет стороннему процессу чтение паролей и прочей секьюрной инфы в памяти, то думаю отключить будет невозможно. По крайней мере в пользовательских ОС.


    1. sumanai
      03.01.2018 13:57

      А куда они денутся? В десятке не так то просто от чего-то отказаться. Да и ядро люнукса не каждый скомпиляет.


      1. KivApple
        03.01.2018 16:29

        Вроде как ядро Linux перекомпилировать не придётся. Хватит отредактировать конфиг загрузчика, чтобы передать нужную опцию в качестве параметров ядра.


      1. evocatus
        03.01.2018 17:39

        Можно будет выключить через реестр Windows

        twitter.com/aionescu/status/930496352781340672


    1. runalsh
      03.01.2018 13:58

      Судя по коду на гите, изоляцию можно отключать.

      + pti= [X86_64]
      + Control user/kernel address space isolation:
      + on — enable
      + off — disable
      + auto — default setting


    1. famiak
      03.01.2018 14:03

      Вопрос не праздный: падение производительности на моем стареньком Core2Quad мне совсем не нужно, а мифическая уязвимость в области виртуальных машин и прочего тревожит не сильно.


      1. sHaggY_caT
        03.01.2018 14:21

        Виртуальные машины тут ни при чём скорее всего. Возможно, будут и javascript эсплойты, через браузер.


        1. bro-dev
          04.01.2018 05:31

          Даже если так, то я готов чтобы браузер работал медленнее, а не весь комп.


          1. willyd
            04.01.2018 12:42

            Могут найти способ провести атаку и не через браузер.
            Нужно лечить болезнь, а — не симптомы.


        1. iShatokhin
          04.01.2018 21:47

      1. Victor_koly
        03.01.2018 15:08

        Инфа секретная — почти любому Core 2 Quad уже больше 10 лет. Уточню — я предполагаю, что все Yorkfield существенно не отличались этим от QX9650 и не могли ещё содержать такого бага.
        Про совет ниже — если термин «виртуальная машина Java» относится к указанным проблемам, то снесите Java со своей Винды:)


        1. EnigMan
          03.01.2018 16:01
          +1

          Мне кажется, народ неверно понимает причины упоминания виртуализации. Как я понял, зловред сможет получить доступ к памяти ядра процессора. И не важно, есть у вас виртуальные машины на компе или нет. Для владельцев ферм виртуальных машин опасность в том, что они не контролируют, что там запускают пользователи на арендованных мощностях, а те могут получив доступ к памяти ядра получить данные (повлиять?) других виртуальных машин или хост-системы.


          1. Victor_koly
            03.01.2018 21:11

            Да, с такой фигней согласен. Хотя не читал конкретного описания бага в контексте виртуализации.
            Действительно ли именно из виртуалки есть возможность получить доступ к памяти ядра хоста? Конечно, если скажем виртуалка сможет передать какой-то код через драйвер сетевой карты, а Вы разрешили этой виртуалке как минимум доступ к каким-то папкам на запись. В теории возможная функция для тех же хостингов или никто так не делает (максимум — создаст такой доступ через какую-то другую виртуалку, правда не знаю, какую сетевую инфраструктуру можно создать в таком случае в виртуальной среде)?


            1. equand
              04.01.2018 02:37

              С любого запущенного кода.


    1. DrPass
      03.01.2018 15:26

      Т.к. многие будут готовы пожертвовать гипотетической безопасностью ради существенного прироста

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


      1. Alexey2005
        03.01.2018 18:09

        Тогда почему бы не попросить всех причастных молчать и дальше? Неужели нельзя обойтись без публикации подробностей? Ведь если уязвимость настолько неочевидна, что её 10 лет не могли найти, то без публикации кода потенциальные злоумышленники ещё лет 7 провозятся как минимум. Зачем упрощать им задачу?


        1. creker
          03.01.2018 18:15

          Как по мне, подробности уязвимости помогут исследователям. Каждая подобная хитрая уязвимость это идея другим исследователям, где им стоит искать, и о чем они могли даже не думать раньше. Прочитает человек, решит поискать в процессорах других архитектур, а там окажется что-то похожее.


        1. mikelavr
          03.01.2018 18:45
          +1

          en.wikipedia.org/wiki/Security_through_obscurity

          Это мнимая безопасность. Информация тем и отличается, что ее дублирование происходит незаметно для оригинала.


        1. worldmind
          03.01.2018 18:55

          Нашли одни, найдут и другие, тем более держать в секрете сложно, там небось целая орда анализом причин занималась.
          А как только будут патчи, то уже ничего скрывать — по коду разберутся.


        1. ekungurov
          04.01.2018 02:43

          Патамушта.


      1. jcmvbkbc
        04.01.2018 07:47

        Патчи, по крайней мере линуксовые, делают настолько общие вещи, что ничего не говорят о деталях уязвимости. В отличие от статей: meltdown, spectre.


    1. Mixaill
      03.01.2018 17:55

      для Linux можно просто передать ядру параметр nopti, с другими ОС пока ничего не ясно.

      В целом, всё не так страшно. В играх, например, просадки может не быть вовсе
      www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests


      1. Soul_in_Gun
        03.01.2018 20:09

        тест не самый лучший ибо используется свежайший Coffee Lake, для которого есть смягчающий импакт фактор. Вот если бы там было что-то типа i7-2600k, который явно проиграет сильнее всего…


        1. AbnormalHead
          03.01.2018 20:54

          <sarcasm_on>

          i7-2600k, который явно проиграет сильнее всего…

          Можно уже включать режим теории заговора, и утверждать что производитель подталкивает к замене процессора?
          <sarcasm_off>


          1. Soul_in_Gun
            03.01.2018 22:07

            Да нет, почему-же. Процессор до сих пор держится на уровне i5-7400 в «попугаях» многоядерной производительности и вполне справляется с «офисными» задачами и почти вытягивает современные игры в паре с какой-нибудь 1070 (при этом правда подбираясь к 100% загрузке почти вплотную в супертяжёлых релизах) — просто интересно насколько более старые, но актуальные mid-highend процессоры из второго-третьего поколения получат урона относительно более свежих — в таком случае возможно и ставить патчи смысла нет, а проще будет сразу менять платформу на свежее, благо что так или иначе эти процессоры уже подходят к границе «пора менять»


        1. sumanai
          03.01.2018 21:58

          По крайней мере в i5-3570 поддерживает PCID.


          1. faultedChip
            04.01.2018 18:29

            i5-4570 не поддерживает, а он вышел позже.


            1. sumanai
              04.01.2018 18:33

              Странно. Я смотрел в АIDA64.


              1. faultedChip
                05.01.2018 00:18

                Сейчас проверил в AIDA64 — всё равно пишет что не поддерживается. Видимо какие-то особенности линеек Intel'а.


                1. sumanai
                  05.01.2018 00:33

                  На всякий случай уточню: индекс K есть?


                  1. faultedChip
                    05.01.2018 00:38

                    Нет.

                    Intel® Core(TM) i5-4570 CPU @ 3.20GHz


                  1. iDm1
                    05.01.2018 03:17

                    На всякий случай в 4770K точно есть PCID.


                    1. sumanai
                      05.01.2018 03:35

                      Да уж. Либо у faultedChip какие-то особенности, либо распределение фич у Intel не содержат в себе никакой логики.


            1. Darknet
              05.01.2018 00:51

              HWiNFO64 показывает поддержку PCID в i5-4570S, скрипт от Майкрософта подтверждает:

              Windows OS support for PCID optimization is enabled: True


              1. faultedChip
                05.01.2018 03:43

                Могу скриншот привести. Я проверял и самописным скриптом через CPUID(EAX=1) и AIDA64 — в обоих случаях результат один (у меня процессор просто i5-4570, без S)


              1. faultedChip
                05.01.2018 04:00

                Извиняюсь за недостоверную информацию: гипервизор меняет значения CPUID, отключая в том числе PCID — при выключенном Hyper-V результаты совпали с вашими.


          1. kxx
            04.01.2018 21:40

            На 3470, похоже, тоже поддерживается PCID.

            i5-3470
            image


  1. LaFleur
    03.01.2018 14:01

    мало информации.
    про какие процессоры речь? все core i? пни? селероны? каких поколений/годов выпуска?
    какие ОС? та же XP уже ведь того…
    можно ли будет отказаться от патча? ведь если есть старенький, например, селерон, который работает почти на пределе, то такой патч забрав себе эти гипотетические 30% производительности может совсем привести к необходимости срочного апгрейда машины


    1. sumanai
      03.01.2018 14:58

      та же XP уже ведь того…

      Авось опять выпустят фикс, на крайняк от встраиваемых систем подойдёт.


    1. deimos_lt
      03.01.2018 17:55

      Простите, но разве работа на пределе не является индикацией для срочного апгрейда машины?


      1. maaGames
        04.01.2018 07:58

        Работа ПОЧТИ на пределе — индикация сбалансированной системы. А вот если компьютер простаивает, то была переплата за ненужные мощности. Но это если формально к вопросу подходить. А по факту, я тоже предпочитаю недогружать, чтобы кулерами не шелестели.


      1. Victor_koly
        04.01.2018 11:32

        Есть люди, которые верят, что для процессора является нормой работа на Tjunction как минимум 8700 часов в год.


      1. fedorov97
        04.01.2018 18:29

        Думаю, не является, если пользователю хватает скорости/возможностей, поэтому сейчас срочный апгрейд не нужен.


    1. Exchan-ge
      03.01.2018 17:59

      может совсем привести к необходимости срочного апгрейда машины

      Вы нашли самую суть и скрытый смысл данной проблемы )


      1. vconst
        03.01.2018 19:03

        Это заговор…


        1. Exchan-ge
          04.01.2018 18:33
          -1

          Это заговор…


          Да ну, какой там «заговор».
          В 1995 году еженедельник «Компьютерное обозрение» перепечатал откуда-то опрос представителей десятка крупнейших компьютерных фирм того времени на тему «Каким вы видите процессор 2005 года?» (не дословно)
          Я, по тогдашней своей привычке, вырезал эту статью и сохранил ее в тематической папке.
          Как раз в 2005 году, в связи с предстоящим ремонтом — я случайно наткнулся на эту, давно забытую папку, и снова прочитал этот прогноз.
          Из тех компьютерных фирм к 2005 году осталось меньше половины. Прогнозы всех специалистов прошли мимо цели — кроме одного, сделанного представителем Интел.
          Он, в 1995 году — точно описал параметры Р4 Prescott — тактовую частоту, количество транзисторов на чипе, размер кэша и применяемый техпроцесс.

          (В случайные совпадения я не верю )


          1. dimm_ddr
            04.01.2018 19:07

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


            1. Exchan-ge
              05.01.2018 16:36

              что спец смог предположить


              Я сам инженер, до известных событий 90х занимался разработкой и внедрением не менее интересных и сложных изделий, чем процессоры.
              10 лет — это как раз тот срок, на который планируется разработка и внедрение чего-то реально нового в производство. При этом обычно уже известно, что это будет и как именно будет работать.
              Упомянутая статья — всего лишь одно из подтверждений того, что этот процесс «на Западе» происходит точно также, как это было у нас (есть еще масса интересных косвенных сведений в издававшемся тогда журнале «В мире науки»).

              Процессор с кодовым именем Willamette впервые появился в официальных планах компании Intel в октябре 1998 года, хотя его разработка и началась вскоре после завершения работ над процессором Pentium Pro, вышедшим в конце 1995 года, а название «Willamette» упоминалось в анонсах 1996 года… Предполагалось, что Willamette выйдет во второй половине 1998 года, однако, в результате многочисленных задержек анонс был перенесён на конец 2000 года. В феврале 2000 года на форуме разработчиков Intel (IDF Spring 2000) был продемонстрирован компьютер, основой которого служил инженерный образец процессора Willamette, получившего наименование «Pentium 4» (с) Вики


              1. dimm_ddr
                06.01.2018 13:50

                Я сам инженер, до известных событий 90х занимался разработкой и внедрением не менее интересных и сложных изделий, чем процессоры.

                Вы занимались не процессорами, следовательно я не вижу причин почему ваш случай можно продолжить на процессоры. "Не менее сложные и интересные" — весьма слабая характеристика. И даже так ваш комментарий никак не противоречит возможности для крутого спеца реально предсказать направление разработки на 10 лет вперед.


                1. Exchan-ge
                  06.01.2018 17:37

                  Вы занимались не процессорами, следовательно я не вижу причин почему ваш случай можно продолжить на процессоры


                  Потому что процесс разработки и внедрения в производство зависит только от степени сложности выпускаемого изделия, а не от его конструкции и назначения. Этапы разработки будут одинаковыми.
                  Даже избыточное финансирование и широкое применение ВТ не дает существенного ускорения, так как в реале все зависит от человека (коллектива), а его возможности ограничены.

                  возможности для крутого спеца реально предсказать направление разработки на 10 лет вперед.


                  Вы читали вторую цитату в предыдущем сообщении?
                  Там все написано прямым текстом — никакого «предсказывания» не было, человек поделился реальными планами Интел (в 1995 это еще случалось )


                  1. wych-elm
                    06.01.2018 17:45

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


  1. igentuman
    03.01.2018 14:08

    Ждем первых эксплойтов


    1. Alex_ME
      03.01.2018 14:09

      Возможно, они уже давно существуют, если уязвимость такая старая.


  1. Alex_ME
    03.01.2018 14:09

    Немного оффтоп.
    Раньше не задумывался, но как вообще возможен доступ одного процесса в область памяти другого (или ядра) при наличии виртуальной памяти и независимых адресных пространств? Это касается не только этой уязвимости, но даже, к примеру, дебаггеров и того же ArtMany?


    1. yurisv3
      03.01.2018 14:42

      Что значит «независимых»? Физическая память одна. Мэпинг адресов и права прописаны в дескрипторах MMU, никто не мешает (в кольце 0) создать для разных процессов дескрипторы, адресующие одну и ту же (или с перекрытием) область.


    1. Victor_koly
      03.01.2018 15:20

      Попробуйте хакнуть ArtMoney процесс своего антивируса (хотя бы окна GUI).


    1. VBKesha
      03.01.2018 15:45

      Ну по поводу например AtMoney есть винлвые функции:
      msdn.microsoft.com/ru-ru/library/windows/desktop/ms680553(v=vs.85).aspx
      msdn.microsoft.com/ru-ru/library/windows/desktop/ms681674(v=vs.85).aspx
      Специально для этого сделаные.


  1. mikhaelkh
    03.01.2018 14:22

    Через 50 лет:
    Из-за уязвимости в чипах Intel, вживляемых в мозг, можно получить доступ к мыслям человека.


    1. ARD8S
      03.01.2018 14:56

      В некотором царстве, в некотором государстве, к тому времени у всех будут «правильные» чипы с таким функционалом «by design».


      1. BigBeaver
        03.01.2018 15:20

        «правильные»
        «православные»?


        1. ffs
          03.01.2018 17:27

          правда. живите по правде.


      1. dfgwer
        03.01.2018 15:24

        У всех будут, к сожалению


        1. PavelZhigulin
          03.01.2018 20:26

          «Кто ж на плюке поводу думает...»


          1. PavelZhigulin
            03.01.2018 20:27

            правду*


      1. j-ker
        03.01.2018 17:55

        Говорят, что в Москве кур доят. Их ловят, доят, а те не доятся — титек нет. таки УЖЕ есть соотв. закладки, прокладки и микрокод.


        1. sumanai
          03.01.2018 19:34

          Чёрт, чипов ещё нет, а закладки на них уже есть. Как же я отстал от жизни…


    1. SanekPlus
      03.01.2018 22:14

      Из-за закрытия уязвимости в чипах Intel, вживляемых в мозг, мы снизили вам производительность работы мозга на 30%. Не волнуйтесь, вы всегда можете взять ипотеку на новый чип.


  1. Captain_Sparrow
    03.01.2018 14:23

    Смотрю я тут описание обновлений биоса на свою материнку… Да это же история факапов интела. Опустим локальные баги и их исправления. И так:
    1. Ошибка «Prime95».
    2. Глючный Hyper-threading.
    3. Пробоина Intel ME.

    Бонус из будущего, не войдущий в обновление BIOS'а:
    4. Вот это вот всё это вот это из сабжа.

    Когда я был молод и студентом, был глуп, беден и велся на маркетинговый буллщит, и поэтому купил себе ноутбук на АМД/Радеон. Отхватив горячих выхлопов из радиатора зарекся больше иметь дел с АМД.

    И в связи с этим у меня к Интелу вопрос: какого мать его ты делаешь, Интел???..
    Благо, когда собирал десктоп, райзены были ещё только в фантазиях инженеров.


    1. Konachan700
      03.01.2018 14:30

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


      1. BlackMokona
        03.01.2018 16:15

        Вполне возможно, что уже 100 Васей продали, перед тем как её нашли добрые ребята


      1. leggiermente
        03.01.2018 17:24

        Современные процы настолько сложные, что баги в них просто невозможно отловить полностью, ни вручную, ни автоматикой. То ли еще будет.

        Очень верно замечено. Когда в процессоре сотни миллионов логических элементов, вероятность наличия одной или нескольких уязвимостей в нём очень близка к единице. Обнаружение критических уязвимостей в существующих процессорах — лишь вопрос времени и удачи (в теорверовском смысле).


        1. darkfrei
          04.01.2018 02:58

          Идея для стартапа с распределёнными вычислениями?


          1. dimm_ddr
            04.01.2018 12:57

            Майнинг уязвимостей. Если придумать алгоритм для распределения, то может даже сработать.


            1. EviLOne
              05.01.2018 03:18

              Подобный алгоритм есть у некоторых спецслужб.


      1. DEmon_CDXLIV
        03.01.2018 17:55

        Возможно что условный хакер Вася продавал эту уязвимость месяц-другой до обнаружения.


        1. 57ar7up
          04.01.2018 18:29
          +1

          А то и 10 лет


      1. Myxach
        03.01.2018 17:55

        Не факт, что у красных нет уязвимостей. Просто они намного менее популярны, вот и не ищут дыры в их процах так интенсивно.

        то-есть ситуация как с линуксом и вирусами?


        1. equand
          04.01.2018 03:37

          SPECTRE вообще все текущие CPU подвержены.


        1. sHaggY_caT
          04.01.2018 20:17
          +1

          то-есть ситуация как с линуксом и вирусами?


          Нет, это проблема дизайна Windows. Android популярнее, чем Windows, но массовые эпидемии про Windows а не Android.
          Поясню свою мысль: во всех операционных системах способы делать что-то удобно безопасные, а в Windows нет.
          Что делает стадартный Windows-пользователь? Гуглит «кряк $програмнейм», «драйвер $девайснейм». Что делает разработчик очередного говноприложения, быстро наклёпанного в Windows? Хранит всё, включая динамически меняющиеся данные, в %programfiles%\$program_name, в результате говноприложение, если юзеру повезёт, для своей работы требует прав на запись в свою папку, а если не повезёт, то и админских прав.

          Теоретически, в Windows есть все или почти все технологии безопасности. Есть даже мандатный контроль, вот только в Ubuntu большинство юзеров не отключает apparmor, многие не отключают в Федоре и других дистрибутивах SELinux, а в Windows почти никто не знает о существовании местного MAC, а многие отключают даже примитивный UAC (который со времён висты почти не стал лучше), работают под админом, итд. В Linux логиниться в десктоп энвайромент рутом просто неудобно.
          Я думаю, что Windows 10 с её технологиями была правильным ходом. Со временем, все Windows приложения перекочуют в Windows store вместе с популяризацией плиток, когда-нибудь допилят DAC/UAC и сделают популярным MAC, начнут паковать приложения в докер-контейнеры, которые под Windows уже есть. Тогда в Windows и прекратятся эпидемии. Всего лишь нужно не просто сделать технологии безопасности, их нужно сделать такими же удобными, как в других ОС.


          1. willyd
            04.01.2018 20:32
            +1

            многие не отключают в Федоре и других дистрибутивах SELinux
            Справедливости ради в Федоре, если не прилетели правила, то приложение будет в unconfined запускаться. Ну и теперь еще firefox в песочнице не запустить.
            А вообще, все правильно…


          1. Hellsy22
            04.01.2018 22:13
            -3

            Что делает пользователь линуксов, когда обнаруживает, что stable-версия приложения отстала лет на 5? Переходит на ~, после чего ему приходится перевести на ~ пару библиотек, а затем и пол-системы, потому как зависимости. Оттуда остается лишь один шаг до ** и установки напрямую.

            говноприложение, если юзеру повезёт, для своей работы требует прав на запись в свою папку

            Это уже почти стандарт — запись в свою инсталляционную директорию. А вот линуксовые приложения пишут куда попало, лишь бы хватало прав.

            многие отключают даже примитивный UAC

            Многие сидят под root-ом, что это доказывает-то?

            Linux логиниться в десктоп энвайромент рутом просто неудобно
            Не замечал каких-либо сложностей.

            Добавим сверху альтернативные репозитории, немодерируемые помойки типа сборника плазмоидов, отсутствие хоть какой бы то ни было ответственности и получим полную картину.


            1. sumanai
              04.01.2018 22:22

              Это уже почти стандарт — запись в свою инсталляционную директорию.

              Это требуется только при установке. Нормальным приложениям при работе права на запись в Program Files не нужны.
              Многие сидят под root-ом

              Кто например? Думаю, единицы.


              1. Hellsy22
                05.01.2018 02:50

                Кто например? Думаю, единицы

                — Во второй Мировой погибло 20 миллионов советских граждан
                — Кто например? Думаю, единицы.

                В каком формате вы представляете ответ на свой вопрос? Я с завидной регулярностью вижу, как люди или сидят под рутом, или у них sudo не требует пароля.


                1. sumanai
                  05.01.2018 03:38

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


                  1. Hellsy22
                    05.01.2018 10:09

                    На Raspbian sudo без пароля прямо по умолчанию. В других дистрибутивах отключение запроса пароля для sudo — одна строчка, даже проще чем выключить UAC.

                    image

                    Работа под рутом — тоже не проблема.
                    image

                    И объясняется это точно так же как и отключение UAC — нежеланием сталкиваться с какими бы то ни было подтверждениями.

                    Я вот не вполне понимаю, почему одни и те же люди зачастую упорно доказывают, что UAC с его диалоговым окном, кстати, показывающим подписано приложение или нет — это ужас-ужас-ужас, а точно такое же окно sudo — «никому не мешает». И уж совсем я не понимаю, почему система, в которой все завязано на одну сущность с абсолютными правами (root) считается более безопасной, чем система, где права разделены между разными сущностями (System, TrustedInstaller, Administrator и т.д.)

                    А уж тот печальный факт, что в части дистрибутивов нет даже ArmorApp и любое приложение может читать данные других приложений без уведомлений и подтверждений…


                    1. sHaggY_caT
                      06.01.2018 18:34

                      На Raspbian sudo без пароля прямо по умолчанию.


                      Там по-умолчанию логинятся в KDE/Gnome/XFCE под рутом? При чём тут консоль?

                      В других дистрибутивах отключение запроса пароля для sudo — одна строчка, даже проще чем выключить UAC.


                      Это сделано для серверов, для того, что бы можно было запускать автоматически без ввода пароля какой-либо скрипт, причём чаще даже не под рутом, а под специфическим юзером. На десктопе типичный юзер просто поленится это отключать, а для серверов права можно выдать именно на отдельный скрипт.
                      Если специально постараться, можно, конечно, и систему сломать с помощью rm -rf /*
                      Но ведь это специально нужно что-то делать! А В Windows опасные и десктруктивные юзерские и разработческие паттерны приняты по-умолчанию.

                      Я вот не вполне понимаю, почему одни и те же люди зачастую упорно доказывают, что UAC с его диалоговым окном, кстати, показывающим подписано приложение или нет — это ужас-ужас-ужас, а точно такое же окно sudo — «никому не мешает». И уж совсем я не понимаю, почему система, в которой все завязано на одну сущность с абсолютными правами (root) считается более безопасной, чем система, где права разделены между разными сущностями (System, TrustedInstaller, Administrator и т.д.)


                      во-первых, не один юзер, а множество. Считается довольно дурным тоном запускать демоны под рутом: обычно демоны работают под своими собственными юзерами, а во-вторых, мандатный контроль, который большинство юзеров Убунты не отключает(Apprmor прекрасно работает), а на моём PC и ноутбуке включён и SELinux, а в Windows MAC фактически нет: его сделали для какой-нибудь сертификации, и не то что бы его хоть кто-то включал, никто и никогда не писал профилей для приложений для Windows MAC. Его просто не существует.


                      1. sumanai
                        06.01.2018 19:08

                        А В Windows опасные и десктруктивные юзерские и разработческие паттерны приняты по-умолчанию.

                        Это не так. Все рекомендации по написанию программ, начиная минимум с висты, предписывают вполне безопасные практики написания программ, а механизмы перенаправления позволяют работать старым программам (и кривым новым) без администраторских прав.
                        и не то что бы его хоть кто-то включал, никто и никогда не писал профилей для приложений для Windows MAC

                        Опять неверно. Даже если отбросить права доступа, то Mandatory Integrity Control настроен для многих системных процессов и файлов, и по умолчанию настроен для всех процессов в средний уровень.


            1. willyd
              04.01.2018 22:26

              Вам изложили анти-паттерны, а вы доказываете, что их использование — это нормально?


            1. sHaggY_caT
              04.01.2018 23:14

              Что делает пользователь линуксов, когда обнаруживает, что stable-версия приложения отстала лет на 5? Переходит на ~, после чего ему приходится перевести на ~ пару библиотек, а затем и пол-системы, потому как зависимости. Оттуда остается лишь один шаг до ** и установки напрямую.


              Я? Я стараюсь вовремя обновляться… Но если вдруг? На сервере, не десктопе, и там RHEL6? Я просто собиру пакет со свежей версией :)

              Это уже почти стандарт — запись в свою инсталляционную директорию.


              Именно. И взлом очень сильно упрощается, если приложение может отредактировать собственные, в том числе бинарные, части. И части ещё кучи приложений, куда может писать тот же пользователь. Это ужасно.
              Так что это очень правильно, что бинарники в Linux лежат в /usr/bin, библиотеки в /usr/lib, настройки, независимые от пользователей в /etc, а зависимые в ~/.$APP_NAME или в ~/.local

              В Windows есть Documents and settings, но говноприложения его игнорируют. Линуксовые говноприложения могут падать, глючить, не работать без длительного применения напильника, но их файлы раскиданы по ОС секьюрным способом, если приложение включено в репозиторий.

              Типичный дизайн Windows-приложений тем ещё ужасен, что каждое приложение тащит с собой кучу либ, разработчиком которых является вовсе не разработчик приложения. Эти либы, часто совершенно дырявые, лежат в папке самого приложения, и на их обновление все забивают.
              Никсовая система божественна, как системные пакеты, так и pip, rvm, итд инсталляторы. Когда-то были распространены проблемы депенси хэлл, но теперь это всё в прошлом, а библиотеки, которые шарятся между приложениями, экономят шаренный RAM и дорогое место на SSD дисках помимо секьюрити.

              Многие сидят под root-ом, что это доказывает-то?


              В KDE или Gnome? Вы много знаете таких мазохистов? Ведь всё будет глючить, падать, отваливаться или работать странным образом :(

              Добавим сверху альтернативные репозитории,


              Да ладно, мало кто их подключает! Даже гентушники оверлей или арчеводы AUR. А кто подключает, знает, что делает :)
              Если мне нужно что-то, чего нет в официальных репах федоры и трёх самых популярных репозиториях от коммьюнити, возьму спек src.rpm из «левого» репозитория и официальный тарболл, и соберу пакетик несколькими несложными командами.


              1. willyd
                04.01.2018 23:31

                В KDE или Gnome? Вы много знаете таких мазохистов? Ведь всё будет глючить, падать, отваливаться или работать странным образом :(
                RHEL и Centos еще и сопротивляться будут. Да и большинство дестоп-дистрибутивов сейчас даже не спрашивают пароль для рута при установке.
                Если мне нужно что-то, чего нет в официальных репах федоры и трёх самых популярных репозиториях от коммьюнити, возьму спек src.rpm из «левого» репозитория и официальный тарболл, и соберу пакетик несколькими несложными командами.
                На самом деле я еще не столкнулся с проблемой, что мне чего-то не хватает в fedora и rpmfusion. В генту приходилось один или два оверлея подключать, но с ней долго жить невозможно, в конечном итоге тебе надоедает повышать энтропию вселенной сборкой какого-нибудь хромиума и ты съезжаешь на что-то более удобное. Хотя по скорости с ней никто не сравнится.
                А по работе без проблем пересобираю пакеты, когда нужно было отключить зависимости или добавить поддержку библиотеки, которой нет в стандартном пакете.


              1. Hellsy22
                05.01.2018 03:08

                бинарники в Linux лежат в /usr/bin, библиотеки в /usr/lib

                А так же в /usr/sbin, /opt/somedirname, а кое-что валяется и в ~/somedirname
                Кроме того, чего вы ограничиваетесь бинарниками? Почти в любом дистрибутиве линукса есть питон и перл, с помощью которых можно сделать ээ… все. А уж shell-скрипты валяются вообще всюду, включая /etc

                А где лежат, скажем, плазмоиды или плагины для разнообразного софта?

                Да ладно, мало кто их подключает!

                Увы-увы, в некоторых дистрибутивах СПО головного мозга доходит до того, что в базовых репозиториях нет проприетарного софта типа Chrome (а иногда и Chromium), Java или Flash Player — сейчас это уже не так страшно, а вот пару лет назад…

                Если мне нужно что-то, чего нет в официальных репах федоры и трёх самых популярных репозиториях

                Пользователи Windows аналогично берут софт на популярных репозиториях. Или с сайта разработчика, что вообще мало чем отличается от выкачивания готовой сборки с git-а.

                Когда-то были распространены проблемы депенси хэлл, но теперь это всё в прошлом

                Гентушники смотрят на вас со скепсисом. Достаточно не обновляться пару месяцев, чтобы выяснить, что мейнтейнерам захотелось сделать очередную перестановочку и разгребать конфликты придется вручную. А это чудо, когда ебилд требует новой версии Перла, но при перестановке Перла слетают все базовые библиотеки и потому билд падает из-за отсутствия в системе какого-нибудь Locale::gettext. Разумеется, Gentoo — не для слабых духом, но все же не надо кривить душой говоря, что все проблемы в прошлом. А уж если и железо хоть немного нестандартное, то… что ни версия ядра — то какой-нибудь праздник. То mtp2sas отвалится, то ath9k просто перестанет работать потому что… потому что! То кернел-паник из-за l2tp.


                1. willyd
                  05.01.2018 03:38

                  Увы-увы, в некоторых дистрибутивах СПО головного мозга доходит до того, что в базовых репозиториях нет проприетарного софта типа Chrome (а иногда и Chromium), Java или Flash Player — сейчас это уже не так страшно, а вот пару лет назад…

                  Если нет в оффициальной репе, будет в комьюнити, которая заслуживает доверия, как софтина, так и библиотеки нужные библиотеки. Сейчас даже быстрее чем для win все найдется.

                  Гентушники смотрят на вас со скепсисом. Достаточно не обновляться пару месяцев, чтобы выяснить, что мейнтейнерам захотелось сделать очередную перестановочку и разгребать конфликты придется вручную.
                  За год общения была проблема только раз. Именно с Перлом, но из-за рассинхрона репозиториев, в течении суток решилась.

                  Разумеется, Gentoo — не для слабых духом, но все же не надо кривить душой говоря, что все проблемы в прошлом. А уж если и железо хоть немного нестандартное, то… что ни версия ядра — то какой-нибудь праздник. То mtp2sas отвалится, то ath9k просто перестанет работать потому что… потому что! То кернел-паник из-за l2tp.
                  Не уверен, что я делал не так. Все работало отлично, ничего не слетало, до сих пор считаю Генту самым быстрым десктопом. Вот только сборка хромиума и еще пары пакетов, которая занимала несколько часов, — это меня пересилило. Ушел на Федору.

                  зы а вообще начинается линукс-срач


                  1. Hellsy22
                    05.01.2018 10:37
                    +1

                    будет в комьюнити, которая заслуживает доверия
                    Чем это в итоге-то отличается от установки софта в винде из «заслуживающих доверия» крупных репозиториев софта или от известных компаний?

                    Все работало отлично, ничего не слетало

                    У меня за последние 15 лет ни разу винда не слетала и, в целом, «все работало». У ребенка последние пять лет тоже была винда и линукс и тоже все как-то работало (потому что нет административных прав и не будет).

                    Но что в винде, что в линуксе, достаточно сделать лишь шаг в сторону от стандартных запросов и проблемы начинают сыпаться как из рога изобилия.

                    Например, уже упомянутая выше проблема с mtp2sas — я вот такой странный человек, что у меня на домашнем компьтере аппаратный RAID5. Ну там, знаете, надежность, производительность и вот это все. И для меня было сюрпризом, когда после очередного обновления init.d внезапно localmount стал запускаться до появления рейда в /dev. Решение было чудовищным — добавил sleep 15 и все заработало. А через пару месяцев так же тихо баг исправили.

                    Или вот актуальная проблема — есть китайская беспроводная мышка. Под иксами (любыми) она двигается с задержкой в полсекунды. Под виндой — работает нормально. Почему? Я не нашел решения.

                    Чтобы меня не обвиняли в однобокости припомню проблемы W10 и CH341 — популярнейшим китайским UART-чипом: первый год после выхода W10 драйвер для CH341 просто не работал и единственная рекомендация на форумах была «используйте W7». А как-то я захотел сделать нормальный мост на W10 Pro, с DHCP и роутингом. Промучавшись три дня, перелопатив тонны документации и перепробовав в том числе кучу стороннего софта я махнул рукой и за десять минут сделал то же самое на линуксовой машине. С другой стороны, я помню как мучился с L2TP (accel-ppp) — он насмерть вешал линуксовую машину время от времени…

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


                    1. willyd
                      05.01.2018 12:21

                      Чем это в итоге-то отличается от установки софта в винде из «заслуживающих доверия» крупных репозиториев софта или от известных компаний?
                      Зависит от этих самых неизвестных производителей софта. Если они нормальные, то у них в винде инсталляция будет нормально происходить, в репе, типа rpmfusion, есть хоть какой-то контроль сообщества, и велика вероятность отбраковки корявого приложения. Но shit happens, ничего не поделаешь…
                      Но что в винде, что в линуксе, достаточно сделать лишь шаг в сторону от стандартных запросов и проблемы начинают сыпаться как из рога изобилия.
                      В силу перечисленных sHaggY_caT причин, в винде сделать этот шаг проще. Если следуете минимальным правилам, не утанавливать подозрительный софт, не работать под рутом и т.д., везде будет хорошо.
                      И для меня было сюрпризом, когда после очередного обновления init.d внезапно localmount стал запускаться до появления рейда в /dev. Решение было чудовищным — добавил sleep 15 и все заработало.

                      chkconfig не пробовали прописать с нужными приоритетами на start/stop? Ну или depend() если был OpenRC.
                      В общем, я это к тому, что пока вам нужен от системы в основном браузер и видеопроигрыватель, то выбор OS в целом не принципиален — линукс тоже без особых усилий справляется с подобными задачами. Но когда дело доходит до специфических задач, то вылезают тысячи нюансов и проблем.

                      И универсальных решений нет.

                      Все хорошо везде, пока не нужно строить костыли. И это, в принципе, относится к обоим. Я не могу быть категоричным в этом вопросе. Меня полностью устраивает Linux для работы, у меня нет никаких проблем ни в играх(кроме отсутствия нормально видео карты) ни с проигрыванием media. Windows, еще отлична для enterprise и замены пока особо не видно, хотя я знаком с компанией, которая имеет пару тысяч продуктовых магазинов и использует SUSE, к сожалению уже не помню какую версию версию точно, открытую или enterprise.


                      1. Hellsy22
                        05.01.2018 12:44

                        Гхм, я все же возражу насчет игр, поскольку игры и продукты Adobe для меня являются основной причиной использовать Windows.

                        Все-таки Wine кое-как работает с DX9, но не с DX11/12/Vulkan. Портированные же на Linux игры зачастую работают хуже, чем под Вайном да и не так уж их и много. У меня большие надежды на gpu passthrough в будущем, но конкретно на моей конфигурации железа он не работает.


                        1. willyd
                          05.01.2018 13:31
                          +1

                          Мое желание поиграть могут полностью удовлетворить тайтлы из раздела Linux в steam'е. Но думаю, что если, будет нормальная видеокарта, то я смогу для развлечения поднять win в kvm и прокинуть туда карту.
                          Для работы мне удобнее использовать линукс, и пока это главный повод.


    1. AbnormalHead
      03.01.2018 21:21

      Вводишь в любом поисковике ключевую фразу «XXXXX errata», где XXXXX — название любого процессора (включая всякие микроконтроллеры).
      И узнаешь много интересного про устройство XXXXX.


    1. crea7or
      03.01.2018 23:27

      После всего утекшего от АНБ не исключено, что это просто закладка.


  1. dark_snow
    03.01.2018 14:24

    Вот не зря я фанат красных, как нутром с детства чувствовал… Правда сейчас сижу на кор кваде (ПК собран из халявного железа) но на 7ку и хр можно не ждать патчей думаю, так что с производительностью все нормально будет =)))


    1. sHaggY_caT
      03.01.2018 14:36

      так что с производительностью все нормально будет =)))

      Думаете, майнеры, ддосеры, и спам-рассыльщики, которые пропишутся через уязвимость на уровне ядра, будут оставлять Вам больше производительности, чем патч на уровне ОС?


      1. PavelZhigulin
        04.01.2018 06:51

        Принцип неуловимого Джо ему поможет :)


        1. sHaggY_caT
          04.01.2018 18:46
          -1

          Вряд ли. Не зря ведь есть поговорка «С дряной овцы хоть шерсти клок», и миллионы когда-то уязвимых ПК, теперь включённых в ботнеты.


  1. Tyrauriel
    03.01.2018 14:51

    А как обстоят дела в BSD системах? Нужен ли им аналогичный патч?


    1. Konachan700
      03.01.2018 15:16
      +1

      Судя по слухам (а другой инфы нет пока), уязвимость аппаратная и затрагивает все ОС. Где-то в проце при определенных условиях не проверяется какой-то бит из состава блока защиты памяти.
      Поговаривают, что даже ARM64 зацепило — а это значит, что баг вполне может быть в лицензируемом третьей строной блоке логики, используемым многими вендорами.


      1. Tyrauriel
        03.01.2018 15:45

        Сложилось впечатление что BSD уже работали в том режиме, на который сейчас котят пропатчить Linux и Windows. Или я все-таки перепутал операционки? Ведь точно уже есть такая для которой патч не требуется.


      1. udivankin
        03.01.2018 15:57

        В некоторых источниках пишут что баг архитектурный — в упреждающем выполнении кода без каких-либо проверок


        1. wych-elm
          03.01.2018 19:33

          Стойте, вы про т.н. спекулятивное выполнение, когда выполняются обе ветви if, параллельно, а потом отбрасывается ненужная? И если такая проверка — это if процес_имеет_доступ_к_памяти { читать_из_памяти } else { поднять_исключение }, то мы сможем прочитать из любой памяти (тут важный нюанс, очевидно, интеловские процы спекулятивно прочитанные таким образом данные не стирают и мы можем получить к ним доступ). Кстати, записать в память таким образом не получится, потому что запись в память вызывает сброс конвейера и спекулятивное выполнение не происходит (что соответствует этой дыре — память ядра можно только читать).


          1. kekekeks
            03.01.2018 22:50

            Там спекулятивный выполнятор запрашивает кусок доступной юзерспейсу памяти в L1-кэш в зависимости от результата выполнения инструкции, породившей исключение доступа. А наличие памяти в L1-кэше легко проверяется по задержкам доступа. Такие дела.


          1. Kghrast
            04.01.2018 18:30

            Точные детали уязвимости неизвестны, но на основе обсуждения патча «Do not enable PTI on AMD processors» (https://lkml.org/lkml/2017/12/27/2) предполагают, что речь именно о спекулятивном выполнении. Оно явно упоминается в обсуждении того, что процессоры AMD не подвержены уязвимости.


          1. nun-buoy
            06.01.2018 03:48

            Позапускал код, приведенный в конце spectreattack.com/spectre.pdf. На начальном этапе код заставляет процессор загрузить в кэш один из 256 кусков памяти, в зависимости от значения байта. Затем проверяется время доступа ко всем 256 кускам, и номер куска, который считывается быстрее остальных, и является искомым значением.


      1. ARD8S
        03.01.2018 18:22

        Теоретически, подобные уязвимости могут быть и в «спец. процессорах, которые ну уж совсем точно без закладок» (нувыпонели) или, например, в асиках?


        1. xcore78
          04.01.2018 20:32

          На мой взгляд, предсказание ветвлений ASICам не очень требуется. Еще на ASIC сложно выполнять произвольный код.


    1. equand
      04.01.2018 03:39

      BSD не подвержена, насколько видно в релизах патчей



  1. Barlog
    03.01.2018 14:57

    Может быть эта ошибка даст повод руководству intel хотя бы задуматься о возвращении к двухгодичному релиз циклу.


    1. asm0dey
      04.01.2018 13:23

      Во времена когда все, даже Java, переходят на суть ли не полугодичный? Intel уже замедлились в том плане, что от схемы tic-tac перешли на tic-tac-tac.


      1. Barlog
        04.01.2018 13:25

        Ты путаешь твёрдое с мягким. ;)


        1. asm0dey
          04.01.2018 13:29

          Формально релизный цикл уменьшился в два раза, фактически увеличился в полтора. Ведь внутри одного поколения они почти ничего не меняют.


          1. Barlog
            04.01.2018 13:30

            Вот это «почти ничего не меняют» и является основным источником ошибок.


            1. asm0dey
              04.01.2018 13:33

              Последние громкие ошибки существовали годами вроде, нет? Что вот эта дыра (особенно spectre, которой подвержен даже AMD), что дыра в IME. как ни странно, но возникли они как раз не во время оптимизации (которая происходит на tack), а во время создания новой архитектуры (tick).


              1. Barlog
                04.01.2018 13:36

                Но их не нашли, потому что «зачем всё проверять, мы же совсем чуть-чуть поменяли, если что в следующем процессоре исправим, через год же всего выходит»


                1. asm0dey
                  04.01.2018 13:45

                  Их не нашли потому что это невозможно сделать целенаправленно. Так же как ты не можешь найти все баги в софте (начиная с какого-то уровня сложности) даже если целиком его писал сам — всё предусмотреть невозможно. А процессоры, так же как и софт, делаются не одним человеком, а большими командами. Я думаю, что в Intel серьёзно относятся к безопасности и надёжности (на этом месте можно спросить у @shipilev, он там рядом варился) и гонка за скоростью ради качества, думаю, достаточно ограничена.


                  1. Barlog
                    04.01.2018 14:04

                    Всё можно проверить на 100% и отладить до конца. Вопрос времени. Но возвращаюсь к моему первому ответу: софт можно легко исправить, поэтому на тестировании экономят, железо — нет, но почему-то на тестировании тоже экономят.


                    1. willyd
                      04.01.2018 14:11

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


                    1. lpwaterhouse
                      04.01.2018 15:14

                      «Целое больше, чем сумма его частей»
                      Вы можете отладить часть системы, каждую отдельную часть системы, систему целиком, систему с некоторой внешней средой, но в итоге проверить абсолютно все вы не сможете. И даже если сможете, всегда будут незадокументированные и неочевидные взаимодействия. Это бессмысленно. Баги есть, будут всегда и их не искоренить. Можно лишь оставить те, вероятность обнаружения которых довольно низка.


                    1. asm0dey
                      04.01.2018 16:55

                      Железо обычно правится исправлениями микрокода (и интел регулярно выпускает обновления). А вот тут вот такое вот что не повезло. Гипотетически ты прав — проверить можно вообще всё. Надо просто прогнать все возможные комбинации параметров и комбинации комбинаций. То есть запустить весь возможный софт в случае процессоров. Но это настолько долго и дорого, что легче называть это «невозможно».


                      1. dimm_ddr
                        04.01.2018 19:11

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


                        1. asm0dey
                          04.01.2018 19:52

                          Вам не кажется что вы другими словами повторили то, что написал я? :)
                          Всего возможного софта пока что не написано, так что на настоящий момент такая проверка невозможна.
                          Однако то что сказал я показывает фальсифицируемость гипотезы о том, что можно проверить что-то на предмет 100%-надёжности, что в общем-то делает эту гипотезу как минимум наукообразной :)


                          1. dimm_ddr
                            04.01.2018 20:55

                            Не совсем то же самое, я скорее дополнил на тему того что оно реально невозможно, а не просто слишком дорого.


                            1. willyd
                              04.01.2018 21:14

                              Ваш диалог мне напомнил Deadwood в переводе Сербина.


                              1. asm0dey
                                04.01.2018 21:22

                                Ой, а что там было? Я в какой-то многоголосой озвучке смотрел.


                                1. willyd
                                  04.01.2018 21:38

                                  Да там, в принципе, каждый второй диалог — это построение брутальной логической цепочки.
                                  Многоголосый от fox не передает все глубину этой мысли создателей.


                            1. asm0dey
                              04.01.2018 21:22

                              Согласен с вашим утверждением.


  1. arthi7471
    03.01.2018 15:12

    Мда… Десять! Десять маза фака лет нас могли поиметь по железу и скорее всего имели и вдруг, совершенно неожиданно, заметили что что-то не так.


    1. SNPopov
      03.01.2018 15:30

      Все как по анекдоту. Приговоренного к смерти после длительной отсрочки выводят на казнь. Тут он спрашивает — А какой сегодня день недели?.. Ему отвечают — Понедельник. Он — Ничего себе неделька начинается…


      1. gearbox
        04.01.2018 14:13

        там по тексту — все происходит в туманно-дождливый понедельник, и один из конвоиров ему отвечает — тебе то что, а вот нам еще назад возвращаться.


    1. N1ght1ngale
      04.01.2018 16:14

      Пишут что уязвимая функция появилась уже в 1995 году в Pentium Pro.


  1. Alter2
    03.01.2018 15:16
    +2

    К счастью, последние модели процессоров Intel с технологией PCID (идентификаторы контекста процесса), возможно, позволяют уменьшить падение производительности

    Устав бороться за прирост производительности новых процессоров, решили понизить производительность старых?
    Или кто-то вскрыл аппаратный бэкдор специально заложенный производителем а-ля Intel Management Engine? Кстати, то что уязвимы модели процессоров за последние 10 лет, неплохо коррелирует с внедрением IME.


  1. erazel
    03.01.2018 15:27

    ИМХО есть еще один вариант — так Интел хочет увеличить отрыв будущих процессоров(которые только разрабатываются) от текущих поколений. Что бы стимулировать переходить на новые модели. Не секрет что вот уже лет 7 мы имеем очень малый прирост быстродействия у Интел. Поэтому покупатели не торопятся обновляться.
    Хотя это больше касается десктопного сегмента, а тут под угрозой больше серверные системы.


    1. KivApple
      03.01.2018 16:40

      Уязвимость то реальная (после публикации всей информации её сможет проверить любой желающий) и появилась не меньше чем лет 10 назад. Едва ли кто-то будет планировать такую многоходовочку «заложим уязвимость сейчас, а потом через 10 лет сольём её, чтобы выпустить процессоры без неё и поднять продажи»:

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


      1. San_tit
        03.01.2018 18:26

        Скорее могло быть так: щас сделаю вот такой вот костыль, пока работает, а потом можно будет доделать.


  1. AlexanderS
    03.01.2018 15:31

    Прошло только 3 дня нового, 2018 года и… какие замечательные новости!
    Причём самое печальное не то, что косяк нашли. Косяков не делает тот, кто ничего не делает вообще. Печально то, что наверняка об этом косяке кое-кому было хорошо известно какое-то время, но, по вполне понятным причинам, особо это никто не стремился исправлять.

    Мало технодробностей. Как нашли, как именно эксплуатируется, какое железо затронуто?

    Может это всё этот… заговор? ) Интел решил массово всех подтолкнуть к будущим апгрейдам железа в котором этих косяков нет но есть другие.


    1. a5b
      04.01.2018 00:03

      Первая публикация "по мотивам" была Jun 24, 2017 https://gruss.cc/files/kaiser.pdf, патчи Linux уже несколько месяцев пишут — https://lkml.org/lkml/2017/12/4/709 https://lkml.org/lkml/2017/12/4/709 [patch 00/60] x86/kpti: Kernel Page Table Isolation (was KAISER)
      на базе пакета патчей, готового к 1 ноября 2017 https://github.com/IAIK/KAISER "Kernel Address Isolation to have Side-channels Efficiently Removed"
      Latest commit 6112890 Nov 1, 2017 @dgruss


      1. AlexanderS
        04.01.2018 11:12

        Ну, я-то домашний хомячок + работа вообще-то не по тематике IT, поэтому руку на пульсе не держу, поэтому «неожиданно» узнаю о проблемах вот из таких новостей.
        Спасибо за ссылки.


  1. Neuromantix
    03.01.2018 15:32

    [paranoic mode on] Может, это под впечатлением от Black mirror s4ep05, но почему мне кажется, что подобный подход — обмен надежности на удобства — может плохо кончится? Сколько еще таких дыр в железе и софте, которые напиханы или будут напиханы в ближайшем будущем в боевых роботов, в системы жизнеобеспечения, в коммуналку и в кучу других вещей, на которые опирается нынешняя цивилизация? [paranoic mode off]


    1. neomedved
      03.01.2018 16:24

      Но ведь это наоборот обмен удобства на надёжность.


      1. Neuromantix
        03.01.2018 16:56

        Это костыль, необходимый как раз из-за размена надежности на желание побольше хапнуть и выпускать сырые дырявые продукты. Ведь (к примеру) 1080 — мало, надо 2к, 4к, 8к, 16к и до бесконечности, нужно больше сокетов, обновлений, архитектур, чипов, золота и зиккуратов, а на все прочее — плевать.


        1. Areso
          04.01.2018 10:19

          Но вот ведь интересный момент. 1080 Ti можно воткнуть в G31 материнскую плату и она будет работать (пусть и будучи ограниченной PCI-E v1.1), а вот любой современный процессор в ту материнскую плату не воткнуть.
          Так что уж в кого и кидать камни, так не в PCI-E.


          1. RHCk
            06.01.2018 03:48

            Думаю, имелось в виду FullHD


  1. SinsI
    03.01.2018 15:48

    «Приятная» новость для линуксоидов —

    As it turns out, apparently the Linux patch that is being rolled out is for ALL x86 processors including AMD, and the Linux mainline kernel will treat AMD processors as insecure as well. As a result, AMD CPUs will feel a performance hit as well, though the bug only technically affects Intel CPUs and AMD recommends specifically not to enable the patch for Linux.

    — если у вас АМД, вам всё равно впаривают этот патч.


    1. Konachan700
      03.01.2018 15:53

      Действие патча отключается параметром ядра. Сделано для того, чтобы не создавать хаос в дистрибутивах и не разводить холивары «надо или не надо». При установке будет тест на типа проца, для амд добавит инсталлятор параметр и всё.


      1. KivApple
        03.01.2018 16:43

        А логичнее было бы при загрузке определять модель процессора (это в любом случае делается, потому что в ядре есть куча других work-around для других багов) и применять опцию (раз её можно менять параметром ядра — значит поведение можно менять без перекомпиляции) только если процессор от Intel. Хардкодить в конфигах параметры, которые легко и быстро определять при загрузке — плохой путь. Процессор может и смениться (если это, например, LiveUSB) между перезагрузками.


        1. Konachan700
          03.01.2018 16:55

          Так в последнем патче так и сделали. Баг критикал, потому первый коммит был направлен на скорейшее его закрытие, главное, чтобы он за собой ничего не ломал — остальное можно допилить потом. Это нормальная практика, иначе критикал патчей придеться ждать месяцами, если все учитывать и тестировать по-полной…


    1. VlK
      03.01.2018 16:01

      Насколько понимаю, ответственные решили так не маньячить и упростить все для АМД:

      patchwork.kernel.org/patch/10133447

      В сущности, там проверка типа «для всех 86» заменяется на «для всех Интелов».


    1. DerRotBaron
      03.01.2018 17:56

      Судя по этому патчу, в исправленных версиях ядра будут проверять на AMD


  1. Meklon
    03.01.2018 15:49

    Ох, жестоко (


  1. huhen
    03.01.2018 15:53

    Судя по патчу, добавляется защита на доступ из юзерспейса(ring 3) — видимо TLB кеш позволяет заглянуть куда не следует. Так что баг касается и домашних компьютеров, но судя по тексту статьи позволяет еще и добраться до гипервизора.
    Пока нет подробностей можно надеяться на лучшее и эта «фича» не будет работать например при выключенной виртуализации(хотябы «домашние» компы не просядут).


    1. vconst
      03.01.2018 16:01

      Выше высказади опасения, что это может касаться любых «песочниц», включая js в браузере. Это и правда так может быть? Я не спец, но выглядит очень опасно…


      1. huhen
        03.01.2018 16:09

        Тут скорее всего потребуется двойная уязвимость:
        — исполнение произвольного кода
        — и за счет этой уже выбираемся из «песочницы».


        1. KivApple
          03.01.2018 16:46

          Иногда JIT может сгенерировать такой код, который корректен с точки зрения поведения в идеальных условиях, но тоже триггерит уязвимость. Так что если повезёт, то явных уязвимостей в движке и не нужно.


          1. abyrkov
            04.01.2018 22:20

            Такое работает через раз


            1. sumanai
              04.01.2018 22:22

              Через раз это всего 50%, просто повторить два раза.


  1. vasiliysenin
    03.01.2018 16:31

    Уже давно на хабре была статья про то, как из JavaScript определить где физически размещены данные. Если при выделении памяти, всегда затирать её нулями, то вроде бы такая уязвимость не так и страшна.
    Если же аппаратная ошибка в механизме виртуальной памяти, то единственный вариант защиты — это интерпретация машинного кода. В этом случае падение скорости на 30% это минимум.
    Если погуглить фразу «KAISER patches», то там говорится о "...KAISER, a kernel isolation technique to close hardware side channels on kernel address information.", то есть рандомизация размещения в памяти.
    Замедлять компьютеры на процессорах AMD это конечно интересное решение Линуса Торвальдса.


    1. sumanai
      03.01.2018 17:21

      Если при выделении памяти, всегда затирать её нулями, то вроде бы такая уязвимость не так и страшна.

      Вообще-то так и делается, по крайней мере в Windows.


      1. huhen
        03.01.2018 18:43

        А можно пруф?
        Иначе зачем например openssl при освобождении забивает её нулями рандомными значениями? Как раз чтобы другому процессу ОС случайно не отдала блок с важными данными. Да и в Windows неспроста присутствует функция RtlSecureZeroMemory.


        1. Konachan700
          03.01.2018 19:12

          Пруф можно получить, сделав malloc(1) и дальше в цикле инкремент этого указателя (будет читаться невыделенная память) — там будут или нули, или данные нашей программы. Но там не будет ничего чужого. Я это лично когда-то проверял, тоже казалось, что по невалидным указателям должны читаться ошмётки от других программ, примерно как в ардуино лол…
          Затирают же для того, чтобы в памяти не висели ключи и прочая секретная информация. Из другого процесса это может и не достать, но вот из ядра вполне себе достается. RtlSecureZeroMemory нужна потому, что компилятор выбрасывает все конструкции типа memset(), если данные после них более не используются.


          1. maaGames
            04.01.2018 08:08

            Возможно, зависит от языка программирования, но менеджер памяти ничего сам не затирает, т.к. на это тратится время. Далее говорю только за С/С++.
            Проверяли вы, скорее всего, в debug-режиме, а в нём как раз затирается, для удобства отладки. А в релизе ничего не затирается ни при выделении памяти, ни при освобождении. Поэтому, при необходимости, обнуление выполняется вручную, но оптимизирующий компилятор может эти затиранния удалить, если не считает их важными для работы алгоритма. Выше уже написали о функции RtlSecureZeroMemory, которую компилятору не разрешается удалять, как раз для того, чтобы гарантировано обнулить память.


            1. sumanai
              04.01.2018 13:36

              Не затирается память, выделяемая внутри приложения. Всё, что отдаёт ОС, затирается. То есть в обычном режиме программа может прочитать только свою память.


              1. maaGames
                04.01.2018 13:43

                В принципе, не важно, в каком виде память получается при выделении. Важно, в каком виде память остаётся после использования. Если после удаления объекта память не была обнулена/заполнена мусором, то достаточно вызова ReadProcessMemory, чтобы прочитать данные, которые в блоке памяти были записаны. Как я понял, из-за ошибки не проверяется, есть ли право чтения памяти по указанному адресу, поэтому можно прочитать любой блок памяти, даже тот, которым пользуется ядро. В нормальной ситуации был бы сегментфолт или другое исключение, но не в этот раз.


            1. CoolCmd
              04.01.2018 18:31
              +1

              венда обнуляет память, которую ей возвращают проги. (может и при выделении, если специально попросят, например HEAP_ZERO_MEMORY). но когда Си-шная прога вызывает free(), этот кусок памяти не обязательно сразу отдается венде.

              размер обнуленных страниц памяти показывает process explorer.


        1. huhen
          03.01.2018 19:14

          Хотя поискал, действительно начиная с Windows Vista(?) выделенные страницы обнулены.


          1. sumanai
            03.01.2018 19:38

            Виста? Так делает любая NT как минимум. Это базовое требование безопасности, заложенное в архитектуру ОС по требованию каких-то там правительственных служб. Инфа из книги «Внутреннее устройство Microsoft Windows» интересующей вас версии, я читал от 2000 до семёрки.
            Кстати, память на дисках так же зануляется для пользователей с ограниченной учётной записью, а вот админы могут прочитать и так, как впрочем и память других процессов, кроме защищённых.


          1. Mabu
            05.01.2018 03:18

            Вызываю функцию HeapAlloc без флага HEAP_ZERO_MEMORY, страницы тоже будут обнулены?


            1. sumanai
              05.01.2018 03:41

              Память будет обнулённой при вызове HeapCreate. При выделении памяти в этой куче обнуления не происходит, так как эта память принадлежит процессу, и это его забота, что там есть.


              1. Mabu
                05.01.2018 17:58

                Память будет обнулённой при вызове HeapCreate.

                Это при условии, что мы заранее указываем размер создаваемой кучи. А если не указывать, то куча куча может расти, и каждое выделение памяти из неё не будет обнуляться.


                1. sumanai
                  05.01.2018 19:10

                  Вы не правы. При росте кучи сверх текущих размеров новая память для неё будет выделяться стандартными средствами из списка очищенных страниц большими блоками, а уж потом из неё выдадут блок запрошенного размера, и вот тут обнуления не будет. Никаких утечек приватных данных, доступных для обычных приложений, в Windows нет.


                  1. Mabu
                    06.01.2018 04:45

                    Только что проверил. Вызвал функцию HeapAlloc без флага HEAP_ZERO_MEMORY, выделив 154000 байт. Получил не нули, а мусор. Я туда не записывал, только читал. Что это за данные? Эти данные от предыдущих программ? То есть это могут быть логины и пароли?


                    1. sumanai
                      06.01.2018 15:01

                      Это ваши же данные. Структуры самой кучи, мусор от запуска рантайма. Посмотрите на размер экзешника, на него в дизасме. Там кроме вашего кода валяется в 100 раз больше кода от компилятора.
                      Попробуйте выделить десяток мегабайт, чтобы заставить ОС отдать новые страницы памяти, а не переиспользовать старые.


        1. wadeg
          06.01.2018 03:18

          Система выделяет память пользовательскому процессу вызовом
          VirtualAlloc[Ex].

          The function also guarantees that when the caller later initially accesses the memory, the contents will be zero. Actual physical pages are not allocated unless/until the virtual addresses are actually accessed

          malloc etc — это уже надстройка (система кучи) со своими правилами, которые тоже нужно понимать.


  1. SinsI
    03.01.2018 16:55

    Не может ли эта уязвимость быть связана с IME — ведь ей как раз десяток лет?
    Это могло бы объяснить, почему она так долго оставалась незамеченной…


  1. random1st
    03.01.2018 17:20

    lkml.org/lkml/2017/12/27/2 — касаемо Linux и AMD


  1. Scratch
    03.01.2018 17:33

    А 29 ноября CEO Intel слил все свои акции.
    Совпадение?


    1. novice2001
      03.01.2018 22:50

      Во-первых, не все.
      Во-вторых, те акции, что он продал, были куплены по опциону ниже рынка.


      1. ivan2kh
        03.01.2018 23:06

        вообще-то все что мог, кроме обязательного минимума


        1. novice2001
          04.01.2018 00:16

          Только вот минимум — это столько же, сколько и продал. Так что чувак просто наварился на разнице цен — а из этого делают какие-то выводы.


    1. prianichnikov
      04.01.2018 18:31
      +1

      Есть предположение, что просто комбинирует с налогами:

      I will offer an alternate explanation. He lives in CA. Due to the recently passed federal tax changes, there may be good reasons to realize some gains under 2017 tax regime vs 2018. The limits on write off of state tax against federal will certainly hit him. So taking the action in 2017 he can use the deduction, but not in 2018. He is certainly hitting top tax brackets so 13.3% * 39.6% works out to a >5% take home difference. Not earth shattering, but definitely worth considering pulling some transactions in 2017.

      Reddit


  1. MaxKorz
    03.01.2018 17:57

    Патч с решением (kpti) для Linux добавил в ядро лично Линус Торвальдс.

    Ну давайте еще больше жути напустим. Линус просто мержит ветки, и если открыть по ссылке log то это прекрасно видно, к патчу он не имеет отношения.


  1. baldrs
    03.01.2018 17:57

    А я еще сомневался брать ли Threadripper. -30% к производительности на процессорах Intel это однозначное да.


    1. boblenin
      03.01.2018 22:51

      Ага. Только что считал сборку на 8700k, теперь думаю о Ryzen.


  1. kegex
    03.01.2018 17:57

    Желаю потерять им побольше процентов рынка в пользу AMD


  1. budoraq
    03.01.2018 17:57

    — Как продавать больше новых процессоров?
    — Давайте дискредитируем все старые за последние 10 лет!
    — Ты чудовище! Какое хочешь повышение?


  1. Kogolbok
    03.01.2018 17:57

    А макось уязвима? В громком названии её не вижу. Это просто потому, что они пока никак не отреагировали, или они-таки не подвержены в силу тех или иных причин?


    1. PlayTime
      03.01.2018 18:01

      Это не идеальное решение проблемы, но грядущие патчи для Windows, Linux и macOS будут использовать именно этот подход.


      1. Kogolbok
        03.01.2018 19:12

        Да, но в названии числятся только две операционки. И название-то, шокирующее и наводящее на определённые размыщления. ТС писал с Мака? :)


        1. lpwaterhouse
          03.01.2018 19:26
          +1

          Просто уязвимость мака — это несерьезно. Винда — огромный процент в юзер-сегменте, Линукс — серверный, а Мак — игрушка с грошами на фоне остальных цифр.


          1. asmrnv777
            04.01.2018 09:54

            От 6 до 11.5% по разным данным — это весьма немало.


            1. fpir
              05.01.2018 19:38

              От 6 до 11.5% от 2% устройств не на linux.


          1. Darknet
            04.01.2018 18:31

            Alex Ionescu рапортует что макось пропатчили еще в 10.13.2, падения производительности никто не заметил.


            1. willyd
              04.01.2018 18:52

              Где-то отписывался пользователь, что по субъективным оценкам произошло прямо противоположное iphone и ipad, и батарея начала разряжаться быстрее.


    1. MuLLtiQ
      04.01.2018 14:22

      macOS пропатчили еще в декабре, насколько я понимаю support.apple.com/en-us/HT208331


  1. SergeyMax
    03.01.2018 17:57

    некоторые подробности всё-таки выплыли наружу благодаря Python Sweetness и The Register

    Странно, а по первой ссылке слово «Intel» вообще не упоминается, более того, написано «security bug impacting apparently all contemporary CPU architectures that implement virtual memory». Не трахнули ли несчастного журналиста ещё раз?


  1. xl-tech
    03.01.2018 17:57

    Объясните, пожалуйста, а если я ставлю патч сначала на хостовую машину, потом на виртуальную, я получаю падение производительности до 60%? Или на виртуальные машины оно так влиять не будет?


    1. jryj
      03.01.2018 18:21

      До 49%. Если уж следовать вашей логике.


    1. danzealzer
      03.01.2018 18:30

      30% — это среднее по больнице. На некоторых задачах можно и по-более отхватить, согласно Фороникс. А может и вовсе не увидите разницы, как мне кажется.


      1. nidalee
        03.01.2018 20:19

        Нет, до 30% — это до 30%. В таком случае «среднее по больнице» — это 15%. Среднее между 30 и 0.


        1. Mixaill
          03.01.2018 20:50

          В исходном тексте не совсем корректные данные. В худшем случае падение более чем в два раза lwn.net/Articles/742522


  1. HaltAction
    03.01.2018 17:57

    А тем временеим CEO Intel за месяц до этого продал акций на 11 миллионов
    www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx


  1. pda0
    03.01.2018 18:22

    Тут другое интересно. Получается, в VPS эту штуку придётся держать включенной на каждой виртуалке? Гостевые OS с nokpi гонять не получится?


    1. asm0dey
      04.01.2018 13:39

      Зачем? Основная проблема-то — уязвимость хоста. Остальное всё-так ближе к проблемам клиента. Дальше всё зависит от ваших отношений с клиентами и обязательств перед ниим. Если их безопасность находится в сфере ваших интересов — тогда да, им тоже надо порекомендовать поставит патч.


      1. pda0
        04.01.2018 15:35

        Эм… Тут все крутые, но я скорее с позиции клиента рассматриваю. :) Раз уязвимость в процессоре, а виртуализация — аппаратная, то патч придётся ставить не только хостеру, но и на гостя. И держать его включенным. Получая, возможно, двойной штраф…


        1. tbl
          04.01.2018 15:57

          если виртуализация не полная, а что-то типа docker, то ядро общее


        1. asm0dey
          04.01.2018 17:04

          Тогда да, учитывая что клиентская виртуалка может словить малварь — конечно там тоже должна быть заплатка в большинстве случаев.


        1. shikhalev
          04.01.2018 18:32
          +1

          Двойного штрафа, насколько я понимаю, не будет — основное замедление из-за инвалидации процессорного кэша, а не из-за инструкций, которые эту инвалидацию делают. Могу ошибаться.


          1. pda0
            04.01.2018 21:26

            Так они кэш инвалидируют? Тогда нам всем ещё повезло, что просадка всего на 30%. Помню, на старых компах была опция в BIOS по отключению кэша. Сразу раз в 20 медленнее работать начинал компьютер.


            1. shikhalev
              05.01.2018 19:01

              Сорри, был не совсем прав, там всё сложнее. Так что двойной штраф возможен. Хотя, мне кажется, не каждому вызову syscall на госте будет соответствовать таковой на хосте, т.о. штраф будет в среднем между единичным и двойным.


  1. Terras
    03.01.2018 18:35

    Интересно, двинет ли это рынок процессоров в объятия AMD?


    1. Alcpp
      03.01.2018 23:57

      Рынок б.у. процев — да.

      Новых — не сильно. Увеличение количества новых процев произойдет не скоро (измеряется месяцами), т.к. заказы не так просто разместить. А Интел может уже через пару недель выкатит хардварный апдейт.


      1. GalVorbak
        04.01.2018 17:42

        А Интел может уже через пару недель выкатит хардварный апдейт.

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


        1. Meklon
          04.01.2018 20:06

          Это ж с каким дисконтом продавать надо будет? Все будут ждать чистое поколение.


          1. GalVorbak
            04.01.2018 21:44

            А будет ли дисконт вообще? Они вроде наоборот все сливки снять намерены, ведь зная об уязвимости выходящего на рынок поколения они наоборот сдвинули его запуск на два месяца раньше (знатоки теорий заговоров в треде и вещают ещё и про то что их СЕО ещё в осенью продал свои акции сколько смог, зная что они упадут после массовых публикаций об уязвимостях). В то-же время, простые люди покупать их процессоры будут, потому что большинству до лампочки новости из сферы безопасности, а упираются в потолок производительности они относительно редко.
            А с серверным действительно интересно, поможет ли сильный дисконт, учитывая, что даже без выявленной уязвимости EPYC получался, вроде как, довольно хорошими за свою цену.


      1. metric_ghost
        04.01.2018 20:56

        Хардварный апдейт, КМК, потребует полной переработки масок. Я так понимаю, это не степпинг по мелочи поправить, это очень-очень дорого. Голосую за то, что восьмое поколение останется без апдейта, а если маски уже создали для девятого поколения, то не факт, что и оно его получит.


  1. tmnhy
    03.01.2018 18:59

    1. joker2k1
      03.01.2018 19:45

      ящик пандоры открыт?


    1. cher11
      03.01.2018 20:17

      А не могли бы вы объяснить, что именно произошло на скриншоте? Первая команда — компиляция, понятно. Затем запуск бинарника, и?..


      1. VlK
        03.01.2018 20:20

        Он сначала прямиком читает из таблицы символов ядра (собственно, баг).

        А потом показывает, что это правильные адреса через обычный интерфейс (директорию /proc/).


    1. huhen
      03.01.2018 20:31

      Как я понял при его участии в феврале была опубликована инфа про обход ASLR через js. Если верить публикации обход сработал на 22 разных процессорах, в атаке насколько я понял использовалось особенности работы кеша процессора и TLB, видимо капнул дальше.


  1. springimport
    03.01.2018 21:08

    Видимо началась новая эпоха замедлений. Эпл и Интел стали первопроходцами. Интересно, какие будут причины придумываться.


  1. Nedder
    03.01.2018 21:40

    А вот интересно, а как насчёт судебных исков из-за падения производительности на 15%-30%?


    Фольксваген за несчастный газовый тест на миллиарды засудили, а тут что? Забыть и простить?


    1. sumanai
      03.01.2018 22:02

      Фольксваген за несчастный газовый тест на миллиарды засудили

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


      1. novice2001
        03.01.2018 23:14

        Стандарты выполнимы. Иначе засудили бы не только VW. И засудили их за мошенничество.


        1. idiv
          03.01.2018 23:38

          Тут сложнее. Есть идея, что это была акция против крупнейшего в мире конкурента. Еще один вариант — слишком уж нагло они это делали и далеко не один год. А так сейчас смотрят в сторону Крайслер-Фиат и Мерседес.


        1. sumanai
          04.01.2018 13:44

          Стандарты выполнимы.

          Только получается совсем не то, что хочет потребитель.
          Иначе засудили бы не только VW.

          Проще было изменить законы и разрешить превышение по выхлопам в два раза.


    1. darthmaul
      03.01.2018 22:11

      Фольксваген за несчастный газовый тест на миллиарды засудили, а тут что? Забыть и простить?

      Фольксваген нарушил интересы государства, а Интел — всего лишь интересы простых смертных. Увы, ничего им не будет.


      1. ARD8S
        03.01.2018 22:54

        Репутационные потери никто не отменял. Потери капитализации. Вообще, они всё грамотно делают, если что, всегда есть пункт под "*" о производительности.
        Ну продажи могут просесть, цены придётся немного скидывать на старые поколения, если AMD не повысят.

        Интел — всего лишь интересы простых смертных

        Некоторые большие корпорации (и гос. компании/органы) могли поиметь из-за этого проблем (и не факт, что их не было). Сейчас, как минимум замедление виртуализации, а это некислый такой кусок бизнеса Intel и VPS площадок. Вообще, оправдатели AMD лукавят, протравливая свои «выстрелившие» удачные платформы.
        новые серверные чипы EPYC от AMD, а также их десктопные процессоры Ryzen Pro имеют технологию шифрования защищённой памяти, дающую дополнительную защиту от атак подобного рода.
        а для других, как я понял всё это доступно, только уже
        «Архитектура AMD не позволяет получить доступ к данным при отсутствии соответствующих привилегий»
        т.е. с соответствующими привилегиями не факт, что невозможно.


        1. huhen
          04.01.2018 00:27

          т.е. с соответствующими привилегиями не факт, что невозможно.
          А почему поток с соответствующими привилегиями не должен иметь доступа к данным?


          1. ARD8S
            04.01.2018 01:57

            Да, это я понимаю. Если человек работает под root/админской учёткой или процесс запускается с повышенными правами, или использует другую уязвимость, повышающую права, то проц AMD не обезопасит от этого. Хотя, если уж всё так, то тогда конкретно эта дырка будет уже не нужна. Т.е., допустим, многие сервера работают под рутом, многие виртуалки так же. И всё. Просто как бы не началась истерия — интел говно, покупайте AMD, они неуязвимы. «И вирусов там нет» (с).


  1. Mightywill
    03.01.2018 22:37

    это не уязвимость, это цру попросило сделать, а инфа утекла или ктото случайно нашел эту дыру


    1. SanekPlus
      03.01.2018 22:46

      инфа 146% ?


      1. DjOnline
        04.01.2018 12:19

        Ну достаточно почитать wikiliks, чтобы понять, что они активно сотрудничают как с производителями (в том числе материнских плат, процессоров, жёстких дисков), так и с хакерами, выкупая 0-day раньше всех.
        Так что по сути неважно, по их ли инициативе это появилось или вследствии ошибки, важно то, что они этим как минимум пользовались с ноября, а возможно и годами раньше.


    1. equand
      04.01.2018 12:30

      В АМД такого нет. Так что похоже на то, что ЦРУ ничего не просила, похоже на оптимизацию из разряда предкалькуляции. Видимо весь прогресс Интела на этой баге и висел.


      1. interprise
        04.01.2018 12:32

        «чистая» производительность без сисколов падать не будет, те интел в производительности на ядро все равно быстрей и баг тут не причем.


        1. equand
          04.01.2018 12:34

          Не важно ибо по текущей производительности AMD до патча догнал Intel, после патча получается у Intel еще и сисколлы будут в тормозе.


        1. alexr64
          04.01.2018 18:33
          -1

          Чистая производительность, без обращений к ядру ОС, в настоящее время является узким местом только в ограниченном круге задач. БОльшая часть упирается в ввод/вывод.


      1. Mightywill
        04.01.2018 14:34

        в АМД нет или еще не нашли? почему вы думаете что дыры должны быть в одном месте? (кривая ухмылка)
        к тому же бага в каком наборе инструкций? если это интел-специфик то в амд его и не будет


  1. funnybanana
    03.01.2018 22:48

    Минуточку:

    Также сообщается, что патч для Linux будет по умолчанию включать kpti и на компьютерах с процессорами AMD, вызывая соответствующее падение производительности.


    Зачем это делать если об уязвимости АМД процессоров ничего не известно?
    P.S сижу на AMD a10


    1. a5b
      04.01.2018 00:35

      Представитель amd заявил, что их микроархитектура не допускает доступа к более привилегированной памяти из менее привилегированного контекста (в т.ч. спекулятивного) и предложил не включать "kpti" на AMD
      https://lkml.org/lkml/2017/12/27/2 Tom Lendacky (amd)


      AMD processors are not subject to the types of attacks that the kernel
      page table isolation feature protects against.  The AMD microarchitecture
      does not allow memory references, including speculative references, that
      access higher privileged data when running in a lesser privileged mode
      when that access would result in a page fault.
      
      Disable page table isolation by default on AMD processors by not setting
      the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
      is set.
      
      -   /* Assume for now that ALL x86 CPUs are insecure */
      -   setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
      +   if (c->x86_vendor != X86_VENDOR_AMD)
      +       setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
      


  1. NiTr0_ua
    03.01.2018 22:58

    to funnybanana:

    то было первое решение «лишь бы залатать». уже принят новый патч patchwork.kernel.org/patch/10133447

    //промахнулся немного веткой…


  1. Neuromantix
    03.01.2018 23:55

    Уже фигурируют страшные цифры -63% twitter.com/grsecurity/status/948170302286172160


  1. robert_ayrapetyan
    04.01.2018 00:25

    Пока что в единственно показанном PoC на скриншоте в твиттере видно чтение, а что с записью? Ведь если запись недоступна, то все не так страшно?


    1. willyd
      04.01.2018 00:55

      Я вот не знаю. В теории нельзя написать такую инструкцию, которая скомпрометирует критические данные с хост-сервера, к примеру?
      Да и после такого громкого выстрела только ленивый не будет копать в поисках схожих уязвимостей, причем не только в Intel…


  1. ShashkovS
    04.01.2018 00:49

    Пишут, что postgresql с этим фиксом проваливается на 17-23%. Жесть, конечно.
    Пруф: www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3.anarazel.de


    1. MuLLtiQ
      04.01.2018 01:35

      Note that real-world scenarios probably will see somewhat smaller
      impact, as this was measured over a loopback unix sockets which'll have
      smaller overhead itself than proper TCP sockets + actual network.

      Все-таки хочется посмотреть насколько все плохо на реальных БД: там очень многое зависит от производительности диска и сети.


  1. ange007
    04.01.2018 01:22

    Только блин купил мать под 8е поколение.
    Теперь остаётся ждать хардварной заплатки, либо снижения цен на старшие модели процессоров.


    1. interprise
      04.01.2018 01:38

      вы хотя-бы можете ее продать и тут же купить рейзен с небольшими потерями по деньгам. Я купил 6800к, который после выхода райзена подешевел почти в 2 раза и теперь не продать, и производительность на 6том поколении падает сильней и что делать хз.


      1. tbl
        04.01.2018 02:27

        только хотел в следующем месяце на рейзен переехать с FX-8350, не успел (( Ща цены на него взлетят


  1. vsespb
    04.01.2018 01:57

    Google считает что AMD тоже
    security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html

    These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel


    1. tbl
      04.01.2018 02:09

      В AMD branch target injection сработает на linux только если включить BPF JIT, но оно и понятно, что с помощью правил для файрвола и зондирования с локалхоста можно пощупать, что там в kernelspace хранится. Да и кому попало BPF настраивать не дают в ядре (по-хорошему только рут это должен делать).


  1. tbl
    04.01.2018 02:01

    Похоже, что в Intel спохватились и дали ответ в обход снятия эмбарго. Но он какой-то невнятный: «Баг — не баг, а эксплоиты не corrupt, modify or delete data». А то, что из юзерспейса можно почитать kernelspace — это по их мнению не critical.


    1. interprise
      04.01.2018 02:03

      да мелочь то какая, прочитать ssh ключи соседней машины. Правда, где тут критичность


      1. tbl
        04.01.2018 02:16

        из своего юзерспейса в соседний не пролезешь, только в гипервизор, но иногда и этого достаточно


        1. tbl
          04.01.2018 02:21

          ошибся, можно пролезть: с точки зрения бажного cpu — все равно, какие данные использовать для спекулятивного исполнения в предсказателе переходов — память ядра или память соседнего процесса


          1. DistortNeo
            04.01.2018 03:07

            А как текущий процесс попадёт в память соседнего процесса, если в таблице страниц памяти сидит только память текущего процесса и ядра?


            1. ElegantBoomerang
              04.01.2018 18:33

              Может! Например, в Линуксе для удобства в память ядра отображена вся физическая память. А одна из разновидностей уязвимости атакует через данные предсказания веток, чтобы другой процесс при исполнении работает за другое время — а это и замеряется, атака по сайд-каналу же.


              1. MacIn
                04.01.2018 20:14

                в Линуксе для удобства в память ядра отображена вся физическая память

                А если ее больше, чем address space за вычетом служебных зон? Скажем, 4 гига на 32 битной платформе?

                А если память соседнего процесса выгружена к своп?


                1. DistortNeo
                  04.01.2018 20:48

                  Видимо, это касается только 64-битных систем, где нет никакой проблемы отобразить всю физическую память в логическое адресное пространство.


                  А если память соседнего процесса выгружена к своп?

                  Наверное, зависит от того, происходит ли page fault с подгрузкой страницы в память при спекулятивном выполнении команд.


                  1. sumanai
                    04.01.2018 22:08

                    Наверное, зависит от того, происходит ли page fault с подгрузкой страницы в память при спекулятивном выполнении команд.

                    Вряд ли, это тормоза.


                  1. MacIn
                    04.01.2018 22:52

                    ПМСМ, если нужна подгрузка страницы, то это очень большой оверхед, чтобы можно было использовать такую уязвимость.


                1. ElegantBoomerang
                  04.01.2018 21:19

                  На 32битных системах мапят, как я знаю, отрезок, сколько влезет. Его постоянно переключать не очень удобно, вот на 64 битах и решили мапать всё.


    1. xcore78
      04.01.2018 20:25

      Этот текст писали юристы с определенной целью. Было бы странно оценивать его с технической точки зрения.


  1. rt3879439
    04.01.2018 02:01

    Владельцам гипервизоров остаётся страдать и плакать.


  1. mike_y_k
    04.01.2018 02:09

    Скачал последние исходники ядра.
    Буду смотреть на kpti и пытаться отделить истину от потока малосодержательной пока информации.
    Может тогда станет понятна суть ошибки.
    Возможно Intel найдёт менее торомозящее лекарство от собственных ошибок.
    Заодно стоит внимательно посмотреть на ситуацию с macOS, с прошлого года пока не открывал крышку…



  1. farcaller
    04.01.2018 02:17

    meltdownattack.com — еще детали и публикации исследований.


  1. tbl
    04.01.2018 02:34

    1. Krypt
      04.01.2018 03:01

      twitter.com/brainsmoke/status/948561799875502080
      Насколько я понял, кому-то удалось успешно провести атаку на практике. Так что «NOT OBSERVED ACTIVE DEPLOYMENT» — это временно.


      1. tbl
        04.01.2018 04:30

        Один из авторов статей Meltdown и Spectre у себя в твиттере обещает на следующей неделе выкладку исходников эксплоитов. Видео там интересное, хотелось бы посмотреть (да и следующий скрин про дамп памяти браузера интересен).


        1. firk
          04.01.2018 07:55

          Уже выложили https://spectreattack.com/spectre.pdf
          Как я понял это баг не совсем в конкретной реализации, а в самой идее предсказания ветвлений и предварительной подготовки к выполнению будущих инструкций, считая чтение операцией, не меняющей состояние (а она давно не такая из-за кеща). Если там всё по-честному проверять — предсказание ветвлений будет иметь гораздо меньше смысла. Если нет — получается вот такой read-only доступ куда не следует.
          И эти заплатки с изоляцией системной памяти от чего-то защитят, но всё равно могут оставить дыру в эксплуатации особенностей исполнения ядерного кода (в нём то ядерная память доступна и могут непреднамеренно быть конструкции, использующиеся в эксплойте с входными данными от юзера — когда его писали никто про такое не думал, да и даже зная о такой "особенности" сложно это предусмотреть везде).
          Но не всё так плохо. Получить доступ на чтение к ядерной памяти тут относительно легко, а вот к памяти соседнего процесса — намного сложнее, если вообще возможно (как описанным в статье способом так и тем вторым, что останется после этих заплаток). А важные данные типа паролей/ключей хранятся как раз обычно в памяти процессов, а не в ядре.


          1. firk
            04.01.2018 09:05

            А, упустил деталь
            тут https://meltdownattack.com/meltdown.pdf написано


            as well as the entire kernel space, which typically also has all physical memory (in-use) mapped

            видимо это нововведение 64-битных ядер (т.е. зависит от ОС, и не указано какой ОС, в каких-то этого может и не быть), из-за которого красть данные теперь можно не только из ядра, но и из соседних процессов (которые теперь там тоже выставлены на обозрение) тоже. Хорошо у меня 32-битное ядро хоть и на 64-бит проце.


            1. jcmvbkbc
              04.01.2018 10:12

              На 32-битном ядре почти гигабайт физической памяти замаплен точно так же. И нет, это не нововведение.


              1. firk
                04.01.2018 16:37

                Ну, гигабайт — далеко не вся память. И опять же это может зависеть от ОС. Замапленная память ядра — понятно зачем нужно, чтобы не переключать карту памяти для большинства системных вызовов, и если её убрать — действительно понизится быстродействие. И поэтому скорее всего так будет сделано по умолчанию во всех вменяемых современных ОС (до того, как привлекли внимание к обсуждаемой особености процов). Замапаленная просто рандомная (или вообще вся) физическая память — просто небольшое удобство и на быстродействие почти не влияет.


  1. crea7or
    04.01.2018 05:07

    Azure уже написал и обновляет виртуалки: Dear Azure customer,
    An industry-wide, hardware-based security vulnerability was disclosed today. Keeping customers secure is always our top priority and we are taking active steps to ensure that no Azure customer is exposed to these vulnerabilities.


    1. Suvitruf
      04.01.2018 09:02

      Ага, так обновил, что после ребута часть наших VPS сломались )=


      1. youROCK
        04.01.2018 11:45

        не только ваших :)


      1. crea7or
        04.01.2018 17:14

        у меня bsd постоянно ломается от их ребутов, а сам ребутнул в этот раз.


        1. Suvitruf
          04.01.2018 19:49

          У меня от этих ребутов на части машин сломался consul.io, к примеру. Он не особо любит внезапные ребуты. Хорошо хоть это не мастер ноды были.


    1. podivilov
      04.01.2018 18:34
      +1

      AWS молчит покамест?



  1. vsespb
    04.01.2018 10:51

    Интересно, можно как-нибудь сделать чтобы root процессы в host машине не тормозились этим патчем. Ибо руту всё равно можно всё и нечего его ограничивать. Тогда хоть будет возможность запустить какие-то тяжёлые задачи под рутом, что лучше чем ничего.


    1. vasimv
      04.01.2018 19:33

      В виртуалках тоже руты живут. Надо еще и проверять, что этот рут — настоящий рут :)


  1. alhimik45
    04.01.2018 10:58

    А что делать владельцам старых линуксовых ядер?) Будут ли бэкпорты в 3.x ветки?


    1. alix_ginger
      04.01.2018 11:39

      Если сделаете — будут!


      1. Areso
        04.01.2018 12:54

        Вы считаете у каждого программиста достаточно квалификации, чтобы сделать бэкпорт патча в старое ядро и успешно его собрать потом?)


        1. alix_ginger
          04.01.2018 16:31

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


          1. alhimik45
            04.01.2018 18:23

            То есть если человек сидит на старом ядре из-за того драйвера wifi для его ноутбука под 4ю ветку не собираются, то он сразу получает знания о бэкпортировании патчей в это ядро?


            1. alix_ginger
              04.01.2018 18:34

              Если он заботится о безопасности, то он же как-то устанавливает остальные патчи :)


  1. Hayate
    04.01.2018 11:53

    Версий процессоров без уязвимости нужно будет ждать пару лет?


    1. dfgwer
      04.01.2018 12:58
      -1

      Бери АМД


      1. vasiliysenin
        04.01.2018 18:11
        +1

        googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html?m=1
        АМД тоже подвержен этой уязвимости ( Spectre )


        1. iDm1
          04.01.2018 18:50
          +1

          Исходя из заголовка речь идет об уязвимости Meltdown, устранение которой программно как раз и снижает производительность, а ей процессоры AMD не подвержены.

          В случае со Spectre, которая касается всех процессоров, то ее снижающий производительность KPTI не устраняет. Над вариантами решения проблемы данной уязвимости работа все еще идёт и не ясно чем все закончится.


  1. NoRegrets
    04.01.2018 12:07
    -2

    Интелгейт какой-то. Это брак процессоров, имхо, и штеуд должен произвести замену. Хотя их лоеры со словами «это фича, а не баг» будут стоять до конца.


    1. willyd
      04.01.2018 13:07

      По вашей логиге, возможность намеренного повреждения шланга к вакуумному усилителю тормозов авто — это брак, и все машины должны быть отозваны.


      1. Hayate
        04.01.2018 13:13

        Скорее это наличие в машине центрального замка, сигнализации, бронестекла, видеорегистратора и при это форточки для проветривания которая никак не закрывается и находится в мёртвой зоне камеры.


      1. NoRegrets
        04.01.2018 13:17

        Кривая и глупая аналогия.
        Устройство используется по назначению, согласно тех. документации. И имеет такую ошибку в дизайне, которая не допускалась в тех. документации и которая снижает функциональность устройства. Это ошибка проектирования, брак. Пользователь получил не то, за что заплатил деньги.


        1. willyd
          04.01.2018 13:23

          Без действия третьей стороны все работает и нет никаких проблем. Функциональность не снижается, повреждений данных нет. Вы же работаете с продуктом по тех.документации.
          Атака — это действие третьей стороны, которое описать или предугадать невозможно.


          1. Neuromantix
            04.01.2018 13:43
            +1

            Я купил меганавороченную систему безопасности, однако она открывается зубочисткой. Но взлом системы безопасности — это действие третьей стороны. поэтому все нормально. Так что ли?
            Это таки брак — как минимум в том месте, где костыль жрет производительность (и не важно, 1% или 50%). Ну и это слишком опасный прецедент, чтобы оставлять корпорации безнаказанными — завтра они выпустят еще какое-нить баганутое поделие, а потом еще и еще — потому что ответственности ноль.


            1. willyd
              04.01.2018 14:03

              Еще раз.
              Вы не купили систему безопасности. Вы купили вычислительный модуль, который производит для вас вычисления. И в данном случае, проблем с этим нет — никаких, все вычисления он проводит в штатном режиме и его функциональность не нарушена. Обнаружили уязвимость в изоляции памяти ядра, но это проблема решается одной переменной в конфиге ядра линукса, к примеру. Где тут брак? Вы просто расплатитесь производительностью за безопасность своих личных или бизнес данных. И поверьте, на том же azure, aws, gcp крутятся сервисы компаний, для которых падение производительности на 5% исчисляться восьмизначными суммами долларов в год.
              Возвращаясь к автомобилям. Вы купили автомобиль, у него есть замок и ключ и какой-никакой иммобилайзер, но вы ставите дополнительную сигнальную систему, на которую нужно потратить деньги и которая добавляет точек отказа системы.


              1. Neuromantix
                04.01.2018 15:17

                Я не хочу расплачиваться своей производительностью за чужие баги. Я купил процессор с заявленными характеристиками ( в частности никто не заявлял. что он дырявый) и с заявленным быстродействием. И получил в итоге дыру и падение быстродействия, и мне еще говорят, что все нормально, так и должно быть.


                1. sumanai
                  04.01.2018 15:23

                  и с заявленным быстродействием.

                  А это что? Тактовая частота и прочие характеристики процессора ни капли не изменятся. Это ОС будет тормозить. Можете использовать старые ОС, я уверен, XP будет работать так же шустро, как и раньше.


              1. evgenyk
                05.01.2018 17:18

                «Перечитывал пейджер, много думал.»
                Процессор не только уязвим, он в своем кэше так же портит данные!

                Не в физической памяти конечно, а процесс может получить неверные данные.

                2) Не обязательно таймер, можно просто хранить 1 число и сравнивать значения, это сработает для случаев кроме того, когда считываемое значение равно хранимому числу.


          1. NoRegrets
            04.01.2018 15:13

            По тех.документации процесс не может читать память за пределами своих выделенных страниц. А он читает. Это невыполнение функции защищенного режима процессора. Одной из основных его функциональностей.
            Все ОСи написаны с учетом предоставляемой защиты, а ее по факту нет. И сейчас они городят кучу костылей, чтобы ее реализовать на софтовом уровне.


            1. willyd
              04.01.2018 15:57

              Как вы не поймете, от багов никто не застрахован, и даже при улучшении методологий тестирования, с сегодняшними темпами усложнения систем и перехода на более высокие уровни абстракций при написании программных продуктов, тенденция в раскрытии критических уязвимостей подобно этой будет усиливаться. Это естественный процесс, которому тяжело, что-то противопоставить, всегда найдется более умный, смекалистый, с нестандартным мышлением, который сможет создать условия и окружение для компрометации данных. Это не всегда будет приводить к таким масштабным последствиям, но думаю, что данная уязвимость открыла новую эпоху и нас ждет еще много чего интересного. c'est la vie…


              1. SADKO
                04.01.2018 20:25
                -1

                Смешно читать такие или около такие рассуждения ибо уязвимость то боянистая, лет шесть уже как модули на её основе имеются в продаже, пора бы и честь знать…
                И это не баг, вот уж чего обывателю никак не понять!
                Это новый контекст использования :-)
                И дело не в умении и смекалистости, дело в постановке задач, которые у каждого свои.


                1. willyd
                  04.01.2018 20:49
                  +1

                  Ну так поделитесь ссылкой на аукцион, а мы посмотрим.
                  А то как-то выходит, что 6 лет эксплойт в свободной продаже, но при этом никто и не слыхал про него. Это как? Я еще понимаю, если его спецслужбы используют, но тогда о какой свободной продаже может идти речь. А если другая сторона использует, то мы бы наверное чаще читали новости об уведенных кошельках или потерянных через swift суммах.
                  Мне вот тяжело понять, какая была «постановка задачи», что он всплыл только сейчас…


                1. metric_ghost
                  04.01.2018 21:00

                  Интелу тоже за шесть лет было никак не понять? Ждали, пока на них ведро навоза выплеснут? А подумаешь, репутация, штрафы, рыночная доля, это же всё просто слова, да?


      1. rogoz
        04.01.2018 16:26

        Если что, Интел отзывала процессоры по гораздо менее важной причине: ru.wikipedia.org/wiki/Ошибка_Pentium_FDIV


        1. saboteur_kiev
          04.01.2018 16:40

          Не отзывала, а предлагала обмен всем желающим, ибо в реальности, эта проблема касалась очень узкого круга пользователей. Сколько конкретно пользователей воспользовались услугой замены — неизвестно. Заявленные потери Интел учитывали в основном маркетинговые проблемы, а не саму замену процессоров.

          В данном же случае, проблема касается всех и каждого.


        1. vsespb
          04.01.2018 16:41

          Где сказано что отзывала?


        1. nidalee
          04.01.2018 16:45

          Они не будут их отзывать.
          Это все процессоры, которые они успели выпустить.


          1. antonksa
            05.01.2018 03:19

            Вы ошибаетесь. Ну не то чтобы ошибаетесь, просто это нужно писать очень большими буквами.
            ЭТО ВСЕ-ПРЕВСЕ ВООБЩЕ ПРОЦЕССОРЫ, КОТОРЫЕ ОНИ УСПЕЛИ ВЫПУСТИТЬ!


  1. kafeman
    04.01.2018 13:13
    +2

    meltdownattack.com

    Which systems are affected by Meltdown?
    Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013).


    1. kafeman
      04.01.2018 13:15
      +2

      Which systems are affected by Spectre?
      Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.


  1. vsespb
    04.01.2018 16:49

    Тут новость что придумывают патч, который не так сильно скажется на производительности www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Retpoline-Patches


    1. Aleks1113
      05.01.2018 03:19

      Да в принципе, пока что логично поставить те патчи, что есть, а потом уже с спокойной душой дождаться новых патчей, которые не будут так сильно бить по производительности — пускай некоторое время посидишь с замедленным компом, зато за сохранность данных банковской карты можно не беспокоиться.


    1. Sap_ru
      05.01.2018 13:31
      +1

      Это от spectre. А тормозит систему Meltdown. Сейчас их смешали в кучу, но это разные уязвимости, разные патчи и разные последствия.
      Spectre не так страшен и от него уже и так есть защита (отключение/эмуляция таймеров, дополнительный уровень гипервизора, шлюзы и т.п.) — вопрос в том, какой путь лучше.
      А с Meltdown все плохо — сброс кэша при перезагрузке таблиц страниц).
      Кстати, есть мнение, что рекламируемая PCID совсем не панацея. Там тэги не для всех видов данных и все равно частично кэш сбрасывается.


  1. no1D
    04.01.2018 17:20

    1. AtaZ
      05.01.2018 18:42

      Установил обновления, уж не знаю оно это или нет, но никаких существенных отличий в работе не заметил.


  1. pdk10
    04.01.2018 18:35
    -1

    предвижу массовые возвраты в магазины и коллективные иски, я вот не собираюсь копаться с патчами и терпень просадки производительности, компьютеру нет 6 месяцев, пусть intel выпускает официальный пресс релиз на основании которого организуют массовый отзыв процессоров, что делать с материнками под процессоры, которые все уязвимы тоже не понятно


  1. dakiev
    04.01.2018 18:35
    -2

    А никто не думает что уязвимость была заложена в интересах третьей стороны? Не страдаю теориями заговоров, но вероятность имеется и слишком уж долго уязвимость оставалась ненайденной.


    1. willyd
      04.01.2018 19:00
      +1

      Если бы делали закладку, она была бы более юзабельной в плане поиска нужных данных.


    1. metric_ghost
      04.01.2018 21:04

      Оставалась ненайденной, пока искать не начали. Да и слишком просто её использовать кому угодно после обнаружения, инфраструктура на процессорах интела не только в странах потенциального противника есть.


    1. abyrkov
      04.01.2018 22:54

      DirtyCOW тоже заложена в интересах третьей стороны?


  1. Nick_Shl
    04.01.2018 18:35
    +1

    Где группа подающих в суд? Запишите меня тоже!
    Только купил ThinkPad P71 с i7-7700HQ. Глядя тесты в интернете видел производительность возросла за последние 5 лет всего где-то на 16% и рассчитывал, что мой процессор ещё долго будет актуален, а тут баг который одномоментно "состарил" процессор на 5 лет!
    Пусть или процессор меняют(как это было с первым Пентиумом), или 30%(ладно, соглашусь и на 15%) от цены ноутбука возвращают!


    1. CapricornTV
      05.01.2018 18:42

      Тогда уж процент от цены процессора, интел не отвечает за всю остальную мишуру на вашем ноуте.


  1. crea7or
    04.01.2018 20:43

    Нда, красота, прям в риалтайме


  1. vasimv
    04.01.2018 22:56

    Почему мы это читаем не в блоге интел? Серьезная же проблема.


    1. FernandoAlfonso
      06.01.2018 14:48

      Вот поэтому и не читаем.


  1. Vnuchok
    05.01.2018 00:26

    блииииин!!!


  1. Farxial2
    05.01.2018 00:34

    и Intel по понятным причинам предпочитает молчать
    Это называется трусость.
    под удар, в первую очередь, могут попасть компании, использующие виртуализацию
    А их пользователи? И что им делать?


  1. chabapok
    05.01.2018 01:08

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


    1. Farxial2
      05.01.2018 01:17

      Потому что Intel ссыкуны и думающие о прибыли, а не о людях, эгоисты, ну. (Надеюсь, этот коммент не потрут, ибо оскорбление — поведение Intel.)
      Во-первых, всё зависит от микроархитектуры. Если микроархитектура позволяет, то можно обновить микрокод, и в худшем случае пострадает производительность. Т.е. полностью отключаем кэш, например. (Не, ну а что ещё делать? *dunno*)
      Во-вторых, если микархитектура не позволяет, то, наверное, надо честно сказать об этом людям, причём сказать, какая микроархитектура проблемная, а какая нет. Для этого может потребоваться раскрыть информацию о микроархитектурах — ибо как ещё людям понять, что их не обманывают? Но они не хотят и, скорее всего (если только не произойдёт чуда), не захотят сделать это из-за конкуренции.


      1. Farxial2
        05.01.2018 02:50

        Хм, похоже, я немного контекст потерял...)


        1. willyd
          05.01.2018 03:45

          Пользовательский?


          1. Farxial2
            05.01.2018 06:22

            Возможно.


    1. Darknet
      05.01.2018 12:04

      Сначала обновляем антивирус, Windows Update проверяет флаг в реестре перед установкой чтобы не упасть в BSOD. Обновляемый статус антивирусных продуктов.
      Затем устанавливаем обновление Windows, через Update или вручную.
      Используем скрипт Powershell от Microsoft, убеждаемся что CVE-2017-5754(Meltdown) закрыт.
      Обновляем браузеры, на Firefox утром прилетело обновление от Spectre.
      Проверяем сайт производителя на наличие обновления BIOS, устанавливаем если оно есть.
      Вновь запускаем скрипт от Майкрософта, убеждаемся что CVE-2017-5715 (Spectre) закрыт.
      Nvidia написала об обновлениях драйверов для устранения этой уязвимости, пока непонятно, но стоит проверять и их сайт.
      После этого можно слегка расслабиться.


      1. fpir
        05.01.2018 21:46

        И так на N машинах. Даже с winsus и политиками есть чем заняться, особенно с BIOS/UEFI.


  1. Serge3leo
    05.01.2018 02:11

    Хм. Так и Вы будете смеяться, но ещё в прошлом веке, Intel для по-настоящему защищённых операционных систем, а не всяких там Linux/Windows, реализовала «Time Stamp Disable (bit 2 of CR4)». Вероятно по заказу АНБ. Они что-то ещё тогда знали ;)


    1. Farxial2
      05.01.2018 02:24

      О, TSD это же круто.
      Добавлю, что при TSD=1 rdtsc[p] на x86 генерирует #GP(0), а значит можно запилить обработчик прерывания #GP(0), который будет эмулировать rdtsc[p]. И патчить кучу софта не потребуется. Если я прав, то было бы здорово.

      Хотя, может, злоумышленники могут использовать не только TSC…


      1. Serge3leo
        05.01.2018 02:37

        С тех появилось некоторое количество отладочных регистров и счётчиков производительности, но они тоже все отключаемые. А без них, ни meltdown, ни spectre, ни многое и многое иное, не пройдут ;)


        1. a5b
          05.01.2018 17:35

          Для замера времени без TSC иногда предлагают запустить второй поток, который будет просто постоянно инкрементировать счетчик в общей памяти. Метод от тех же самых Graz UoT… (Можно запретить потоки, запретить запускать свой код, запретить наличие кодогенераторов, см iOs: https://stackoverflow.com/questions/5054732/is-it-prohibited-using-of-jitjust-in-time-compiled-code-in-ios-app-for-appstor "3.3.2 An Application may not download or install executable code...")


          https://news.ycombinator.com/item?id=16066871&ref=hvper.com Timer coarsening is a bad idea. Turns out [1], a simple timer thread is a good enough poor man's cycle counter. What are you going to do: ban variables?
          https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_lipp.pdf ARMageddon: Cache Attacks on Mobile Devices (Moritz Lipp, Daniel Gruss et al, Graz, August 10–12, 2016) 3.3 Accurate Unprivileged Timing ..


          Cache attacks on x86 CPUs employ the unprivileged rdtsc instruction to obtain a sub-nanosecond resolution timestamp. The ARMv7-A architecture does not provide an instruction for this purpose… We broaden the attack surface by exploiting timing sources that are accessible without any privileges or permissions.
          Dedicated thread timer. If no interface with sufficient accuracy is available, an attacker can run a thread that increments a global variable in a loop, providing a fair approximation of a cycle counter. Our experiments show that this approach works reliably on smartphones as well as recent x86 CPUs. The resolution of this threaded timing information is as high as with the other methods.

          https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
          , mitigation we are disabling or reducing the precision of several time sources in Firefox. This includes both explicit sources, like performance.now(), and implicit sources that allow building high-resolution timers, viz., SharedArrayBuffer.


          1. Serge3leo
            05.01.2018 18:55

            На мой взгляд, Мозилла дует на воду, таймер в соседнем потоке имеет разрешение заметно ниже вариации работы кэш L1 или спекулятивного выполнения. Впрочем, это зависит от модели общей памяти, для Intel точно ниже.


  1. TheOleg
    05.01.2018 02:16

    Для диванных экспертов сделали первые бенчмарки.
    www.techspot.com/article/1554-meltdown-flaw-cpu-performance-windows
    www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2
    www.phoronix.com/scan.php?page=article&item=linux-more-x86pti&num=1
    Никаких 30% там даже близко нет.
    В некоторых играх так FPS даже чуть повысился.


    1. Sap_ru
      05.01.2018 13:23

      Это мало кому интересно. Основной рынок это сервера. И там все довольно плохо.


    1. Andy_U
      05.01.2018 14:03

      У меня на Windows 7.1 64 bit/i7 3770K@3.7 ггц/Geforce 1080/2560x1600 60 гц frame rate в игре WarThunder упал. До MS патча, с отключенной вертикальной синхронизацией было ~150 на максимальных настройках (в игре, а не во встроенном benchmark'е), причем загрузка видеокарты была под 100% (что позволяло играть на «fast» синхронизации с 120 гц «развертки»). А теперь все уперлось в процессор при frame rate чуть меньше 120 гц и загрузке видеокарты в 65-70%. Или процессор скальпировать и еще разгонять, или с настройками игры экспериментировать, или, что проще всего, отказаться от «fast» вертикальной синхронизации — тогда нагрузка на процессор (ядро) падает до ~70-80%, на видеокарту — до 55-60%.

      Пробовал отключить защиту с помощью ключей регистра (требуется перезагрузка!), описанных в: https://support.microsoft.com/en-gb/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution. Защита (см. Powershell скрипт, указанный в конце указанной страницы), отключается, но быстродействие не восстанавливается :(

      P.S. Если интересно, могу показать вывод скрипта до патча, после патча и после отключения защиты.


    1. creker
      05.01.2018 15:50

      Я не диванные эксперты читали, в каких условиях падение ожидается и почему? Эти тесты никаким образом не касаются ожидаемого замедления, которое на реальном софте тестами уже подтвердили неоднократно.


      1. TheOleg
        05.01.2018 16:17
        +1

        Как я понял, замедляется только работа с syscalls.
        В бенчмарках в моём комментарии видно проседание на процентов так 10, для реальности надо прибавить ещё само время работы серверов + сетевого стека.
        Сам гугл так же выпустил статью про то, что много спекулятивных статей и на их серверах «незначительное» изменение производительности.
        security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
        image


  1. Andrus_Trash
    05.01.2018 03:22

    Кажется, рано SPARC похоронили.



  1. N1ghtwish
    05.01.2018 18:44

    Как я понял это касается только датацентров, которые предоставляют доступ к виртуалкам? Так ведь это же замечательно, Xeon'ы E5 V3 скоро будут скидывать за бесценок!


    1. avpdnepr
      06.01.2018 03:47

      Если бы, за месяц нового процессора не выпустят


  1. unxed
    06.01.2018 04:10

    Интересно, почему никто из диванных аналитиков до сих пор не предположил наличие связи между стремительным ростом альткойнов (на фоне стабилизировавшегося биткойна), существенная часть которых майнится на процессорах, и временем обнаружения/раскрытия дыры в процессорах, спешно сделанное исправление которой «на некоторых задачах» даёт потерю производительности до 30%?


    1. alexr64
      06.01.2018 05:11

      Мимо. Майнинг к этим задачам не относится. При майнинге преобладают именно голые вычисления, а не активный IO, где нужно часто обращаться к ядру ОС.


      1. unxed
        06.01.2018 05:42

        Вне зависимости от алгоритма PoW?


        1. gearbox
          06.01.2018 13:29
          +1

          в худшем случае пострадают майнеры на дисковом пространстве. Их настолько мало что они интересны только самим себе. Все остальное мимо кассы, там из системных вызовов только работа с сетью.