На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS

Дорогие друзья! Поздравляем вас с Новым 2018 годом!

Всем удачи, успеха и благополучия!
В новом году ожидаем новых рекордов при подсчёте количества ёлочек на экране ;)


msm.ru
Соблюдайте Правила
Модераторы: Модераторы, Комодераторы
Страницы: (3) [1] 2 3  все  ( Перейти к последнему сообщению )  
    > Об инженерах, точнее инженерах Intel, вот это поворот!
      Разработчики Linux и Windows работают над закрытием аппаратной уязвимости процессоров Intel
      Цитата
      Ошибка проектирования всех процессоров Intel, выпущенных за последние 10 лет, заставила разработчиков Linux и Windows в срочном порядке перерабатывать схему разделения адресных пространств ядра и пользователя, брешь в которой вызвана этой ошибкой. По известным сейчас данным, переработка требует модификации критических частей ядра и приводит к падению производительности приложений от 5 до 30% (чипы Intel 2010 года и новее имеют в своём арсенале возможности, чтобы сократить это падение).

      Суть уязвимости, скорее всего, заключается в том, что спекулятивное исполнение кода косвенно нарушает контроль доступа, и это позволяет приложению «видеть» содержимое защищенного адресного пространства ядра (раннее описание). Детали уязвимости находятся под эмбарго до выпуска исправлений, который намечается на середину января 2018, когда выйдет новое ядро Linux и ежемесячное обновление безопасности для Windows.

      Для решения проблемы разработчикам ядер пришлось полностью разделить память ядра и память пользовательских процессов, однако такое решение приводит к серьёзному падению производительности из-за необходимости сброса части кэша транслированных виртуальных адресов (TLB) при входе в ядро.

      Разработчики ядра Линукса в шутку предлагали следующие аббревиатуры для новой модели разделения памяти ядра и пользовательских процессов: User Address Separation (*_uass) и Forcefully Unmap Complete Kernel With Interrupt Trampolines (fuckwit_*), однако остановились на Kernel Page Table Isolation (kpti_*).

      Компания AMD утверждает, что её процессоры уязвимости не подвержены.


      Заплатка сильно просаживает производительность линупса: Initial Benchmarks Of The Performance Impact Resulting From Linux
      Сообщение отредактировано: applegame -
      error: 'long long long' is too long for GCC
        Цитата applegame @
        однако остановились на Kernel Page Table Isolation
        Чорт! :wall:
        Здравым смыслом можно пренебречь, выбирая название для системы. Особенно в таких случаях.
        Сообщение отредактировано: negram -
          Инженеры AMD просто в эту уязвимость не наступили. Думаю, им просто повезло. Вряд ли они сколько-нибудь тщательнее, чем Intel'овские подобные дыры ищут.
          Всё написанное выше это всего лишь моё мнение, возможно ошибочное.
            Команды слишком разные, а потому узнать какая команда и сколь глубоко каждую брешь прощупала - сплошное гадание, думается мне. Хотя, у этих гигантов вполне может быть и коллективный обмен находящимся изъянам/неточностям. Впрочем, и это - гадание.
              Цитата applegame @
              Ошибка проектирования всех процессоров Intel, выпущенных за последние 10 лет

              Это не ошибка, а "фича" интеловских процессоров (быстрый доступ к кэшу L1 по виртуальным адресам). И существует она уже более 10 лет (начиная с Pentium 4). Куда все это время смотрели "разработчики Linux и Windows", не понятно.

              Цитата applegame @
              Суть уязвимости, скорее всего, заключается в том, что спекулятивное исполнение кода косвенно нарушает контроль доступа, и это позволяет приложению «видеть» содержимое защищенного адресного пространства ядра (раннее описание).

              Непосредственно ничего "видеть" нельзя, т.к. все эти нарушения контроля доступа существуют только внутри самого процессора (как черного ящика) до момента возникновения исключения. А то, что после обработки исключения могут оставаться некие побочные эффекты, которые могут нести информацию о прочитанном значении ядерной памяти (например, по времени доступа к кэшу), так это недоработки тех же разработчиков ОС, которые забыли сбросить кэш или еще чего.
                Цитата leo @
                Это не ошибка, а "фича" интеловских процессоров (быстрый доступ к кэшу L1 по виртуальным адресам). И существует она уже более 10 лет (начиная с Pentium 4). Куда все это время смотрели "разработчики Linux и Windows", не понятно.
                Ты уверен, что речь об этом? А то как-то странно получается. Никто об этой "фиче" не знал и только через 10 лет очнулись, а ты вот такой весь гениальный все давно уже, оказывается, знаешь. Такой сценарий, конечно, возможен. Но мне он представляется крайне маловероятным.
                Цитата leo @
                Непосредственно ничего "видеть" нельзя, т.к. все эти нарушения контроля доступа существуют только внутри самого процессора (как черного ящика) до момента возникновения исключения. А то, что после обработки исключения могут оставаться некие побочные эффекты, которые могут нести информацию о прочитанном значении ядерной памяти (например, по времени доступа к кэшу), так это недоработки тех же разработчиков ОС, которые забыли сбросить кэш или еще чего.
                То есть все эти разработчики линухов и виндовсов тупорылые лохи, им надо к тебе обратиться за консультацией?
                Однако, какое высокое самомнение у тебя, чувак. Может ты и прав и твое самомнение соответствует действительности. Посмотрим.
                Сообщение отредактировано: applegame -
                error: 'long long long' is too long for GCC
                  Цитата leo @
                  Это не ошибка, а "фича" интеловских процессоров (быстрый доступ к кэшу L1 по виртуальным адресам). И существует она уже более 10 лет (начиная с Pentium 4). Куда все это время смотрели "разработчики Linux и Windows", не понятно.

                  Если бы была просто фича с 10 летней историей, акции амд не поднялись бы на 10% а интел не упали бы на 6.
                  Помню когда корка вышла, там было около 200 ошибок(документ потом стал недоступен)
                  "Воля - это то, что заставляет тебя побеждать, когда твой рассудок говорит тебе, что ты повержен" Карлос Кастанеда
                    applegame
                    Странное у вас сообщение. Обычно новость публикуют после выхода патча а вы пишете о середине января.

                    Проверил по своим каналам Американци уже отчитали, что в декабре закрыли:
                    https://lkml.org/lkml/2017/12/4/709
                    Правильный обед должен состоять из 5 блюд приготовленных из 33 ингредиентов.
                      1. Информации 0.
                      2. Разделение ядра и пространства пользователя имеет смысл. Но не для борьбы с конкретным багом, а как борьба с целым рядом угроз основанных на чтении памяти ядра из ядерного пространства. Только к багам CPU это не имеет отношение.
                      И всё равно это не спасёт.
                      3. Разделение надо было делать поверх виртуализации, а не как сейчас.

                      Так что ихмо это интел раскручивает новые процессоры. Чёрный пиар всё равно пиар. Да и МС это на руку так как линукс просядет по скорости.
                      Правильный обед должен состоять из 5 блюд приготовленных из 33 ингредиентов.
                        Полностью отделить ядро невозможно. Как минимум в памяти должны оставаться обработчики исключений и прерываний.
                        Цитата TheMachine @
                        т.е. в общем случае вы правы конечно, а мне надо спать больше а пить меньше
                          Цитата https://www.opennet.ru/opennews/art.shtml?num=47856
                          Разработчики из Google Project Zero опубликовали детали двух уязвимостей, которые получили кодовые имена Meltdown и Spectre. Процессоры Intel и ARM64 подвержены обеим проблемам, AMD затрагивает только вторая уязвимость. Производители процессоров были уведомлены о проблемах 1 июня 2017 года. Для демонстрации атак подготовлены работающие прототипы эксплоитов, в том числе реализация на JavaScript, работающая в браузере.

                          Уязвимость Meltdown (CVE-2017-5754) позволяет приложению прочитать содержимое любой области памяти компьютера, включая память ядра и других пользователей. Проблема также позволяет получить доступ к чужой памяти в системах паравиртуализации (режим полной виртуализации (HVM) проблеме не подвержен) и контейнерной изоляции (в том числе Docker, LXC, OpenVZ), например, пользователь одной виртуальной машины может получить содержимое памяти хост-системы и других виртуальных машин. Уязвимости подвержены процессоры Intel (фактически все процессоры, выпускаемые с 1995 года, за исключением Intel Itanium и Intel Atom, выпущенных до 2013 года) и ARM64 (Cortex-A15/A57/A72/A75). Подготовленный прототип эксплоита позволяет читать память ядра со скоростью 2000 байт в секунду на процессоре Intel Xeon архитектуры Haswell.

                          Уязвимость Spectre (CVE-2017-5753, CVE-2017-5715) создаёт брешь в механизме изоляции памяти приложений и позволяет атакующему обманным способом получить данные чужого приложения (только приложения, но не памяти ядра). Этой атаке подвержены процессоры Intel, AMD (только при включенном eBPF в ядре) и ARM64 (Cortex-R7/R8, Cortex-A8/A9/A15/A17/A57/A72/A73/A75). По сравнению с Meltdown уязвимость существенно труднее в эксплуатации, но её и значительно труднее исправить. Прототип эксплоита Spectre уже можно найти в открытом доступе.

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

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

                          Пользователям рекомендуется установить обновление ядра сразу после его публикации для дистрибутивов. Исправление проблемы Meltdown для ядра Linux выпущено в виде набора патчей KPTI. Исправление уязвимости Spectre в общем виде пока не выработано, частично предложено обновление микрокода и усиление безопасности отдельных приложений. Обновление для блокирования Meltdown уже выпущено для RHEL и Fedora. Проследить за появлением обновлений в других дистрибутивах можно на следующих страницах: Debian, Ubuntu, SUSE (частично исправлена), openSUSE, FreeBSD, OpenBSD, NetBSD. Исправления для Windows и macOS ожидаются в ближайшее время. Для платформы Android исправления были доставлены в последнем обновлении. Проблема также устранена в Chrome OS 63.

                          Применение патча обязательно так как пользователи ежедневно запускают чужой код на своих компьютерах, посещая веб сайты с JavaScript (>99%) и одним из инструментов совершения атаки может стать web-браузер. Разработчики Google Chrome работают над интеграцией защиты от совершения атаки через JavaScript прямо в браузер. Исправление будет доступно в релизе Chrome, назначенном на 23 января. Компания Mozilla внесла в Firеfox 57 временные исправления, затрудняющие атаку, ограничив точность работы таймера (performance.now) до 20µs и отключив SharedArrayBuffer.

                          Интересен комментарий Торвальдса: текущие патчи безусловно включили KPTI для всех процессоров и архитектур Intel, что может означать, что у компании нет кристаллов, в которых эта ошибка исправлена, а это может значить, что Cannon Lake/Ice Lake выйдут с этой же проблемой.


                          Добавлено
                          И на данный момент, нет точного понимания подвержены ли камешки AMD первой уязвимости, слухи о том, что не подвержена идут от отсутствия подтверждения.
                          Цитата
                          Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
                          Сообщение отредактировано: negram -
                            Цитата Pavia @
                            applegame
                            Странное у вас сообщение. Обычно новость публикуют после выхода патча а вы пишете о середине января.

                            Проверил по своим каналам Американци уже отчитали, что в декабре закрыли:
                            https://lkml.org/lkml/2017/12/4/709

                            Странное у вас сообщение. Это не мое сообщение и это не я пишу о середине января.
                            Ты уверен, что идет речь именно об этом патче?

                            Цитата Pavia @
                            Так что ихмо это интел раскручивает новые процессоры. Чёрный пиар всё равно пиар. Да и МС это на руку так как линукс просядет по скорости.
                            Странный способ раскрутить новые процессоры обосрав самих себя. И с чего ты взял, что производительность Windows не просядет?

                            Вот жеж самоуверенных защитников Intel понабежало. :)
                            Сообщение отредактировано: applegame -
                            error: 'long long long' is too long for GCC
                              Цитата applegame @
                              Странный способ раскрутить новые процессоры обосрав самих себя. И с чего ты взял, что производительность Windows не просядет?

                              Это неважно. Все уже слышали что Линукс просядет на 30%.
                              А про виндоус некто не слышал. Тем более это не единственный способ борьбы. С точки зрения защиты достаточно защитить не всё ядро,а небольшой участок именуемый хранилище секретов. А защитить само хранилище секретов можно путем unmmap при выходе из ядра. При unmmap происходит сброс кэша. А до mmap сколько бы сплоит не читал память он будет попадать в некуда или можно положить "утку". Даже если есть ошибка в CPU, то её можно закрыть путём подбора последовательности из кучи команд которая сбросит все внутренние буферы.

                              Цитата applegame @
                              Странный способ раскрутить новые процессоры обосрав самих себя.

                              Поиском уязвимостью может заниматься только сами. Если эти займётся кто-то со стороны, то его можно обвинить в разработки зловредных программа. Несколько лет тюрьмы и огромные штрафы. И такие случае известны.
                              Сообщение отредактировано: Pavia -
                              Правильный обед должен состоять из 5 блюд приготовленных из 33 ингредиентов.
                                Цитата ^D^ima @
                                Если бы была просто фича с 10 летней историей, акции амд не поднялись бы на 10% а интел не упали бы на 6.

                                Акции взлетают и падают от любой раздутой шумихи в СМИ, которая может иметь весьма отдаленное отношение к действительности или не иметь его вообще.
                                Цитата applegame @
                                Ты уверен, что речь об этом?

                                Да. Почитай хотя бы цитату, приведенную negram в #11. Если угодно, можно привести ссылки и на профессиональные\оригинальные исследования (хотя для их понимания не мешало бы поштудировать мануалы от Intel и А.Фога).
                                Цитата applegame @
                                Никто об этой "фиче" не знал и только через 10 лет очнулись

                                Об этой фиче должны были знать все (кому нужно и положено), т.к. она описана во всех мануалах Intel. Но никому до сих пор не приходило в голову ее использовать через тонкие сайд-эффекты (сайд-каналы) типа замера времени доступа к кэшу. Поэтому тут "рыло в пуху" не столько у Интел, сколько у разработчиков ОС, которые "бездумно" мапят ядерные страницы в юзермодное пространство (якобы) для ускорения доступа. Однако если они не полные идиоты и мапят не все подряд, а лишь то, что реально необходимо, то масштаб проблемы сильно раздут, т.к. прочитать таким хитрым способом можно не всю ядреную память, а лишь часть, замапленную в юзермод. Не мапь лишнего и сбрасывай кэш после обработки исключения нарушения прав доступа - и все будет ОК.
                                  Цитата leo @
                                  Если угодно, можно привести ссылки и на профессиональные\оригинальные исследования
                                  Эта ссылка появилась только сегодня утром и там есть ссылки на источник информации и все связанные публикации...
                                  Впрочем, ваш тон немного вызывающ. Утверждается, что при правильной обработке, производительность сильно падает, так-что либо слово "якобы" лишнее, либо стоит им показать как надо программировать.
                                  1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
                                  0 пользователей:
                                  Страницы: (3) [1] 2 3  все


                                  Рейтинг@Mail.ru
                                  [ Script Execution time: 0,1387 ]   [ 14 queries used ]   [ Generated: 16.01.18, 07:14 GMT ]