Когда исследователь Майкл Шварц из Грацского технического университета впервые связался с компанией Intel, он думал, что расстроит её. Он нашёл проблему в их чипах, работая совместно с коллегами — ему помогали Дэниел Грасс, Мориц Лип и Стефан Мангард. Уязвимость была глубокой и легко используемой. Его команда закончила писать эксплоит 3-го декабря, воскресным днём. Оценив возможные последствия своей находки, они немедленно написали в Intel.
Ответ Шварц получил только через девять дней. Но когда ему позвонили из компании, Шварц удивился: компания уже знала о проблемах с ЦП, и отчаянно пыталась понять, как их исправить. Более того, компания делала всё возможное, чтобы гарантировать, что больше никто не узнает об этом. Они поблагодарили Шварца за его вклад, но сказали, что обнаруженная им информация совершенно секретна, и дали ему дату, после которой этот секрет можно было раскрывать.
Проблема, которую обнаружил Шварц — и, как он потом узнал, много кто ещё — потенциально была катастрофической. Уязвимость на уровне схемы чипа, которая могла замедлить работу любого процессора в мире, при отсутствии идеального исправления за исключением переработки всего чипа. Она поразила практически все крупные технокомпании мира, от серверных ферм Amazon до производителей чипов вроде Intel и ARM. Но Шварц столкнулся с ещё одной проблемой: как сохранять в секрете такую серьёзную уязвимость достаточно долго, чтобы её можно было исправить?
Раскрытие — старая проблема в мире безопасности. Когда исследователь находит баг, обычно принято давать изготовителям несколько месяце форы на исправление проблемы до того, как она становится доступной широкой публике и у плохих людей появятся шансы её использовать. Но чем больше компаний и продуктов подвержено найденным проблемам, тем сложнее становится этот танец. Чем большое программ нужно по-тихому разработать и продвинуть, тем большему количеству людей требуется сообщить о проблеме и попросить держать её в секрете. В случае с Meltdown и Spectre эта координация по удержанию секретов провалилась и секрет проявился раньше, чем кто-либо успел к нему подготовиться.
У преждевременного раскрытия есть последствия. После обнародования информации наступает путаница — например, подвержены ли чипы от AMD атакам Spectre (подвержены) или характерен ли Meltdown только для Intel (чипы от AMD тоже пострадали). Антивирусные системы оказались пойманными врасплох, и ненамеренно заблокировали множество критических патчей. Разработку других патчей пришлось приостановить после того, как компьютеры переставали работать из-за них. Один из лучших инструментов, подходящих для исправления уязвимости, Retpoline, разрабатывала команда по реагированию на происшествия Google, и изначально они планировали выпустить его одновременно с информацией о баге. Но хотя команда разработчиков Retpoline утверждает, что её не застали врасплох, код этого инструмента не выкладывали в общий доступ вплоть до дня, последовавшего за тем, когда впервые было объявлено о наличии уязвимости, в частности из-за случайного прорыва секретности.
Что больше всего волнует, так это что многие критически важные группы, реагирующие на уязвимости, вообще были не в курсе происходящего. Самое влиятельное предупреждение по поводу имеющейся уязвимости пришло из подразделения CERT Карнеги-Мелон, работающего с Министерством внутренней безопасности по вопросам обнародования уязвимостей. Но, согласно главному аналитику уязвимостей Уилу Дорману, в CERT не знали об этой проблеме до тех пор, пока не были запущены сайты Meltdown и Spectre, что привело к усилению хаоса. В изначальном отчёте замена ЦП была указана как единственное решение. Технически такой совет был правильным в случае с ошибкой в схеме процессоров, но он лишь приумножил панику среди менеджеров в сфере IT, представивших себе, как они выковыривают и заменяют ЦП на всех подотчётных устройствах. Через несколько дней Дорман с коллегами решили, что их совет на практике неприменим, и заменили рекомендацию на простую установку патчей.
«Мне бы хотелось знать заранее, — говорит Дорман. — Если бы мы узнали об этом раньше, мы бы смогли выпустить более точный документ, и люди бы сразу получили гораздо больше информации, а не как сейчас, когда мы проверяем патчи и обновляем документ всю последнюю неделю».
Но, возможно этих проблем нельзя было избежать? Даже Дорман в этом не уверен. «Это крупнейшая множественная уязвимость, с которой мы когда-либо имели дело, — сказал он мне. — С уязвимостью таких масштабов невозможно выйти сухим из воды так, чтобы все остались довольны».
Первый шаг в раскрытии уязвимостей Meltdown и Spectre был сделан шесть месяцев назад, до открытия Шварца, в письме от 1 июня, отправленном Яном Хорном, участником проекта Google Project Zero. Письмо, направленное в Intel, AMD и ARM, расписывалась новая уязвимость, которая получит название Spectre, и демонстрировался эксплоит процессоров Intel и AMD, и неприятные последствия для ARM. Хорн подошёл к этому с осторожностью и выдал изготовителям только необходимый минимум информации. Он специально обратился к трём производителям чипов, и призвал каждую компанию разобраться с тем, как ей самой предать дело огласке и связаться с другими компаниями, на которых ситуация может сказаться. В то же время Хорн предупредил их, чтобы они не распространяли информацию слишком далеко и слишком быстро.
«Учтите, что пока мы не сообщили об этом в другие отделы Google, — писал Хорн. — Сообщая об этом третьим лицам, старайтесь не распространять информацию без нужды».
Довольно сложным делом оказалось установить, кто именно подвержен уязвимости. Началось всё с изготовителей чипов, но вскоре стало понятно, что необходимо будет патчить операционные системы, что требовало привлечения ещё одного круга исследователей. Это должно повлиять и на браузеры, а также на массивные облачные сервисы, управляемые компаниями Google, Microsoft и Amazon, которые можно было считать наиболее привлекательными целями для нового бага. В итоге десяткам компаний со всех концов света придётся выпускать тот или иной патч.
Официальной политикой Project Zero было предоставлять 90 дней перед публикацией новостей, но чем больше компаний присоединялось к кругу избранных, тем сильнее Project Zero уступал своим требованиям, и продлил этот период больше, чем в два раза. Шли месяцы, компании начали выпускать собственные патчи, стараясь скрыть, что именно они исправляли. Команда реагирования на происшествия из Google получила информацию в июле, через месяц после первого предупреждения от Project Zero. Программа Microsoft Insiders выпустила тихий ранний патч в ноябре. В этот период директор Intel Брайан Кржанич совершал более спорные действия, в октябре заказав автоматическую продажу акций на 29-е ноября. 14 декабря клиенты Amazon Web Server получили предупреждение, что 5 января волна перезагрузок компьютеров может сказаться на быстродействии. Ещё один патч от Microsoft был скомпилирован и выпущен в канун Нового года, что говорит, что команда компании, вероятно, работала над ним всю ночь. В каждом из случаев причины изменений были размытыми, и пользователи мало что знали о том, что именно исправляется.
Нельзя однако переписать основы инфраструктуры интернета, чтобы это кто-нибудь не заметил. Самые толстые намёки пришли из мира Linux. Эта ОС, на которой работает большинство облачных серверов в интернете, обязана играть большую роль в любом исправлении ошибок Spectre и Meltdown. Но, так как исходный код этой системы открыт, любые изменения придётся предъявлять общественности. Каждый апдейт выкладывался на открытый Git-репозиторий, и все официальные обсуждения проходили на общедоступном списке рассылки. Когда для загадочной функции «page table isolation» один за другим начали выходить патчи для ядра ОС, пристально наблюдавшие за этим люди поняли, что что-то не так.
Самым большим намёком стало событие от 8 декабря, когда Линус Торвальдс принял новый патч, изменявший то, как ядро Linux работает с процессорами x86. «Это исправление, кроме того, что исправляет утечки KASLR), также усиливает код для x86», — пояснил Торвальдс. А самый последний выпуск ядра вышел всего за день до этого. Обычно патч должен был подождать включения в следующий релиз, но по какой-то причине этот патч был слишком важным. Отчего же обычно капризный Торвальдс вдруг так просто включил внештатное обновление, особенно если оно вроде бы может замедлить работу ядра?
Ещё страннее выглядело вдруг появившееся письмо месячной давности, в котором предлагалось обновить старые ядра новым патчем задним числом. Суммируя слухи, 20-го декабря ветеран Linux Джонатан Корбет написал, что проблема с таблицей страниц «имеет все признаки патча безопасности, выпущенного под давлением дедлайна».
И всё же им было известно не всё. Page Table Isolation, «изоляция таблицы страниц» — это способ отделить пространство ядра от пространства пользователей, поэтому проблема явно была в какой-то утечке из ядра. Но оставалось непонятным, что именно неправильно работало в ядре или как далеко распространялось действие этого бага.
Следующее известие пришло от самих производителей чипов. В новом патче Linux описал все процессоры x86 как уязвимые, включив туда и процессоры от AMD. Поскольку патч занижал быстродействие, AMD была не рада включению этого патча. На следующий день после Рождества [католического, 25 декабря / прим. перев.] инженер AMD Том Лендаки отправил письмо в список рассылки по ядру Linux, объясняя, почему именно чипам от AMD патч не требовался.
«Микроархитектура AMD не позволяет оперировать такими ссылками на память, в том числе спекулятивными, которые получают доступ к привилегированным данным, работая в менее привилегированном режиме, в тех случаях, когда такой доступ может привести к ошибке „page fault“, — писал Лендаки.
Вся эта история переполнена техническими терминами, но для всех людей, пытавшихся выяснить сущность ошибки, она звучала, как пожарная тревога. Инженер из AMD точно знал об уязвимости, и говорил, что проблема ядра проистекала из чего-то такого, что процессоры делают уже почти 20 лет. Если проблемой были спекулятивные ссылки, эта проблема касалась всех — и для её исправления должно потребоваться нечто гораздо большее, чем простое исправление ядра.
»Это послужило толчком, — говорит Крис Уильямс, редактор The Register. — До того момента никто не упоминал спекулятивные ссылки на память. Только после появления этого письма мы поняли, что что-то не так".
Когда стало ясно, что проблема связана со спекулятивными ссылками, исследователи смогли дорисовать картину до конца. Годами исследователи безопасности искали методы взлома ядра через спекулятивное выполнение программ; команда Шварца из Граца опубликовала работу по этому поводу аж в июне. Андерс Фог опубликовал свои попытки похожих атак в июле, хотя они и не увенчались успехом. Всего через два дня после письма из AMD исследователь под ником brainsmoke представил работу по этой теме на конференции Chaos Computer Congress в Лейпциге. Все эти работы не привели к открытию бага, пригодного для эксплуатации, но благодаря ним стало ясно, как он должен выглядеть — и выглядел он крайне плохо.
Фог сказал, что с самого начала было ясно — любой рабочий баг обернётся катастрофой. «Когда вы начинаете изучать что-то подобное, вы уже знаете, что ваш успех приведёт к очень плохим последствиям», — сказал он мне. После выпуска Meltdown и Spectre и разразившегося хаоса, Фог решил не публиковать дальнейшие исследования по этой теме.
На последовавшей неделе слухи о баге стали просачиваться через Twitter, списки рассылки и форумы. Обычный измеритель скорости, пролетевший в списке рассылки PostgreSQL, обнаружил 17% замедление быстродействия — ужасное число для людей, ожидавших патч. Другие исследователи писали неформальные посты, описывая всё, что им известно, и подчёркивали, что это всего лишь слухи. «Эта статья в основном предоставляет догадки, до тех пор, пока не будет отменено эмбарго», — писал один из авторов. «А в этот день следует ожидать фейерверков и драматических событий».
К Новому году слухи стало невозможно игнорировать. Уильямс решил, что пора что-то написать. 2-го января The Register опубликовала статью о том, что они назвали «недостатком в схеме процессоров Intel». Там описывалось то, что происходило в списке рассылки Linux, зловещее письмо из AMD, и ранние исследования. «Из того, что описал программист Том Лендаки из AMD, следует, что ЦП от Intel грешат спекулятивным выполнением кода без проверок на безопасность», — говорилось в статье. — Это позволит пользовательскому коду уровня ring-3-level читать данные с уровня ядра ring-0-level. А это нехорошо".
Решение о публикации этой статьи оказалось противоречивым. Индустрия предполагала существование эмбарго на распространение информации, дающего компаниям время на выпуск патчей. Раннее распространение новостей урезало это время, и давало преступникам шансы использовать уязвимости до появления патчей. Но Уильямс утверждает, что ко времени выхода статьи секрет уже был раскрыт. «Я считал, мы обязаны предупредить людей, что, когда эти патчи выйдут, их точно необходимо устанавливать, — говорит Уильямс. — Если вы достаточно умны, чтобы использовать такой баг, вы бы и без нас о нём догадались».
И в любом случае эмбарго продержалось бы всего ещё один день. Официальный выпуск планировался на 9 января, одновременно с четверговыми патчами от Microsoft и прямо в разгар выставки потребительской электроники Consumer Electronics Show, что могло бы приглушить плохие новости. Но комбинация из диких слухов и доступных исследователей сделала невозможным сдерживание новостей. Репортёры забрасывали исследователей письмами, и все, кто имел в этому отношение, изо всех сил старался сохранять молчание, поскольку вероятность того, что секрет продержится ещё неделю, постоянно уменьшалась.
Переломный момент наступил благодаря brainsmoke. Он был одним из малого числа исследователей ядра, на которых не распространялось эмбарго, поэтому он воспринял слухи как руководство к действию и решил отыскать этот баг. На следующее утро после статьи в The Register он его нашёл, и твитнул скриншот своего терминала в качестве доказательства. «Никаких page fault не нужно, — писал он в последовавшем твите. — Основной вопрос, судя по всему, содержится в том, чтобы перетаскивать всё в кэш и из кэша».
Когда исследователи увидели этот твит, всё и завертелось. Команда из Граца твёрдо решила не раскрывать карты до Google или Intel, но после распространения доказательств возможности использования бага из Google поступило сообщение о том, что эмбарго будет отменено в тот же день, 3 января, в 2 часа дня по тихоокеанскому времени. В назначенный час полная версия исследования появилась на двух специально подготовленных сайтах, вместе с предварительно подготовленными логотипами каждой из уязвимостей. Сообщения потекли рекой из ZDNet, Wired и The New York Times, часто описывая информацию, собранную всего за несколько часов до этого. После более чем семи месяцев планирования секрет, наконец, вышел наружу.
Пока сложно сказать, во сколько обошёлся ранний выход. Патчи всё ещё разрабатываются, а измерители скорости ещё подсчитывают итоговые потери. Прошло бы всё более гладко, если бы на подготовку была ещё одна лишняя неделя? Или она просто оттянула бы неизбежное?
Можно найти множество формальных документов, описывающих, как должен происходит анонс подобных уязвимостей, например, у международной организации по стандартам, у министерства торговли США, у CERT — хотя у них можно найти мало чётких советов по поводу настолько серьёзной проблемы. Эксперты годами мучаются с подобными вопросами, и самые опытные из них уже отчаялись найти идеальный ответ.
Кэти Муссурис помогала писать в Microsoft инструкцию для подобных событий, совместно со стандартами ISO и бесчисленным количеством прочих инструкций. Когда я попросил её оценить реакцию общественности на этой неделе, она описала её мягче, чем я ожидал.
«Возможно, лучше уже нельзя было ничего сделать, — сказала она. — Стандарты ISO могут сказать вам, о чём нужно задуматься, но они не скажут вам, что делать на пике развития подобной ситуации. Это похоже на то, как вы читаете инструкции и выполняете парочку учебных тревог. Хорошо, когда есть план, но когда ваш дом горит, вы действуете не так, как написано в плане».
Чем больше технология централизуется и обрастает внутренними связями, тем сложнее становится избегать подобных пожарных тревог. С распространением протоколов типа OpenSSL увеличивается риск массивных багов вроде Heartbleed, интернет-версии болезни зерновых культур. Эта неделя продемонстрировала сходный эффект, влияющий на железо. Спекулятивное выполнение стало стандартом индустрии до того, как у нас было время на обеспечение его безопасности. И поскольку большая часть веб-сервисов выполняется на одних и тех же чипах и на одних и тех же облачных сервисах, этот риск увеличивается многократно. И когда уязвимость наконец проявилось, в результате задача её правильного освещения стала почти невыполнимой.
Подобной неразберихи тяжело избежать при любом отказе ключевых технологий. «В 90-х у нас был девиз — одна уязвимость, один производитель, и таких уязвимостей было большинство. А теперь практически где угодно присутствует элемент координации нескольких заинтересованных сторон, — говорит Муссурис. — Вот так и выглядит реальное освещение проблем, связанных с работой нескольких заинтересованных сторон».
Комментарии (70)
almuerto
18.01.2018 15:28Она поразила практически все крупные технокомпании мира, от серверных ферм Amazon до производителей чипов вроде Intel и ARM.
Корректно ли это высказывание? ARM — архитектура процессоров, ARM ltd., впрочем, чипы тоже не производит.
Dvlbug
18.01.2018 16:19ИМХО, уязвимость затронула чипы на архитектуре ARM, соответственно это предложение можно считать верным. Может быть не все, но всё-таки.
Alex_Sa
18.01.2018 22:51Так проблема как раз с архитектурой. Так что любой производитель чипов с ядром от АРМ соответсвующей архитектуры будет подвержен уязвимости. Правда не все типы АРМ имеют такие проблемы. Список проблемных — developer.arm.com/support/security-update
reversecode
18.01.2018 17:04+4насколько я понимаю об этой уязвимости знали еще в 2010 году
twitter.com/rootkovska/status/948997805158338560geisha
19.01.2018 03:17Там черным по белому автор написал, что в 2010 у них ничего не получилось. Атаки по таймингу они не предлагали. Судя по куску отчёта, они действительно собирались спекулятивно подгружать память в кэш и, наверное, использовать какие-то баги гипервизора чтобы прочесть её.
alexoron
18.01.2018 19:27-5Так вот как ФСБ получила доступ к секретным данным против предвыборной кампании Хилари.
Farxial2
18.01.2018 21:37Я так и не понял: какие у Intel есть основания (из нормальных, естественно) держать в секрете информацию о микроархитектурах и спецификацию микрокода (а также информацию о его шифровании) и не давать поработать над проблемой IT-сообществу? Читать о том, как Intel боролась с проблемой, конечно, забавно, но хотелось бы, чтобы сама проблема была решена.
asoukhoruchko
18.01.2018 22:54Боролась не только Интел, но ещё и команда ядра Линукса, Гугл, Амазон, Майкрософт, Амд и прочие. А разглашать информацию до этого означало проинформировать хакеров о проблеме до того, как у кого-нибудь будет решение.
Собственно, поэтому некоторые патчи были применены до того, как о проблеме стало известно широкой публике. И в статье об этом говорится.Farxial2
19.01.2018 00:041. Ну, а как на счёт текущего момента? О уязвимости уже известно.
2. Не обязательно было разглашать информацию о самой уязвимости — можно было просто предоставить спецификации микроархитектуры и кода. Кто-то нашёл бы уязвимость… А кто-то другой, возможно, дополнил бы архитектуру нужными ему фичами — и это было бы круто независимо от устранения уязвимости.
zagayevskiy
19.01.2018 12:13Почему Intel должен это делать? Не должна ли Apple опубликовать полную спецификацию iPhone X, чтобы любой мог дополнить его нужными фичами?
Farxial2
19.01.2018 13:13Не должна ли Apple опубликовать полную спецификацию iPhone X, чтобы любой мог дополнить его нужными фичами?
Хороший вопрос! Попробуете сами на него ответить? =)zagayevskiy
19.01.2018 14:30Я думаю, что нет, не должна.
Farxial2
19.01.2018 14:51Почему Вы так думаете?
Я наоборот считаю, что должна. Выгода для общества vs. выгода для компании — мне кажется, сравнить это можно даже не взвешивая в граммах.
kosmos89
19.01.2018 20:59Вы сейчас предлагаете компаниям заниматься иррациональными вещами. Польза для общества — не самоцель для компаний. Заработать денег — вот смысл существования любого бизнеса.
Farxial2
19.01.2018 21:48Я простой человек, не работающий в этих компаниях и не имеющий профита с их профита — это значит, что у меня нет сдерживающих факторов, запрещающих осуждать их бизнес. Как, впрочем, и бизнес вообще. Мне отвратительна эта экономическая система, в которой надо перекладывать деньги из чужого кармана в свой. А эти лица, сколько бы у них не было миллионов денег или власти — лишь рабы этой системы. Это недостойно уважения. (Чую, щас опять посыпятся минусы. Но минусующим просьба подкреплять это хоть какими-то аргументами, OK?) И из хороших вещей остаётся только конкуренция как движущая сила развития. Однако:
1. То, что люди не хотят нормально развиваться, если их не пинать под зад — тоже проблема. (Хоть я и сам, увы, отношусь к такому типу людей — это не значит, что я должен перестать считать проблему проблемой.)
2. Ничто не мешает, скажем, открыть свои разработки сообществу, а потом улучшить их настолько, что разработки сообщества померкнут на их фоне. И делать так каждый раз. Единственное, что тут может мешать — желание наживаться, а не развиваться, но это уже их личное дело и не аргумент в этом вопросе.
nidalee
19.01.2018 02:58Я что-то сомневаюсь, что любой производитель микрокодов будет раздавать их направо и налево.
По статье: можно сделать вывод, что секретность «поломал» инженер AMD? Типа «мы не знаем почему ездят танки, но в наш город революция обойдет стороной!»Farxial2
19.01.2018 13:18Но проблемные процы можно толкать направо и налево, да.
Я так понял, секретность поломала открытость Linux.nidalee
19.01.2018 13:42Нет, Linux не виноват. Узнали, что что-то с процессорами, но не поняли что, пока инженер AMD не отличился.
Farxial2
19.01.2018 14:58Но поняли бы позже. Нормальные исследователи… А уж хулиганы, для которых ущерб простым людям является неотъемлимой частью стиля жизни, поняли бы намного быстрее. А патчей нет до сих пор.
Karpion
19.01.2018 04:23+11) Я очень надеюсь, что потребители процессоров и прочих электронных чипов — наконец-то сообразят, что нельзя доверять крупным корпорациям. Операционные системы с открытым кодом уже есть — теперь пора думать о процессорах с открытой архитектурой (полностью открытой — на всех уровнях, включая чертежи, где расписано расположение транзисторов на кристалле).
2) Производителям компьютеров давно пора думать над альтернативной архитектурой. Например, об архитектуре, где есть много процессоров с раздельной памятью. Понятно, что такая архитектура не ликвидирует описанные в статье проблемы полностью — но возможный ущерб хотя бы будет ограничен памятью того процессора, на котором работает зловредный код. Тогда особо секретные приложения смогут потребовать себе физическую изоляцию на отдельном процессоре в отдельной памяти.
3) Мне достаточно очевидно то, что значительная часть проблемы вызвана разделением производителей аппаратуры и операционки. Если бы аппаратуру (в т.ч. процессор собственной архитектуры) и операционку производила одна корпорация — то неразберихи было бы на порядок меньше.
dernuss
19.01.2018 05:561) И что вы предлагаете? Что использовать потребителям? Сейчас и через 5 лет?
3) Третий пункт очень спорен. Возможно если бы так было, то были бы времена DOS до сих пор. И была бы одна операционка на один процессор (семейство).vis_inet
19.01.2018 08:243) Третий пункт очень спорен
Да, был бы ещё больший монополизм, чем сейчас.
creker
19.01.2018 11:331. Каким образом это поможет? Архитектура современных процессоров давно известна и, в принципе, понятна людям. Там нет никаких секретов уж прямо. Уж про спекулятивное исполнение и работу кэшей знают даже окологеймерские сайты, а всякие игровые разработчики так вообще на каждой конференции об этом рассказывают, т.к. для них очень важно понимать эти вещи. Опенсорс не решает проблем безопасности.
2. А можно сделать проще и реализовать изоляцию на уровне серверов, стоек и т.д., как это и делается собственно. У AMD есть SEV примерно для этих целей. Выдумывать что-то дальше видится как трата ресурсов на слишком нишевые фичи.
3. Неразберихи — конечно. В остальном, никаких преимуществ для индустрии в целом от этого не было бы. Вон Apple чето никак не выиграла от того факта, что iOS устройства она делает сама от и до.
nidalee
19.01.2018 13:07об архитектуре, где есть много процессоров с раздельной памятью.
У людей несколько чипов в одном сокете по latency проседают так, что мама не горюй, а если эти чипы еще и в разных местах на плате будут… Это прямо «верните мой 2007» получится.Karpion
21.01.2018 02:36Очевидно — это потому, что люди не умеют организовывать многозадачность. Например, драйверы файловой системы и жёсткого диска переходят с процессора на процессор — туда, откуда их вызывает прикладная программа; и когда разные экземпляры этих драйверов параллельно выполняются на нескольких процессорах — приходится синхронизировать их работу. А надо — организовать это дело по архитектуре типа файлового сервера и его клиентов.
И вообще, сейчас всё больше компьютеров работают в качестве аппаратного носителя множества вирт.машин. Эти вирт.машины — автономные, в синхронизации не нуждаются (а если синхронизируются — то по вирт.сети). Почему Вы против разнесения их на разные чипы — я не понимаю.
Ну и не забываем, что многие задачи не нуждаются в FPU. Запускать их на процессоре с FPU — это безумное расточительство.
sumanai
21.01.2018 16:06Очевидно — это потому, что люди не умеют организовывать многозадачность
Но вы конечно лучше знаете, чем разработчики популярных ОС, программ и процессоров.
А надо — организовать это дело по архитектуре типа файлового сервера и его клиентов.
Подобное есть в ОС с микроядром, но они не показывают высокой производительности- затраты на передачу сообщений между разными процессами оказываются выше, чем блокировки внутри одного.
Почему Вы против разнесения их на разные чипы — я не понимаю.
Слишком жёсткая привязка к архитектуре. Сейчас на одном сервере можно запустить как 10 относительно мощных виртуалок, так и 500 слабых. Жёсткое разделение процессоров ограничивает выбор несколькими оптимальными конфигурациями.Karpion
21.01.2018 16:53Но вы конечно лучше знаете, чем разработчики популярных ОС, программ и процессоров.
Совершенно очевидно, что:
1) Существующая система многозадачности — не идеальна. Т.е. — можно лучше.
2) Разработчикам важно, чтобы работало надёжно. Поэтому разработчики выбирают известные опробованные решения.
3) Разработчики не готовы делать рефакторинг, пока для этого нет серьёзных оснований. Т.е. нужно доказать, что новая система многозадачности намного лучше старой. Причём — именно доказать им.
4) Система многозадачности очень сильно завязана на многие вещи, в т.ч. на архитектуру аппаратуры и на работу других компонентов системы, вплоть до пользовательских программ (например, система многозадачности исторически недавно переделывалась под многотредовость программ). (См.ниже.)
Поэтому я реально могу знать то, что разработчики — может, знают, может, не знают, но в любом случае пока не готовы реализовывать.
Подобное есть в ОС с микроядром, но они не показывают высокой производительности- затраты на передачу сообщений между разными процессами оказываются выше, чем блокировки внутри одного.
Выше в 4-м пункте я сказал о связи многозадачности с архитектурой аппаратуры. Разумеется, попытка разделения ядра на микроядра — будет неэффективна, если аппаратура заточена на монолитное ядро.
Или для Вас является новостью тот факт, что аппаратуру (в т.ч. процессор) делают под некую ожидаемую модель программ?
Микроядро — это вообще не на тему производительности. Это на тему надёжности и безопасности — а эти две вещи всегда работают против производительности.
А я агитирую не за микроядро. И т.б. не за микроядро на традиционной (на данный момент) аппаратуре.
Я агитирую за дальнейшее развитие и углубление традиций AsMP. Если на HDD есть свой процессор, выполняющий весьма сложную работу — то надо развить эту идею дальше и поручить этому процессору (или не этому, а другому) и обслуживание файловой системы.
Я надеюсь, Вы не возражаете против того, что на брюхе у HDD живёт двухядерный процессор?
Сейчас на одном сервере можно запустить как 10 относительно мощных виртуалок, так и 500 слабых. Жёсткое разделение процессоров ограничивает выбор несколькими оптимальными конфигурациями.
Если я сделаю в своей архитектуре десять процессоров (возможно, многоядерных; каждый процессор с собственной памятью) (и ещё пару специализрованных — один для сети, второй для файловой системы) — то смогу запустить и десять относительно мощных виртуалок, и полтысячи слабых.sumanai
21.01.2018 19:121) Всегда можно сделать лучше. Вопрос в том, выгодно ли это.
2) Надёжность важна не только разработчикам, но и потребителям.
4) Про переделку про многотредовость не понял.
Или для Вас является новостью тот факт, что аппаратуру (в т.ч. процессор) делают под некую ожидаемую модель программ?
Конечно нет, поэтому я и написал про «разработчики популярных ОС, программ и процессоров».
Если я сделаю в своей архитектуре десять процессоров (возможно, многоядерных; каждый процессор с собственной памятью) (и ещё пару специализрованных — один для сети, второй для файловой системы) — то смогу запустить и десять относительно мощных виртуалок,
А вот при 11 две из них будут ютится на одном кластере и дико тормозить, хотя со стороны остальных может быть запас. Даже при размещении на одной подложке возникает множество проблем, и например AMD из-за этого завозит режим отключения одного блока. Поэтому при первой возможности все стремятся к одному кристаллу и однородному доступу к памяти.Karpion
22.01.2018 04:30Всегда можно сделать лучше. Вопрос в том, выгодно ли это.
Если рассматривать понятие «выгодно» в капиталистическом смысле — то эволюция запросто может привести человечество к экологической или какой-то другой катастрофе. У меня чёткое ощущение, что катастрофа в IT уже наступила — просто мы её не заметили. Впрочем, в космической отрасли похоже, аналогичная катастрофа.
Надёжность важна не только разработчикам, но и потребителям.
Решения принимают разработчики. Но при этом они ориентируются на потребителей.
Поэтому (повторю) разработчики очень часто предпочитают проверенные временем решения — даже если есть серьёзные основания полагать, что новые решения лучше и по производительности, и по надёжности.
Про переделку про многотредовость не понял.
Идея многопоточных программ стала популярной сравнительно недавно, на моей памяти. Сначала многопоточность была реализована в виде библиотеки, работавшей на уровне процесса; она не могла распараллелить потоки одного процесса по разным процессорам/ядрам и не давала работать всему процессу, если один из тредов делал блокирующий вызов в ядро. Потом многопоточность реализовали на уровне ядра — вот это и была переделка.
Конечно нет, поэтому я и написал про «разработчики популярных ОС, программ и процессоров».
Беда современного IT — в том, что аппаратуру, операционку и приложения разрабатывают разные конторы. Обратите внимание: в автопроме автомобильный концерн разрабатывает автомобиль целиком (либо заказывает на аутсорсе — но по своему ТЗ).
К сожалению, в IT мало кто разрабатывает собственную экосистему. А те, кто разрабатывают — те сидят в узкой нише и даже не пытаются сделать свою платформу широко-функциональной.
Например, у меня есть один товарищ, имеющий Sony PlayStation; от него у меня вся информация по ней. Судя по его словам, Sony поступила феерически глупо (оценка — моя, от него только факты): PlayStation невозможно использовать ни для чего, кроме игр. По идее, эта железка по аппаратной мощности запросто м.б. и WWW-браузером, и текстовым редактором, и офисным пакетом (Word+Excel+etc), и даже редактировать картинки/звук/видео. Но Sony принципиально не развивает свою приставку в эту сторону.
А вот при 11 две из них будут ютится на одном кластере и дико тормозить, хотя со стороны остальных может быть запас.
А давайте не менять условия задачи на ходу. Любая IT-система строится под определённый круг задач и не обязана хорошо работать при выходе за этот круг.
AMD из-за этого завозит режим отключения одного блока
Я так понимаю, Вы не заметили слово «NUMA», хотя оно там многократно повторяется.
И опять же, я повторю: Я считаю большой ошибкой использование многоядерных чипов. Хорошо хоть на CPU не возлагают управление жёстким диском (перемещение сбойных секторов, etc), а держат для этого отдельный процессор на брюхе жёсткого диска.
Поэтому при первой возможности все стремятся к одному кристаллу и однородному доступу к памяти.
Странно то, что некоторые люди предпочитают ставить отдельную видеокарту с GPU в отдельном чипе и с собственной памятью.sumanai
22.01.2018 16:26+1Сначала многопоточность была реализована в виде библиотеки, работавшей на уровне процесса… Потом многопоточность реализовали на уровне ядра — вот это и была переделка.
Всё равно не понял. Какая библиотека, какое ядро? Вы про какие годы вообще?
К сожалению, в IT мало кто разрабатывает собственную экосистему. А те, кто разрабатывают — те сидят в узкой нише и даже не пытаются сделать свою платформу широко-функциональной.
Так может это связанные проблемы? Ну не может одна компания сделать всё на свете.
А давайте не менять условия задачи на ходу.
Вы это бизнесу скажите. Или типа запустили сайт на 100к клиентов, и всех лишних отстреливать на балансере?
Я так понимаю, Вы не заметили слово «NUMA», хотя оно там многократно повторяется.
Я его прекрасно заметил, и на него намекаю. Любая архитектура с множеством процессоров будет страдать такой фигнёй как неравномерный доступ к памяти и к данным другого процессора.
Странно то, что некоторые люди предпочитают ставить отдельную видеокарту с GPU в отдельном чипе и с собственной памятью.
Просто никому ещё не удалось объединить мощный ЦПУ и ГПУ на одном кристалле с раздельной памятью для каждого. Как только это станет возможно, их тут же сольют, и получат прирост скорости.
Нет, вы не подумайте- я не против использования специализированных чипов для некоторого ограниченного круга задач, таких как сетевой контролёр. Но я против раскидывания приложений по разным ЦП.Karpion
22.01.2018 19:04Всё равно не понял. Какая библиотека, какое ядро? Вы про какие годы вообще?
Я об многопоточности и потоках выполнения. Год найти не удалось — но это примерно 199*-е.
Так может это связанные проблемы? Ну не может одна компания сделать всё на свете.
Ну, почитайте про спектр занятий японских и южнокорейских фирм — Вас ждёт много удивительных открытий на тему того, как фирма может выпускать смартфоны и военные миномёты.
Вы это бизнесу скажите {«не менять условия задачи на ходу»}.
Ой, а разве в бизнесе не принято составлять ТЗ до начала работы?
Или типа запустили сайт на 100к клиентов, и всех лишних отстреливать на балансере?
По мере запуска новых клиентов — в стойку добавляются новые мощности. Или Вы знаете бизнес, который работает как-то иначе?
Любая архитектура с множеством процессоров будет страдать такой фигнёй как неравномерный доступ к памяти и к данным другого процессора.
Пожалуйста, не надо соскакивать с темы. Мы обсуждает вирт.машины. Зачем вирт.машине доступ к данным другой вирт.машины? Для воровства данных? А вот нефиг!
Просто никому ещё не удалось объединить мощный ЦПУ и ГПУ на одном кристалле с раздельной памятью для каждого.
Ну так и не удастся! Это стало понятно ещё в тот момент, когда память перестала успевать кормить процессор кодом и данными — так что пришлось ставить кэш-память.
А сейчас — надо перенести выполнение X-сервера на видеокарту.
И ещё надо аналогично отделить сетевую подсистему и файловую систему.
Но я против раскидывания приложений по разным ЦП.
Наверно, Вы ещё и сторонник терминальной схемы — когда все приложения выполняются на одном центральном компьютере, а у юзеров только тонкие терминалы?
sumanai
19.01.2018 17:35чертежи, где расписано расположение транзисторов на кристалле
Самая бесполезная вещь в мире. В существующих процессорах куча автогенерируемых частей, и схема расположения даст не больше, чем скомпилированный бинарный код.
Схема процессора ничего не даст, если не рассматривать самостоятельно маски, по которым делают процессоры.
Хотя мне стало интересно, сколько будет весить такая схема, скажем, для ГПУ с миллиардом транзисторов?
Если бы аппаратуру (в т.ч. процессор собственной архитектуры) и операционку производила одна корпорация — то неразберихи было бы на порядок меньше.
У Apple с последними айфонами почти так. Только не пойму, про какую неразбериху вы пишите? Уязвимость процессора есть уязвимость, и она будет как в отдельной компании, так и в отдельном подразделении одной корпорации.a5b
19.01.2018 18:34маски, по которым делают процессоры. Хотя мне стало интересно, сколько будет весить такая схема, скажем, для ГПУ с миллиардом транзисторов?
Те маски, по которым изготавливают чипы (после OPC-коррекции) — сотни ГБ на 28 нм (2013). До OPC — видимо в разы меньше.
https://semiengineering.com/can-mask-data-prep-tools-manage-data-glut/ "At 28nm, design post-OPC data files sizes reach hundreds of gigabytes. With 20nm and below technology demonstrating that complexity due to correction techniques is increasing, engineering teams are facing terabyte-size data files."
С многопроходными засвечиваниями (https://en.wikipedia.org/wiki/Multiple_patterning) каждого слоя — еще хуже "“The complexity of mask making increases with the need to use multiple masks to image a single construction layer (Metal 1).”"
http://adsabs.harvard.edu/abs/2011SPIE.7969E..25C (2011 год, EUV прогнозы — 3 ТБ в сумме) — "OASIS file sizes after OPC of 250GigaBytes (GB) and files sizes after mask data prep of greater than three TeraBytes (TB) are expected to be common."
2017 год — в опросе изготовителей масок упоминали о 16 терабайтной маске (для одного из слоёв, их десятки)
https://www.spiedigitallibrary.org/conference-proceedings-of-spie/10454/104540A/eBeam-initiative-survey-reports-confidence-in-EUV-and-multi-beam/10.1117/12.2279410.short?SSO=1 (http://www.ebeam.org/docs/ebeam_bacus_roundup_2016.pdf "Select Highlights from Mask Makers Survey (data from Q3 2015 through Q2 2016)") "According to the mask makers' survey, the largest data volume reported for any mask level was 16 Terabytes—about 20X higher compared to what was reported in last year's survey. "
https://www.spiedigitallibrary.org/ContentImages/Proceedings/10454/104540A/FigureImages/00553_psisdg10454_104540a_page_4_1.jpg "Largest Mask Data Volume For Any Layer (Q3 2015 — Q2 2016 n=10)." 2016 — 0.245TB — 16 TB
beeruser
19.01.2018 22:45>> для ГПУ с миллиардом транзисторов?
У Nvidia GV100 — 21 миллиард транзисторов (815mm?)
Karpion
20.01.2018 18:461) Ну, я тут говорил про то, что открытыми д.б. все уровни — от верхних до нижних. Т.е. нужно открыть и задание для автогенератора(это как бы программа на языке верхнего уровня), и сгенерированную по этому заданию схему (как бы бинарный код), и маску тоже.
Сколько оно весит — я не знаю. Но на каких-то накопителях оно размещается.
3) Неразбериха — та, что описана в последнем абзаце статьи. Там явно указывают на проблему согласований между разными группами лиц, не имеющими общего начальника.
Apple использует процессоры i*86 от Intel в настольльных компьютерах и ноутбуках; и процессоры ARM в айфонах — такие же, как используются в Android-устройствах. Естественно, эти продукты затронуты общей проблемой.
Я как бы намекаю, что чем больше разнообразие продуктов — тем меньше ущерб от эпидемий (это и в сельском хозяйстве так, и в компьютерных экосистемах).
danfe
19.01.2018 10:53Меня в этой истории отдельно неприятно удивило то, как Intel и Google грубо и недальновидно работали с вендорами открытого софта и коммьюнити.
Популярные дистрибутивы Linux почему-то получили disclosures еще в ноябре, а *BSD и многие другие ничего не знали до последнего момента (Тео, как всегда, не стесняется в выражениях по этому поводу). Чуваки даже не подумали (или им было пофиг), что крупные коммиты в VM-подсистему ядра без внятного объяснения неизбежно вызовут у публики вопросы со всеми вытекающими последствиями. Чуваку из AMD разрешили (или не уследили, по факту неважно) раструбить про спекулятивные ссылки до окончания эмбарго. Вот эти все организационные фейлы едва ли не затмевают собственно главный фейл (проблемы в процессорах).
larrabee
19.01.2018 16:18Видел информацию о том, что разработчики FreeBSD получили инфу вовремя, а с Тео произошла забавная история. Когда нашли баг в WPA2 ему сообщили о уязвимости наряду со всеми, но он раскрыл инфу о ней широкой общественности до оговоренной даты релиза. После этого случая ему сказали, что будут сообщать ему о таких уязвимостях в последний момент. Снятие эмбарго на мелтдаун планировалось на 9 января и вероятно ему бы сообщили детали уязвимости 6-7 января, но инфу разболтали раньше времени.
danfe
19.01.2018 16:41С FreeBSD Intel поделилась информацией (под NDA) только в конце декабря, это отнюдь не вовремя. OpenBSD действительно нарушали эмбарго в прошлом, ну дык я за них особо и не топлю.
SirEdvin
20.01.2018 15:02Не важно, было им пофиг или нет, но что вы предлагаете делать? У большинства дистрибутивов открытые исходники ядра, других вариантов не было.
danfe
22.01.2018 16:31+1Коммиты можно было скоординировать по времени, можно было заранее согласовать (не)включение KPTI (mitigation для Meltdown) с ребятами из AMD. Можно было договориться, кому и что можно, а что нельзя говорить в паблике. При желании всё можно было сделать быстро и прозрачно (запатчить ядра Linux/*BSD, выпустить официальное заявление), но было сделано как было сделано. :-(
Murlakatam
19.01.2018 15:10+1Ситуация описывает почему невозможно достаточно долго реализовывать любую теорию заговора.
olekl
19.01.2018 15:11Так, исключительно с целью пофантазировать — представьте себе хаос, если когда-нибудь окажется, что факторизацию или логарифм по модулю можно за полиномиальное время решить…
Farxial2
19.01.2018 15:45Поэтому я уже несколько раз предлагал использовать наборы ассиметричных ключей разных алгоритмов (когда действительно только совместное использование нескольких ключей разных алгоритмов), но меня не слушали,
блин!
Jecky
19.01.2018 18:21-1Ещё один патч от Microsoft был скомпилирован и выпущен в канун Нового года, что говорит, что команда компании, вероятно, работала над ним всю ночь
Так вот почему у меня 31-го вечером стала падать винда с BSOD по памяти. Кстати, вылечилось только заменой на новую планку.
Leljka
20.01.2018 15:00Но Шварц столкнулся с ещё одной проблемой: как сохранять в секрете такую серьёзную уязвимость достаточно долго, чтобы её можно было исправить?.
Ну а почему бы и нет? Прежде всего — компании такого масштаба беспокоит репутация, оборот, продажи! Помимо этого, чипами данной компании пользуется огромное кол-во потребителей (и даже я))) и если среднестатический потребитель просто откажется от использования, то крупные компании потребуют неустойку!
«Из того, что описал программист Том Лендаки из AMD, следует, что ЦП от Intel грешат спекулятивным выполнением кода без проверок на безопасность»
Отсутствие изоляции ядра. Читала.
А сайты — следствие и, возможно, маркетинговый ход, чтоб как можно большее кол-во клиентов воспользовались патчем!
Ух!.. На втором ПК у меня чип AMD! Как же хорошо, что мы не устанавливали последние обновления! Кстати, впервые до оповещения в СМИ данную информацию я нашла здесь. Вот, чем ценен ресурс! И именно благодаря ему не устанавливали обновления.
Azipolos
20.01.2018 15:00Еще раз, для тех, кто очень далек от всех этих тонкостей и нюансов. С AMD все ОК? Или нет?
haryaalcar
21.01.2018 11:22
NickViz
20.01.2018 15:02я вот что не понимаю — если об уязвимости стало известно аж в середине 2017 — то почему патчи пришлось «срочно писать» в декабре?? что они пол-года то делали? запихивали червяков обратно в банку и надеялись что само пройдёт?
Igggi
20.01.2018 15:04Поясните. Процессор Байкал подвержен данным рискам?
a5b
20.01.2018 23:32https://habrahabr.ru/post/346114/#comment_10601572 YuriPanchul (Старший инженер по разработке аппаратуры в команде разработки микропроцессорного ядра MIPS I6400 в отделении Imagination Technology в Санта-Клара, Калифорния (ранее MIPS Technologies, Саннивейл, Калифорния).) 05.01.18 —
У российского микропроцессора Байкал-Т на основе ядра MIPS P5600 уязвимости Meltdown нет, и если использовать режим EVA, то нет и Spectre.
https://habrahabr.ru/post/346114/#comment_10604162
В Байкале-Т есть и супескалярность, и предсказание переходов, и спекулятивное выполнение, и TLB MMU, и кэши. Meltdown нет за счет дополнительной проверки.
Chelyuk
20.01.2018 15:04Это все классно, но я так и не понимаю чего хотят вендоры дальше. Кржанич, явно стреманулся и слил свои акции Microsoft, Intel зная об уязвимости решила выпустить поколение процессоров в которых по прежнему сохранена уязвимость, без компании с отзывом. Т.е. алчность победила, здравый смысл, я правда так не понимаю кто будет покупать их новые процессоры, но наверное от безысходности будут.
Я полагал, что все таки замена CPU должна стать основным решением а все эти заплатки должны только выиграть время для реализации главного плана. Но судя по действиям основных виновников не видно никаких намеков на решение основной проблемы — на что менять текущие CPU?sumanai
20.01.2018 15:07без компании с отзывом
А это вообще возможно без банкротства Intel?Chelyuk
20.01.2018 17:41Думаю возможно. Samsung в Британии работает по схеме — платишь таксу ежемесячно и получаешь новый топовый продукт сразу после выхода, в обмен на старый. Т.е. от схемы с разовой оплатой по сути перешли на подписку. Интел тоже мог так сделать, мол вот вам устройства но мы знаем о проблеме поэтому в следующем поколении исправим и продадим в обмен на старые за пол или треть цены. Лояльность потребителей дороже стоит.
sumanai
20.01.2018 19:21платишь таксу ежемесячно и получаешь новый топовый продукт сразу после выхода
Что-то мне кажется, что это выйдет не меньше, чем полная стоимость, с учётом переработки старого.
KOLANICH
20.01.2018 22:34+1Это в очередной раз доказывает, что единственная нормальная стратегия добронамеренного ресерчера — это full disclosure. Учитывая то, что ЦРУ и АНБ следят за крупнейшими специалистами, в том числе взламывая их компьютеры или компрометируя цепочку поставок, и устанавливая руткиты, в том числе аппаратные, учитывая то, многие исследователи не считают работу на спецслужбы чем-то плохим
Daniel Genkin was supported by… and the Defense Advanced Research Project Agency (DARPA) under Contract #FA8650-16-C-7622
, учитывая то, что уязвимость meltdown гениально проста, и поэтому задолго до этого могла быть известна спецслужбам с подачи исследователей, на них работающих (я вообще не понимаю, откуда security фирмы берут деньги, кроме как работая на спецслужбы, ведь все способы прямо заработать на уязвимостях: это продать киберпреступникам, легальным (спецслужбы) или нелегальным (нелегально), продать вендору (баг баунти, но даже оно оч. рисковано, можно схлопотать иск (в худшем случае ещё и вымогательство привесят) и проиграть дело — в лицензии многих проприетарных продуктов явно написано, что реверс-инжиниринг запрещён и что вообще разрешено использование только в таких-то целях, что необходимая информация зачастую собирается с нарушением законов о копирайте, например поиск и использование утекших (в нарушение NDA) datasheetов на чипы с отметками copyright, confidential, unauthorized distribution prohibited и тому подобное) и игра на курсе акций (из-за законов об инсайде нелегально), а нелегальными вещами легальная фирма заниматься не может. Те есть, насколько я понимаю, единственный легальный способ у security фирм заработать денег на уязвимостях — это продать их спецслужбам), то единственно верным выходом тут было бы full immediate disclosure. И плевать сколько людей пострадало бы из-за действий детишек, а удар по репутации производителей уязвимых чипов от этого был бы вполне заслужен, всё-таки не исследователи создали эту уязвимость (бекдор?), главное чтобы фикс был как можно скорее, а производители наконец стали прилагать все необходимые усилия, чтобы такого не повторилось.
GerrAlt
SammyTheCat
В оригинале там ARM (ARM chips are also affected).
StjarnornasFred
Перепутать AMD и ARM — это нечто уровня интернет-магазина с китайфонами. Мне известны как минимум 2 таковых.
По существу: если эта уязвимость так трудна в обнаружении, то очевидно, что и в эксплуатации она также очень трудна. Следовательно, вероятность того, что какой-нибудь хакер сможет к ней присосаться, причём не абы как, а результативно — крайне низка. Я бы даже сказал так: эксплуатация Meltdown и Spectre практически невозможна.
alan008
Ну вам конечно виднее
BaLaMuTt
А вот тут вы не правы ибо при наличии готового эксплойта использующего эту уязвимость применять её в своих тёмных делишках сможет любой малолетний прыщавый скрипткидди.
creker
Правда вот реалистичность такого сценария сомнительна. Все примеры демонстрируют идеальные условия — взяли готовый адрес из подопытного примитивного приложения и читаем, что нам нужно. Для начала, этот адрес надо найти и сделать это в рантайме, что далеко не так уж тривиально. И работает это все слишком медленно, чтобы парсить гигабайты памяти в поиске заветной строчки. Таки это совершенно другой сложности уязвимость, нежели когда у тебя на руках RCE, где только и остается что собрать код для выполнения.