Как ошибку Spectre, способную сломать индустрию, держали в тайне семь месяцев

https://www.theverge.com/2018/1/11/16878670/meltdown-spectre-disclosure-embargo-google-microsoft-linux
  • Перевод


Когда исследователь Майкл Шварц из Грацского технического университета впервые связался с компанией 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-х у нас был девиз — одна уязвимость, один производитель, и таких уязвимостей было большинство. А теперь практически где угодно присутствует элемент координации нескольких заинтересованных сторон, — говорит Муссурис. — Вот так и выглядит реальное освещение проблем, связанных с работой нескольких заинтересованных сторон».
Поделиться публикацией
Комментарии 96
    +3
    характерен ли Meltdown только для Intel (чипы от AMD тоже пострадали)
    а нет ли тут какого-то уточнения, что значит «пострадали»? Кто-то смог воспроизвести Meltdown на процессорах AMD?
      +5
      В оригинале там ARM (ARM chips are also affected).
        –5
        Перепутать AMD и ARM — это нечто уровня интернет-магазина с китайфонами. Мне известны как минимум 2 таковых.

        По существу: если эта уязвимость так трудна в обнаружении, то очевидно, что и в эксплуатации она также очень трудна. Следовательно, вероятность того, что какой-нибудь хакер сможет к ней присосаться, причём не абы как, а результативно — крайне низка. Я бы даже сказал так: эксплуатация Meltdown и Spectre практически невозможна.
          0
          Я бы даже сказал так: эксплуатация Meltdown и Spectre практически невозможна.

          Ну вам конечно виднее

            0
            А вот тут вы не правы ибо при наличии готового эксплойта использующего эту уязвимость применять её в своих тёмных делишках сможет любой малолетний прыщавый скрипткидди.
              +1
              Правда вот реалистичность такого сценария сомнительна. Все примеры демонстрируют идеальные условия — взяли готовый адрес из подопытного примитивного приложения и читаем, что нам нужно. Для начала, этот адрес надо найти и сделать это в рантайме, что далеко не так уж тривиально. И работает это все слишком медленно, чтобы парсить гигабайты памяти в поиске заветной строчки. Таки это совершенно другой сложности уязвимость, нежели когда у тебя на руках RCE, где только и остается что собрать код для выполнения.
        +3
        Она поразила практически все крупные технокомпании мира, от серверных ферм Amazon до производителей чипов вроде Intel и ARM.

        Корректно ли это высказывание? ARM — архитектура процессоров, ARM ltd., впрочем, чипы тоже не производит.
          0
          ИМХО, уязвимость затронула чипы на архитектуре ARM, соответственно это предложение можно считать верным. Может быть не все, но всё-таки.
            0
            Так проблема как раз с архитектурой. Так что любой производитель чипов с ядром от АРМ соответсвующей архитектуры будет подвержен уязвимости. Правда не все типы АРМ имеют такие проблемы. Список проблемных — developer.arm.com/support/security-update
          • НЛО прилетело и опубликовало эту надпись здесь
              +3

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

              –14
              Так вот как ФСБ получила доступ к секретным данным против предвыборной кампании Хилари.
              • НЛО прилетело и опубликовало эту надпись здесь
                  +7
                  Боролась не только Интел, но ещё и команда ядра Линукса, Гугл, Амазон, Майкрософт, Амд и прочие. А разглашать информацию до этого означало проинформировать хакеров о проблеме до того, как у кого-нибудь будет решение.
                  Собственно, поэтому некоторые патчи были применены до того, как о проблеме стало известно широкой публике. И в статье об этом говорится.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      +1

                      Почему Intel должен это делать? Не должна ли Apple опубликовать полную спецификацию iPhone X, чтобы любой мог дополнить его нужными фичами?

                      • НЛО прилетело и опубликовало эту надпись здесь
                          +1

                          Я думаю, что нет, не должна.

                          • НЛО прилетело и опубликовало эту надпись здесь
                              +2

                              Вы сейчас предлагаете компаниям заниматься иррациональными вещами. Польза для общества — не самоцель для компаний. Заработать денег — вот смысл существования любого бизнеса.

                              • НЛО прилетело и опубликовало эту надпись здесь
                                  +1
                                  Вы, случайно, не с Альфы-Центавра сюда прилетели?
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    +1
                                    Ваше мнение мало значит, пока вы не поруководили многотысячными коллективами и не поуправляли трилионными ресурсами. Это примерно как пара уборщиц, обсуждающих «нахапавшего» гендиректора корпорации.
                                    Не хочу сказать, что на верхнем уровне управления работают ангелы с нимбиками, но уверен, что скилл товарищей весьма высок, а количество входящих условий известных им, критично больше, чем известно вам. Это не гарантирует безошибочности действий корпораций или правительств, но практически гарантирует ошибочность ваших выводов.
                                    Кроме того, управляющие решения, затрагивающие миллионы людей не могут быть всемилостливыми от слова «никогда». Поэтому открытость информации на верхних уровнях управления, как я понимаю, разрушительна по определению. Пока вы будете кормить семью хлебами голодных, обязательно найдутся: 1) недовольные продавцы зерновых; 2) мошеники, предлагающие накормить шестью хлебами; 3) еб… тые, которые будут утверждать, что выпив два литра водки и закусив вашим хлебом они отравились; 4) невыбранный депутат от мафии, который будет утверждать, что источник получения ваших семи хлебов дурно пахнет; 5) журналист, который для тиража напишет статью о том, что ваши хлеба генномодифицированы, иначе как можно так накормить; 6) террорист, который во имя Великой цели будет искать способ ваши хлеба отравить или хотя бы заплесневеть…
                                    И еще будет желтая печать и форумы называющие вас… составьте сами список ушат дерьма плиз…
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        +1
                                        Нет, не «сперва добейся». Я говорю о том, что обсуждать действия на таком уровне управления, не находясь там и не владея всей информацией — пустое. Вы никогда не поймете в каком русле их скилл (я писал: «Это не гарантирует безошибочности действий корпораций или правительств»), не потому что вы тупы, а потому что вам никто не даст полной информации. Будь вы семи пядей во лбу, вы будете опираться на сообщения в массмедиа, а не на реальную информацию и сделаете неверные или неполные выводы.
                                        Простая вводная — допустим в какой-то момент представители Интел и подобных совещались с Пентагоном, ЦРУ и ФРС по поводу проблемы. И были приняты решения, связанные в первую очередь с соображениями госбезопасности западных стран, а не с недовольством сообщества или миллионами в кармане. И никто вам об этом сообщать не будет (а если попробует — под машину попадет например). И со стороны решения будут озвучиваться частично и выглядеть не совсем понятно.
                                        Никто вас не допустит к реальным мотивам.
                                        Кстати, мотивы создания экономической системы, которая вам отвратительна, я уверен — были далеки от отвратительности. Ну, возможно по-хорошему циничны.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            –1
                                            «Так что я имею на это право. А то, что никто не даст мне полной информации, не моя вина.» — вот поэтому существуют силовые структуры. Если начнете мешать системе, вас подавят.
                                            Справедлива ли система?
                                            Давайте я приведу несколько попсовых заголовков и прочего. А уж как их интерпретировать…
                                            1) «История человечества, как история самоуничтожения: 3,5 млрд. человек погибло в войнах» (вроде как за 5,5 тыс. лет)
                                            2) book.ivran.ru/f/rastyannikovderyuginaurozhajnosthlebovvrossii.pdf — табличка с 16 стр.
                                            3) «10 ведущих причин смерти в мире» — приведены графики за пару лет, думаю сто лет назад причины были другие, но цифры значительно выше. www.who.int/mediacentre/factsheets/fs310/ru Даже если принять 55 млн. в год «тех, кого не вылечили» по вашим меркам, это 5,5 млрд. за век… Думаю реально «невылеченных» было поболе.
                                            4) «Демографический апокалипсис. К 2050 году планета погибнет от перенаселения?»
                                            Вот какая-то хитрая штука, эта справедливость и равноправие. Если почитать каждый пункт в отдельности, то можно как-то запутаться. То ли бездушно уничтожают человечество в своих корыстных войнах; то ли заботятся о пропитании растущего населения, все поднимая и поднимая агрокультуру; то ли ни хера не заботятся о медицине — люди мрут! как мухи в руках эскулапов!!; то ли перестарались с человеколюбием и народа расплодили — не прокормишь…
                                            Борьба за ресурсы, на самом деле, как и миллион лет до нашей эры — дело частное. Станьте миллионером-губернатором-знаменитостью и включитесь в эту борьбу! Ну… либо обсуждайте.
                      +3
                      Я что-то сомневаюсь, что любой производитель микрокодов будет раздавать их направо и налево.

                      По статье: можно сделать вывод, что секретность «поломал» инженер AMD? Типа «мы не знаем почему ездят танки, но в наш город революция обойдет стороной!»
                        0
                        Насколько я понял из статьи вроде из-за Торвальдса начался кипиш когда патч в не совсем обычное время приняли да еще и на гит выложили.
                          0
                          Кипиш начался, но не было понятно, куда копать. Пока разобрались бы, все уже было бы запатчено. А так…
                        • НЛО прилетело и опубликовало эту надпись здесь
                            +1
                            Нет, Linux не виноват. Узнали, что что-то с процессорами, но не поняли что, пока инженер AMD не отличился.
                            • НЛО прилетело и опубликовало эту надпись здесь
                        –7

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


                        2) Производителям компьютеров давно пора думать над альтернативной архитектурой. Например, об архитектуре, где есть много процессоров с раздельной памятью. Понятно, что такая архитектура не ликвидирует описанные в статье проблемы полностью — но возможный ущерб хотя бы будет ограничен памятью того процессора, на котором работает зловредный код. Тогда особо секретные приложения смогут потребовать себе физическую изоляцию на отдельном процессоре в отдельной памяти.


                        3) Мне достаточно очевидно то, что значительная часть проблемы вызвана разделением производителей аппаратуры и операционки. Если бы аппаратуру (в т.ч. процессор собственной архитектуры) и операционку производила одна корпорация — то неразберихи было бы на порядок меньше.

                          +2
                          1) И что вы предлагаете? Что использовать потребителям? Сейчас и через 5 лет?
                          3) Третий пункт очень спорен. Возможно если бы так было, то были бы времена DOS до сих пор. И была бы одна операционка на один процессор (семейство).
                            +1
                            3) Третий пункт очень спорен
                            Да, был бы ещё больший монополизм, чем сейчас.
                              0
                              представьте только: слияние интел и эпл :-)
                                0
                                Всё это было уже, в конкурентной борьбе выжили только INTEL и AMD.
                                  +1
                                  Вот-вот. Для некоторых будет сюрпризом, что еще в 2000х были процессоры Cyrix, выпускаемые VIA
                            +1
                            1. Каким образом это поможет? Архитектура современных процессоров давно известна и, в принципе, понятна людям. Там нет никаких секретов уж прямо. Уж про спекулятивное исполнение и работу кэшей знают даже окологеймерские сайты, а всякие игровые разработчики так вообще на каждой конференции об этом рассказывают, т.к. для них очень важно понимать эти вещи. Опенсорс не решает проблем безопасности.
                            2. А можно сделать проще и реализовать изоляцию на уровне серверов, стоек и т.д., как это и делается собственно. У AMD есть SEV примерно для этих целей. Выдумывать что-то дальше видится как трата ресурсов на слишком нишевые фичи.
                            3. Неразберихи — конечно. В остальном, никаких преимуществ для индустрии в целом от этого не было бы. Вон Apple чето никак не выиграла от того факта, что iOS устройства она делает сама от и до.
                              +1
                              об архитектуре, где есть много процессоров с раздельной памятью.

                              У людей несколько чипов в одном сокете по latency проседают так, что мама не горюй, а если эти чипы еще и в разных местах на плате будут… Это прямо «верните мой 2007» получится.
                                0

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


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


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

                                  0
                                  Очевидно — это потому, что люди не умеют организовывать многозадачность

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

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

                                  Слишком жёсткая привязка к архитектуре. Сейчас на одном сервере можно запустить как 10 относительно мощных виртуалок, так и 500 слабых. Жёсткое разделение процессоров ограничивает выбор несколькими оптимальными конфигурациями.
                                    0
                                    Но вы конечно лучше знаете, чем разработчики популярных ОС, программ и процессоров.
                                    Совершенно очевидно, что:
                                    1) Существующая система многозадачности — не идеальна. Т.е. — можно лучше.
                                    2) Разработчикам важно, чтобы работало надёжно. Поэтому разработчики выбирают известные опробованные решения.
                                    3) Разработчики не готовы делать рефакторинг, пока для этого нет серьёзных оснований. Т.е. нужно доказать, что новая система многозадачности намного лучше старой. Причём — именно доказать им.
                                    4) Система многозадачности очень сильно завязана на многие вещи, в т.ч. на архитектуру аппаратуры и на работу других компонентов системы, вплоть до пользовательских программ (например, система многозадачности исторически недавно переделывалась под многотредовость программ). (См.ниже.)

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

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

                                    Микроядро — это вообще не на тему производительности. Это на тему надёжности и безопасности — а эти две вещи всегда работают против производительности.

                                    А я агитирую не за микроядро. И т.б. не за микроядро на традиционной (на данный момент) аппаратуре.
                                    Я агитирую за дальнейшее развитие и углубление традиций AsMP. Если на HDD есть свой процессор, выполняющий весьма сложную работу — то надо развить эту идею дальше и поручить этому процессору (или не этому, а другому) и обслуживание файловой системы.
                                    Я надеюсь, Вы не возражаете против того, что на брюхе у HDD живёт двухядерный процессор?

                                    Сейчас на одном сервере можно запустить как 10 относительно мощных виртуалок, так и 500 слабых. Жёсткое разделение процессоров ограничивает выбор несколькими оптимальными конфигурациями.
                                    Если я сделаю в своей архитектуре десять процессоров (возможно, многоядерных; каждый процессор с собственной памятью) (и ещё пару специализрованных — один для сети, второй для файловой системы) — то смогу запустить и десять относительно мощных виртуалок, и полтысячи слабых.
                                      0
                                      1) Всегда можно сделать лучше. Вопрос в том, выгодно ли это.
                                      2) Надёжность важна не только разработчикам, но и потребителям.
                                      4) Про переделку про многотредовость не понял.
                                      Или для Вас является новостью тот факт, что аппаратуру (в т.ч. процессор) делают под некую ожидаемую модель программ?

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

                                      А вот при 11 две из них будут ютится на одном кластере и дико тормозить, хотя со стороны остальных может быть запас. Даже при размещении на одной подложке возникает множество проблем, и например AMD из-за этого завозит режим отключения одного блока. Поэтому при первой возможности все стремятся к одному кристаллу и однородному доступу к памяти.
                                        0
                                        Всегда можно сделать лучше. Вопрос в том, выгодно ли это.
                                        Если рассматривать понятие «выгодно» в капиталистическом смысле — то эволюция запросто может привести человечество к экологической или какой-то другой катастрофе. У меня чёткое ощущение, что катастрофа в IT уже наступила — просто мы её не заметили. Впрочем, в космической отрасли похоже, аналогичная катастрофа.

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

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

                                        Конечно нет, поэтому я и написал про «разработчики популярных ОС, программ и процессоров».
                                        Беда современного IT — в том, что аппаратуру, операционку и приложения разрабатывают разные конторы. Обратите внимание: в автопроме автомобильный концерн разрабатывает автомобиль целиком (либо заказывает на аутсорсе — но по своему ТЗ).

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

                                        Например, у меня есть один товарищ, имеющий Sony PlayStation; от него у меня вся информация по ней. Судя по его словам, Sony поступила феерически глупо (оценка — моя, от него только факты): PlayStation невозможно использовать ни для чего, кроме игр. По идее, эта железка по аппаратной мощности запросто м.б. и WWW-браузером, и текстовым редактором, и офисным пакетом (Word+Excel+etc), и даже редактировать картинки/звук/видео. Но Sony принципиально не развивает свою приставку в эту сторону.

                                        А вот при 11 две из них будут ютится на одном кластере и дико тормозить, хотя со стороны остальных может быть запас.
                                        А давайте не менять условия задачи на ходу. Любая IT-система строится под определённый круг задач и не обязана хорошо работать при выходе за этот круг.

                                        AMD из-за этого завозит режим отключения одного блока
                                        Я так понимаю, Вы не заметили слово «NUMA», хотя оно там многократно повторяется.

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

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

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

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

                                          Вы это бизнесу скажите. Или типа запустили сайт на 100к клиентов, и всех лишних отстреливать на балансере?
                                          Я так понимаю, Вы не заметили слово «NUMA», хотя оно там многократно повторяется.

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

                                          Просто никому ещё не удалось объединить мощный ЦПУ и ГПУ на одном кристалле с раздельной памятью для каждого. Как только это станет возможно, их тут же сольют, и получат прирост скорости.

                                          Нет, вы не подумайте- я не против использования специализированных чипов для некоторого ограниченного круга задач, таких как сетевой контролёр. Но я против раскидывания приложений по разным ЦП.
                                            0
                                            Всё равно не понял. Какая библиотека, какое ядро? Вы про какие годы вообще?
                                            Я об многопоточности и потоках выполнения. Год найти не удалось — но это примерно 199*-е.

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

                                            Вы это бизнесу скажите {«не менять условия задачи на ходу»}.
                                            Ой, а разве в бизнесе не принято составлять ТЗ до начала работы?

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

                                            Любая архитектура с множеством процессоров будет страдать такой фигнёй как неравномерный доступ к памяти и к данным другого процессора.
                                            Пожалуйста, не надо соскакивать с темы. Мы обсуждает вирт.машины. Зачем вирт.машине доступ к данным другой вирт.машины? Для воровства данных? А вот нефиг!

                                            Просто никому ещё не удалось объединить мощный ЦПУ и ГПУ на одном кристалле с раздельной памятью для каждого.
                                            Ну так и не удастся! Это стало понятно ещё в тот момент, когда память перестала успевать кормить процессор кодом и данными — так что пришлось ставить кэш-память.

                                            А сейчас — надо перенести выполнение X-сервера на видеокарту.
                                            И ещё надо аналогично отделить сетевую подсистему и файловую систему.

                                            Но я против раскидывания приложений по разным ЦП.
                                            Наверно, Вы ещё и сторонник терминальной схемы — когда все приложения выполняются на одном центральном компьютере, а у юзеров только тонкие терминалы?
                                              0
                                              Я об многопоточности и потоках выполнения. Год найти не удалось — но это примерно 199*-е.

                                              Хорошо. Дальше?
                                              Ну, почитайте про спектр занятий японских и южнокорейских фирм

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

                                              А до этого?
                                              Мы обсуждает вирт.машины.

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

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

                                              Посмотрим.
                                              А сейчас — надо перенести выполнение X-сервера на видеокарту.

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

                                              Если это выгодно, то почему бы и нет. Но в общем случае это лишнее.
                                                –2
                                                Хорошо. Дальше?
                                                Ну, собственно, я доказал, что система многозадачности регулярно очень серьёзно переделывается. В качестве дополнительного примера могу привести тоже относительно недавний хайп на тему того, что в Linux запилили scheduler с трудоёмкостью обработки очереди запросов O(1); правда, я в такие вещи не верю, но факт такого хайпа помню.
                                                Ну и совершенно очевидный пример — это переписывание многозадачности при появлении сначала многопроцессорных систем, потом многоядерных.

                                                Итак, вернёмся к Вашему утверждению «Но вы конечно лучше знаете, чем разработчики популярных ОС, программ и процессоров.». Как видите, регулярно оказывалось, что «разработчики популярных ОС, программ и процессоров» создавали вовсе не идеальные решения. Так почему бы не случиться такому, что у меня родилась более продвинутая идея, чем существующие ныне?

                                                Подразделения {японских и южнокорейских фирм} связаны меньше, чем Интел с Майкрософтом.
                                                Что-то мне подсказывает: если возникнет проблема согласования, то головная контора (верховный совет директоров — представитель акционеров) достаточно быстро принудит подразделения к тесному сотрудничеству.

                                                А до этого?
                                                До чего? До добавления новых клиентов? Т.е. до появления первого клиента?

                                                А-а-а, ну тут всё просто: Создаётся инвестиционный план, в котором расписаны начальные финансы и плановое количество клиентов (с разбивкой клиентов по категориям). Под этот план пишется ТЗ. И по этому ТЗ разворачивают стартовую инфраструктуру.
                                                Затем приходят первые клиенты. Если эти клиенты годятся (т.е. их запросы можно обслужить имеющимися средствами), то эти клиенты обслуживаются этой стартовой инфраструктурой.
                                                Потом в какой-то момент выясняется, что имеющаяся инфраструктура близка к исчерпанию (например, общая загрузка превысила 90% имеющейся мощности). Тогда с некоторым упреждением мощность инфраструктуры наращивают.

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

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

                                                Meltdown чётко показал, что изоляция процессов — совершенно недостаточна. Однако, изоляция вирт.машин — явно избыточна и неуместна. Вот я и пытаюсь нащупать некое среднее решение проблемы.
                                                Мне совершенно очевидно, что персональный компьютер не способен обеспечить изоляцию процессов. Это видно даже из его названия — «персональный»: такая архитектура предполагает, что у компьютера есть только один пользователь, он же владелец компьютера. И никакие попытки дебильных разработчиков залатать врождённые дыры — не будут успешны. Архитектуру компьютера надо рефакторить.
                                                Обратите внимание: архитектуру компьютера, а не процессора. В т.ч. — архитектуру вирт.машин.

                                                Современная концепция вирт.машины — это нечто феерически дебильное. Например, хозяйская OS держить файловую систему. В этой хозяйской файловой системе создаются файлы, которые драйвер вирт.машины выдаёт гостевой OS за физический диск. И гостевая OS создаёт внутри собственную файловую систему. Двойной расход ресурсов на ведение файловой системы — ну просто обалдеть!
                                                Умная система д.б. устроена так, что гостевая OS получает не вирт.диск (который реально = файл), а директорию в хозяйской файловой системе. Для начала — можно использовать что-то вроде NFS. И главное — драйвер хозяйской файловой системы выполняется на отдельном процессоре с отдельной памятью. Ибо нефиг никому другому туда лазать.

                                                А почему существующие вирт.машины устроены так дебильно? Да потому, что все они написаны для работы на писюке. А писюк — это тупая дебильная машина, у которой в ПЗУ — BIOS с дебильно написанными функциями; и, что хуже всего, все эти функции — для реального режима процессора, т.е. для реально нужного защищённого режима они вообще бесполезны.

                                                А потом дегенераты взялись это исправлять и написали EFI. А затем — UEFI. Куда они напихали кучу DRM, но не догадались впихнуть работающую операционку.

                                                Сейчас Вы спросите, как можно упихать операционку в ПЗУ. Ну так гляньте в сторону демо-версии QNX — она умещается на дискете.

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

                                                А вот консолидация ресурсов зачем? Давайте, предложите разработчикам консолидировать всю оперативную память — системную, видеопамять, память на брюхе HDD и даже 16 байт буфера COM-порта. Или Вы уже раздумали консолидировать эту память?

                                                А зря — например, в ряде случаев было бы интересно использовать видеопамять как swap-area, особенно если видео работает в текстовом режиме на сервере, а видеокарта там отдельная. Сейчас это не очень актуально, а вот в 200*-х годах (P'II, P'III и даже P'4 с AGP) это было бы очень полезно.

                                                То, что нужно, уже давно там
                                                Да-да, я не раз слышал сентенцию: «ТО, что сделано — сделано наилучшим образом, и лучше быть е может. Потому что если бы можно было сделать лучше — то „специально обученные люди“ давно бы это сделали.».
                                                А потом через некоторое время оказывается, что сделать лучше — вполне возможно. А «специально обученные люди», оказывается, обучены исключительно тому, как демагогией удерживаться на высокооплачиваемых должностях.

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

                                                Про графику я говорить не готов. А вот для сетевой подсистемы — надо ставить процессор без FPU. для файловой системы — тоже.

                                                Если это выгодно, то почему бы и нет. Но в общем случае это лишнее.
                                                Ой, а как же Ваша любимая консолидация ресурсов? На терминальном сервере — память консолидирована, а не раскидана по отдельным компьютерам.
                                                  +2
                                                  Современная концепция вирт.машины — это нечто феерически дебильное.

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

                                                  Meltdown чётко показал, что изоляция процессов — совершенно недостаточна.

                                                  У вас явное непонимание сути уязвимости. Meltdown показал ровно одну единственную вещь и больше ничего — intel слишком вольно обходилась со своей архитектурой и нарушила гарантии, которые обязан предоставлять процессор. Никто здесь не виноват больше, ни архитектура процессоров в целом, ни тем более ПК вообще — виноват intel и его конкретная реализация. AMD реализация правильная и уязвимости этой не имеет, а значит изоляция процессов продолжает прекрасно работать и выполнять свою цель. Вас куда-то уносит с одной темы в другую, а на самом деле надо всего лишь разобраться для начала в одной.
                                                    –2
                                                    Современная концепция виртуальных машин это следствие определения этой технологии — виртуальная машина должна работать, не подозревая, что она виртуальная.
                                                    Значит, гостевой системе создают имитацию физической машины, верно? Ок, а что это за машина? Это — писюк!

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

                                                    Для начала надо вспомнить, что писюк имеет «родные» устройства и «неродные». Родные — это те, которые предполагались изначально (или если не изначально — то были аналогичными изначальным); ещё один признак — это наличие драйверов устройства в BIOS. Т.е. мы видим, что FDD/HDD и COM/LPT-порты — это родные устройства; а сеть и мышь — не родные.

                                                    Если бы сеть была родной — то вирт.машине можно было бы выделить папку, предоставив к ней сетевой доступ.

                                                    Я думаю, Вам надо ознакомиться с архитектурой компьютеров, созданных фирмой Acorn: Atom, B, B+, Master, Archimedes. Все они вообще не нуждались в локальном диске — т.к. операционка была записана в ПЗУ.

                                                    intel слишком вольно обходилась со своей архитектурой
                                                    Вы так говорите, как будто у Intel были какие-то обязательства/ограничения на тему того, что она может делать со своей архитектурой! Может, у Вас есть ссылки на нормативные документы, ограничивающие вольности корпораций — этого современного дворянства?

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

                                                    В данном случае уязвимость порождена именно разделением системы на уровни абстракции (хотя правильнее — «области абстракции»). Есть три компонента, каждый безопасен сам по себе. А втроём — они образуют дыру.
                                                      0
                                                      Если бы сеть была родной — то вирт.машине можно было бы выделить папку, предоставив к ней сетевой доступ.

                                                      Это вообще как? Так-то и сейчас можно бездисковую виртуалку создать и по сети грузить, но зачем?

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

                                                    Переделываются частности реализации в угоду производительности или нового оборудования. Распределение процессорного времени на основе потоков под контролем ОС старо как мир, и альтернативные варианты, такие как аппаратная многозадачность, провалились.
                                                    Что-то мне подсказывает: если возникнет проблема согласования, то головная контора (верховный совет директоров — представитель акционеров) достаточно быстро принудит подразделения к тесному сотрудничеству.

                                                    Как и интел с МС.
                                                    Я тут как бы намекаю, что разместить клиента на отдельном процессоре с отдельной памятью — дешевле, чем запихивать десять клиентов на один мощный процессор с общей памятью.

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

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

                                                    0.1% + 0.1% расходов, это же 0.2% расходов, ну просто обалдеть!
                                                    Только сейчас я понял, что вы предлагаете ускорять то, что в ускорении в общем то не нуждается. Обслуживание файловой системы практически нигде не является бутылочным горлышком и вряд ли где поглощает заметную часть ресурсов. Все тормоза при работе с файлами идут от медленных устройств, и никакие отдельные процессоры ускорения тут не дадут. Только кеш и более быстрая работа самого диска, например, замена на SSD, замена обычного SSD на версию с PCI-e и NVMe.
                                                    Давайте, предложите разработчикам консолидировать всю оперативную память

                                                    Ой, а как же Ваша любимая консолидация ресурсов?

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

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

                                                    Менять видеокарту при смене ОС? И держать парочку под разные, а то знаете ли, многие любят перезагружаться в разные.
                                                    А вот для сетевой подсистемы — надо ставить процессор без FPU.

                                                    И их ставят там, где нужно. Вот спека первой попавшейся сетевой карты уровня чуть выше домашней
                                                    Performance Features:
                                                    16 Transmit and 16 Receive queues per port
                                                    Up to 16 queues of Receive Side Scaling (RSS) minimize CPU utilization across multiple processor systems
                                                    Support PCI-SIG Single-Root I/O virtualization Rev 1.1.
                                                    Support for up to 8 virtual function ( VFs)
                                                    Partial replication of PCI Configuration space
                                                    Support for 8 pools (single queue) of virtual machine Device Queues (VMDq) per port
                                                    Support Direct Cache Access (DCA)
                                                    Support Intel I/O Acceleration Technology v3.0.
                                                    TSO interleaving for reduced latency
                                                    Minimized device I/O interrupts using MSI and MSI-X
                                                    UDP, TCP and IP checksum offload
                                                    UDP and TCP transmit segmentation offload (TSO). machine
                                                    SCTP receive and transmit checksum offload
                                                    Packet interrupt coalescing timers (packet timers) and absolute-delay interrupt timers for both transmit and receive operation
                                                    EEE ( IEEE 802.3az) for reduced power consumption during low link utilization periods

                                                    Да, всё это реализовано на intel I350AM2.
                                                    для файловой системы — тоже

                                                    Вы не представляете число проблем, костылей и уступок, на которые нужно будет пойти, чтобы вынести обработку файловых систем из ядра ОС. И поверьте, это будет медленнее и будет жрать больше оперативной памяти.
                                                      –2
                                                      Переделываются частности реализации в угоду производительности или нового оборудования.
                                                      Вообще-то, переделываются отнюдь не частности реализации. Там регулярно делается полный рефакторинг; это примерно как переход от ST-506 к IDE/ATA. С т.з. прикладных программ (да и с т.з. операцонки) практически ничего не поменялось; а вот внутри — полный рефакторинг.

                                                      По поводу «нового оборудования» гораздо интереснее. Наверно, Вы заметили, что я как раз и предлагаю то, что входит в это понятие?

                                                      Распределение процессорного времени на основе потоков под контролем ОС старо как мир
                                                      Ой, далеко не «как мир», а гораздо моложе. Вычислительные системы сначала долго были однозадачными и даже однопрограммными. А на писюках ещё был долгий период кооперативной многозадачности (при том, что первые писюки были однозадачными, похерив все достижения больших ЭВМ).

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

                                                      Как и интел с МС.
                                                      А в статье говорится, что они много лет не сотрудничали на тему предотвращения Meltdown!

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

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

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

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

                                                      0.1% + 0.1% расходов, это же 0.2% расходов, ну просто обалдеть!
                                                      Я немного не уверен в том, что расход производительности на файловую систему такой маленький. Ну, понятно, что это зависит от типа файловой системы. Но вот беда — FAT, в котором расходы низкие, как бы немного неактуален (ну, разве что для переносимых накопителей, где важна совместимость). А вот серьёзные сстемы типа ZFS — прожорливы как Лэсси Рерих

                                                      Все тормоза при работе с файлами идут от медленных устройств, и никакие отдельные процессоры ускорения тут не дадут.
                                                      Уж не хотите ли Вы сказать, что создатели аппаратных RAID-контроллеров лгут, обещая повышение производительности относительно программной организации RAID-массива? А ведь вычисления для RAID-массива — на порядок слабее, чем вычисления для файловой системы!

                                                      Вы всё преувеличиваете и доводите до абсурда.
                                                      Я всего лишь предлагаю Вам быть последовательным. Вы агитируете за консолидацию ресурсов — но консолидировать разные виды памяти отказываетесь.
                                                      Но тогда я в упор не вижу аргументов — почему вынесение файловой системы на отдельный юнит (отдельный процессор с отдельной памятью) д.б. медленнее, чем консолидированная система. (Смотрим выше — на аргумент с RAID-контроллером. Почему бы не консолидровать его?)

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

                                                      Менять видеокарту при смене ОС?
                                                      Простите, а почему Вы решили, что видеокарта не сможет работать при смене операционки?
                                                      (Впрочем, проблемы совместимости есть и сейчас — запросто можно встретить ситуацию, когда новая операционка не может работать со старым оборудованием; или старая операционка не может работать с новым оборудованием. Например, у меня в загашнике есть PCI-сетевуха от HP — которую я вообще не смог запустить ни в одной операционке (возможно — недостаточно сильно старался).

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

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

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

                                                        С появлением NT потоки появились в их современном виде, но зачатки были с первых Windows.
                                                        А то Википедия не знает.

                                                        Первый в мире мультимедийный персональный компьютер Amiga 1000 (1984 год) изначально проектировался с расчётом на полную аппаратную поддержку вытесняющей многозадачности реального времени в ОС AmigaOS.
                                                        © Википедия.
                                                        Гугл выдаёт ссылки на HyperThreading

                                                        Мне выдало ссылку выше, а так же статью про ОС на Хабре, где проще и быстрее оказалось забить на аппаратную поддержку многозадачности в x64.
                                                        А в статье говорится, что они много лет не сотрудничали на тему предотвращения Meltdown!

                                                        ? Не заметил.
                                                        Если читали, то расскажите, на каком уровне происходит пробой изоляции.

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

                                                        Поэтому держите банковский софт на отдельном ПК, всё остальное полумеры.
                                                        Но вот беда — FAT, в котором расходы низкие, как бы немного неактуален (ну, разве что для переносимых накопителей, где важна совместимость). А вот серьёзные сстемы типа ZFS

                                                        А между этими опять таки крайностями ничего нет? Ни NTFS, ни EXT4?
                                                        А ведь вычисления для RAID-массива — на порядок слабее, чем вычисления для файловой системы!

                                                        Да вы что?
                                                        Почему Вы не рассказали производителям, что этого делать не надо, что это слишком затратно?

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

                                                        Потому что разные ОС использую разные подходы к композиции окон рабочего стола. Более того- разные окнные менеджеры Linux делают это по разному.
                                                        Вообще-то, основная работа уже сделана — в виде микроядерных систем.

                                                        Которые пылятся на небольшом числе ПК. Вы то как, последовательны, и используете именно такую ОС на вашем ПК?
                                                        А вот по скорости — ожидается ускорени.

                                                        А я, неплохо знающий архитектуру ОС, ожидаю замедления. Кто же прав?
                                                        Чисто за счёт того, что каждый пул памяти обслуживает свой процессор, и процессоры не конфликтуют за доступ к памяти.

                                                        И часто они это делают?
                                                          –1
                                                          С появлением NT потоки появились в их современном виде, но зачатки были с первых Windows.
                                                          Хм-м-м… Откуда Вы это взяли?

                                                          Концепция многопоточности начала складываться, по-видимому, с 1980-х гг. в системе UNIX и ее диалектах. Наиболее развита многопоточность была в диалекте UNIX фирмы AT&T, на основе которого, как уже отмечалось в общем историческом обзоре, была разработана система Solaris. Все это отразилось и в стандарте POSIX, в который вошла и многопоточность, наряду с другими базовыми возможностями UNIX.
                                                          Далее, в середине 1990-х гг. была выпущена ОС Windows NT, в которую была также включена многопоточность.


                                                          Первый в мире мультимедийный персональный компьютер Amiga 1000 (1984 год)
                                                          Самые первые персональные компьютеры были восьмибитными; в них не было аппаратной поддержки функций, необходимых для вытесняющей многозадачности.

                                                          Если же говорить о *86 — то там ущербная защита появилась только в 286, а полноценная — в 386. Т.е. и IBM-PC тоже не сразу стали пригодны для вытесняющей многозадачности.

                                                          Мне выдало ссылку выше, а так же статью про ОС на Хабре, где проще и быстрее оказалось забить на аппаратную поддержку многозадачности в x64.
                                                          По ссылке нет никаких объяснений — что же такое «аппаратная многозадачность». Там всего лишь упоминается ограничение «8192 дескрипторов» — причём неясно, что это за дескрипторы. Странная статья.

                                                          ? Не заметил.
                                                          Значит, это было где-то в другой статье, тоже на Хабре. Там говорилось, что уязвимость существует давно, и что в Intel про неё знают тоже давно — но молчали.

                                                          А в статье говорится про семь месяцев — тоже прилично.

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

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

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

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

                                                          А между этими опять таки крайностями ничего нет? Ни NTFS, ни EXT4?
                                                          Есть. И чем совершеннее они — тем прожорливее.

                                                          Да вы что?
                                                          Ну, рассказывайте — что там надо вычислять.

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

                                                          Потому что разные ОС использую разные подходы к композиции окон рабочего стола. Более того- разные окнные менеджеры Linux делают это по разному.
                                                          Я так понимаю, Вы не в курсе, что в видеокарту можно загружать разные программы — в т.ч. майнинговые. Соответственно, если операционка пожелает — засунет туда X-сервер; а можно засунуть что-то другое.

                                                          Вы то как, последовательны, и используете именно такую ОС на вашем ПК?
                                                          Нет, очевидно. Ведь аппаратура моего компьютера — заточена на монолитную систему.

                                                          Ещё раз повторю: «основная работа уже сделана — в виде микроядерных систем». Но сделанная работа — не является окончательным решением.

                                                          А я, неплохо знающий архитектуру ОС, ожидаю замедления. Кто же прав?
                                                          Эксперимент покажет.

                                                          И часто {ли процессоры конфликтуют за доступ к памяти}?
                                                          Это сильно зависит от архитектуры.
                                                          При общем «плоском» кэше — будут конфликты за доступ к кэшу.
                                                          При общем «многослойном» кэше — конфликты подавляются, но это достигается за счёт двухслойного диспетчера запросов, что увеличивает латентность.
                                                          При раздельном кэше — падает КПД использования кэша, а конфликты происходят при операциях записи в память, когда кэши надо синхронизировать.

                                                          Гланое преимущество раздельной памяти — это снижение потребности в кэшировании.
                                                            +1
                                                            Чёрт, длина комментария превысила все разумные пределы. Спрятал под спойлер, ещё пару обменов мнениями, и я выйду из беседы, а то больне неудобно это делать.
                                                            Основное сообщение
                                                            Хм-м-м… Откуда Вы это взяли?

                                                            Из головы? Что поделать, я лучше знаю Windows.
                                                            Кстати, ваша ссылка только укрепляет мою позицию на счёт давнего появления многопоточности.
                                                            Т.е. и IBM-PC тоже не сразу стали пригодны для вытесняющей многозадачности.

                                                            Это очевидно. И что дальше? К чему вы это написали?
                                                            Странная статья.

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

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

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

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

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

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

                                                            А вы чего ожидали, я не пойму? Чуда?
                                                            Но при этом они быстрее. Толку от того, что на FAT процессор загружен на 1%, когда на самом деле он ждёт какой-нибудь глобальной блокировки? А современные ФС пишутся с расчётом на многоядерные системы, и по минимуму используют блокирующие операции.
                                                            Вот например NTFS старается объединять несколько разных записей в один пакет, выстраивая команды по порядку для более быстрой их обработки жёстким диском и минимизации перемещения головок. Ест ли она больше ресурсов на это? Безусловно. Работает ли медленнее? Нет!
                                                            Другой причиной увеличения потребления ресурсов является их большая отказоустойчивость. Я не помню ни одного случая, когда у меня отказывала NTFS, кроме развала диска, а вот FAT за его короткую историю проживания у меня пару раз слетал.
                                                            Ну, рассказывайте — что там надо вычислять.

                                                            Коды Рида — Соломона или то, что их заменяет.
                                                            А мне, значит, указываете? ;)

                                                            А вы не достаточно компетентны в вопросе.
                                                            Я так понимаю, Вы не в курсе, что в видеокарту можно загружать разные программы — в т.ч. майнинговые.

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

                                                            А что мешает вам купить заточенную? Я давал пример процессора для сети- всего 4,5 тысячи рублей у галимых китайцев. Берите и отключайте паршивую встроенную, которая, ворюга такая, крадёт время на центральном процессоре для важнейшей задачи обработки ваших сетевых пакетов.
                                                            Хотя это всего лишь сетевая карта, и вам, видимо, нужно что-то большее. Помнится, некоторые компьютеры поддерживали дополнительные процессоры, и при их добавлении ОС исполнялась только на центральном, а программы на дополнительном. Не об этом ли вы мечтаете?
                                                            Это сильно зависит от архитектуры.

                                                            Причём тут архитектура, когда я про конкурентный доступ в программах? Всю ли память пытаются получить все программы, или всё же конкуренция идёт за небольшие ресурсы, отведённые на блокировку и синхронизацию, и текущего решения вполне хватает?
                                                              –1
                                                              Из головы? Что поделать, я лучше знаю Windows.
                                                              Я не знаю, откуда Вы взяли, что потоки появились именно в Windows. Мой опыт подсказывает, что для Windows мало что было придумано — в основном цельнотянуто, да ещё и криво. Например, переназначение ввода/вывода в command.com — типичный пример того, как люди увидели что-то крутое и криво реализовали у себя.

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

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

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

                                                              Это очевидно. И что дальше? К чему вы это написали?
                                                              Это я о необходимости рефакторинга аппаратных и программных систем. Я так понимаю — отрицать такой рефакторинг в прошлом Вы не можете. А вот отрицать необходимость очередного рефакторинга — берётесь.

                                                              Я не знаю подробностей
                                                              Но при этом выкатываете какую-то мифическуую «аппаратную многозадачность» в качестве аргумента — при том, что нагуглить её не получается.
                                                              И при этом ссылаетесь на свою высочайшую компетентность.

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

                                                              но ею не пользуются из-за её тормозов.
                                                              Вы сделали мне хорошее настроение!

                                                              Я вообще не понял, почему все решили, что микроядерные ОС не уязвимы для этой атаки.
                                                              (Занудно.) Потому что микроядерность — это принципиальный запрет на доступ компонента в память, куда ему не нужно лазать. И защита через Ring-Level тут не работает.

                                                              Вне всякого сомнения, процесс исправления ошибок вещь бесконечная. И что теперь, выкинуть ПК в окно, раз они принципиально уязвимы?
                                                              У меня такое ощущение, что Вы не слышали про способы построения надёжных систем из ненадёжных компонентов. В данном случае речь не о программных или аппаратных компонентах, а о людях — как компонентах системы разработки программ и аппаратуры.
                                                              Так вот, пока в лицензионых соглашениях будет пункт «система поставляется как есть, используйте её на свой страх и риск» — ни о какой надёжности работы речи не будет. Государство должно ввести ответственность разработчиков — по типу того, как строительные архитекторы отвечают за надёжность построенных по их проектам зданий. Чтобы все разработчики знали: за косяки они поедут валить лес. И поедут не рядовые исполнители, а руководители (ага-ага, Вы правы: это пахнет сталинизмом).

                                                              Ну хорошо, специально вам могу порекомендовать отказ от банковских карт и переход на наличность. Вы же любите быть последовательным?
                                                              Это мне напоминает вопрос Карлсона, адресованный к фрёкен Бок: «Бросила ли ты пить коньяк по утрам?».
                                                              Трудно отказаться от того, чего у меня нет и никогда не было. Вот видите, какой я последовательный!

                                                              Коды Рида — Соломона или то, что их заменяет.
                                                              У меня есть сильное подозрение, что RAID'6-массив используется довольно редко. Вероятно, это в основном от того, что даже RAID'5 способен развалиться из-за каких-то непонятных сбоев, причём сами диски при этом живые. Т.е. эти сложные RAID-массивы не увеличивают надёжность, а понижают её.

                                                              Но почему же аппаратный RAID-контроллер рекомендуется для случаев, когда используются более популярные RAID-массивы 0, 1 или 5?

                                                              Так вы же агитируете за аппаратную специализацию, а подобные нагрузки на ГПУ не являются его предназначением.
                                                              Видите ли, когда производители выпускали видеокарты с ускорителями — никто не предназначал их для майнинга. Как же тогда майнеры умудрились-то?

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

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

                                                              А что мешает вам купить заточенную?
                                                              Отсутствие в широкой продаже, отсутствие документации, отсутствие сообщества с возможностью дать советы, отсутствие программного обеспечения…

                                                              Помнится, некоторые компьютеры поддерживали дополнительные процессоры, и при их добавлении ОС исполнялась только на центральном, а программы на дополнительном. Не об этом ли вы мечтаете?
                                                              Да-да, примерно это. Только ещё и с отдельной памятью для этих процессоров.

                                                              И часто {ли процессоры конфликтуют за доступ к памяти}?
                                                              {...}
                                                              Причём тут архитектура, когда я про конкурентный доступ в программах?
                                                              Вы меня в очередной раз вгоняете в ступор. Впрочем, наверно, мне надо приучиться правильно реагировать на людей, которые заявляют о собственной высочайшей квалификации…

                                                              Я говорю о конфликте процессоров при доступе в память. Процессоров — в память, а не программ — к данным. Это, видите ли, принципиальная разница.

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

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

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

                                                              А вопрос с общими данными — решается по принципу клиент-серверной архитектуры:
                                                              1) Никто не позволяет клиентам лазать в системные области (MBR, BR, FAT, директории) файлового сервера. Файловый сервер сам туда лазает по мере необходимости; а клиентам отдаёт только их данные.
                                                              2) Но файловый сервер — слишком универсальное решение, поэтому он мало где оптимален. Например, SQL-сервер (менее универсально — потому более эффективное и безопасное решение там, где оно пригодно) не даёт доступа не только к системным областям диска, но и к системным областям базы данных (а вот древние СУБД предполагали, что клиенты сами корректно лазают в системные области базы данных — что порождало массу проблем).

                                                              И вот так же надо поступать со всеми данными, доступ к которым хочет получить много программ:
                                                              Данные коллективного доступа располагаются в какой-то памяти. В процессоре, который привязан к этой памяти (имеет туда прямой доступ), запускается программа-сервер. И все, кто хотят получить доступ к данным — обращаются к этому серверу. А сервер уже решает — осуществлять операции последовательно или выставлять блокировки.
                                                                0
                                                                По уже традиции прячу под спойлер
                                                                Основное сообщение
                                                                Я не знаю, откуда Вы взяли, что потоки появились именно в Windows.

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

                                                                Я не отрицаю необходимость изменений. Я уверен, что предлагаемый вами путь не есть тот, который будет реализован.
                                                                Но при этом выкатываете какую-то мифическуую «аппаратную многозадачность» в качестве аргумента — при том, что нагуглить её не получается.

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

                                                                Даже не представляю, что это за процессоры. Калькуляторы?
                                                                Осталось понять, какую такую особую поддержку назвали громким словом «аппаратная многозадачность»

                                                                Вы сделали мне хорошее настроение!

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

                                                                Защита через аппаратные возможности процессора вполне себе принципиальная… Была.
                                                                У меня такое ощущение, что Вы не слышали про способы построения надёжных систем из ненадёжных компонентов.

                                                                И кому это нужно? Где нужно, это давно используется- космическая промышленность, авиация, атомная. Простому пользователю надёжная система, которая будет стоить в пять раз больше нынешних «ненадёжных», не нужна.
                                                                Т.е. эти сложные RAID-массивы не увеличивают надёжность, а понижают её.

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

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

                                                                Так же, как и физика в играх. Майнинг, основанных на хешах, прекрасно ложится на архитектуру ГПУ, в отличии от задач Х-сервера.
                                                                Ну, на сколько потоков можно разбить — столько вычислительных юнитов он и займёт.

                                                                И будет дико тормозить, так как потоки в ГПУ значительно слабее потоков ЦП.
                                                                Да-да, примерно это. Только ещё и с отдельной памятью для этих процессоров.

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

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

                                                                Боюсь, производительность этого решения будет совсем унылой.
                                                                  –1
                                                                  А я не знаю, откуда вы взяли, что я утверждал {что потоки появились именно в Windows}.
                                                                  Как понимать фразу «С появлением NT потоки появились в их современном виде»? Вероятно, что до NT их вообще не было.

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

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

                                                                  Даже не представляю, что это за процессоры {не имеют аппаратных фичей — переключать процессы, потоки и вообще что-либо}. Калькуляторы?
                                                                  Ну, как минимум — для принудительного переключения потока/процесса нужны аппаратные прерывания. У большинства процессоров они есть, но это не обязательная фича — вполне м.б. процессоры без прерываний.

                                                                  Для работы с процессами нужна аппаратная защита памяти (страничная, сегментная или ещё какая-то). Процессоры без такой защиты — известны, хотя в наше время они практически сошли со сцены.

                                                                  Но я надеюсь, Вы согласны с тем, что для принудительной многозадачности требуются аппаратные ичи?
                                                                  (А вот для добровольной-кооперативной многозадачности — не требуется ничего, кроме способности выполнять программы, что требуется и для однозадачных систем.)

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

                                                                  Защита через аппаратные возможности процессора вполне себе принципиальная… Была.
                                                                  Хорошо, я напомню второй аргумент: для микроядерных систем не работает защита через Ring Level — тот самый механизм, который является одним из трёх компонентов, сочетание которых и породило уязвимость.

                                                                  Чтобы не ждать Вашего вопроса «Почему не работает???» (ожидаемо от человека, который постоянно упоминает свою высочайшую квалификацию), отвечу сразу:
                                                                  Потому что защита через Ring Level работает в одну сторону. А при микроядерности надо защищать десятки компонетов друг-от-друга.

                                                                  И кому это нужно {построение надёжных систем из ненадёжных компонентов}? Где нужно, это давно используется- космическая промышленность, авиация, атомная. Простому пользователю надёжная система, которая будет стоить в пять раз больше нынешних «ненадёжных», не нужна.
                                                                  Ну, начнём с определения слова «нужно». Ибо есть объективная нужда, а есть осознаваемая — и они не всегда сопадают.

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

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

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

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

                                                                  Кем, где, для кого?
                                                                  Производителями RAID-контроллеров!

                                                                  Майнинг, основанных на хешах, прекрасно ложится на архитектуру ГПУ, в отличии от задач Х-сервера.
                                                                  Значит, надо думать в сторону изменеия архитектуры GPU.
                                                                  Впрочем, это не имеет смысла, пока не поменяют архитектуру взаимодействия задачи-владельца окна с X-севрером: надо отказаться

                                                                  И будет дико тормозить, так как потоки в ГПУ значительно слабее потоков ЦП.
                                                                  Зато их много!

                                                                  Но ведь от этих систем {с отдельной памятью для этих процессоров} отказались, и не просто так.
                                                                  Конечно же, не просто так. А потому, что тандем Intel+MicroSoft захватил рынок — и вовсе не техническим совершенством своих решений.

                                                                  Так вот, намного проще и производительнее расширить эту шину, увеличить скорость и уменьшить латентность, чем переписывать весь софт на свете под специально разработанную архитектуру процессоров.
                                                                  Расширить шину, говорите? Ну и куда её расширять, если и сейчас платы уже шестислойные?
                                                                  Увеличить скорость? Каким же это образом?
                                                                  Уменьшить латентность? Ой, Вы делаете мне смешно — её давно уже не могут уменьшить!

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

                                                                  Боюсь, производительность этого решения {клиент-серверной архитектуры} будет совсем унылой.
                                                                  Пока что унылой стала производительность общепринятой архитектуры — из-за патча против Meltdown.
                                                                    +2
                                                                    Вы ведёте дискуссии с длиной сообщений в два экрана лучше меня, я так не умею. Устал, умываю руки.
                                  +2
                                  чертежи, где расписано расположение транзисторов на кристалле

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

                                  У Apple с последними айфонами почти так. Только не пойму, про какую неразбериху вы пишите? Уязвимость процессора есть уязвимость, и она будет как в отдельной компании, так и в отдельном подразделении одной корпорации.
                                    0
                                    маски, по которым делают процессоры. Хотя мне стало интересно, сколько будет весить такая схема, скажем, для ГПУ с миллиардом транзисторов?

                                    Те маски, по которым изготавливают чипы (после 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

                                      +1
                                      >> для ГПУ с миллиардом транзисторов?
                                      У Nvidia GV100 — 21 миллиард транзисторов (815mm²)
                                        –1

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


                                        Сколько оно весит — я не знаю. Но на каких-то накопителях оно размещается.


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


                                        Apple использует процессоры i*86 от Intel в настольльных компьютерах и ноутбуках; и процессоры ARM в айфонах — такие же, как используются в Android-устройствах. Естественно, эти продукты затронуты общей проблемой.
                                        Я как бы намекаю, что чем больше разнообразие продуктов — тем меньше ущерб от эпидемий (это и в сельском хозяйстве так, и в компьютерных экосистемах).

                                      –2
                                      del
                                        +5
                                        Меня в этой истории отдельно неприятно удивило то, как Intel и Google грубо и недальновидно работали с вендорами открытого софта и коммьюнити.

                                        Популярные дистрибутивы Linux почему-то получили disclosures еще в ноябре, а *BSD и многие другие ничего не знали до последнего момента (Тео, как всегда, не стесняется в выражениях по этому поводу). Чуваки даже не подумали (или им было пофиг), что крупные коммиты в VM-подсистему ядра без внятного объяснения неизбежно вызовут у публики вопросы со всеми вытекающими последствиями. Чуваку из AMD разрешили (или не уследили, по факту неважно) раструбить про спекулятивные ссылки до окончания эмбарго. Вот эти все организационные фейлы едва ли не затмевают собственно главный фейл (проблемы в процессорах).
                                          +3

                                          Видел информацию о том, что разработчики FreeBSD получили инфу вовремя, а с Тео произошла забавная история. Когда нашли баг в WPA2 ему сообщили о уязвимости наряду со всеми, но он раскрыл инфу о ней широкой общественности до оговоренной даты релиза. После этого случая ему сказали, что будут сообщать ему о таких уязвимостях в последний момент. Снятие эмбарго на мелтдаун планировалось на 9 января и вероятно ему бы сообщили детали уязвимости 6-7 января, но инфу разболтали раньше времени.

                                            +2
                                            С FreeBSD Intel поделилась информацией (под NDA) только в конце декабря, это отнюдь не вовремя. OpenBSD действительно нарушали эмбарго в прошлом, ну дык я за них особо и не топлю.
                                            0
                                            Не важно, было им пофиг или нет, но что вы предлагаете делать? У большинства дистрибутивов открытые исходники ядра, других вариантов не было.
                                              +1
                                              Коммиты можно было скоординировать по времени, можно было заранее согласовать (не)включение KPTI (mitigation для Meltdown) с ребятами из AMD. Можно было договориться, кому и что можно, а что нельзя говорить в паблике. При желании всё можно было сделать быстро и прозрачно (запатчить ядра Linux/*BSD, выпустить официальное заявление), но было сделано как было сделано. :-(
                                            +11
                                            Ситуация описывает почему невозможно достаточно долго реализовывать любую теорию заговора.
                                              +1
                                              Так, исключительно с целью пофантазировать — представьте себе хаос, если когда-нибудь окажется, что факторизацию или логарифм по модулю можно за полиномиальное время решить…
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                –6
                                                Ещё один патч от Microsoft был скомпилирован и выпущен в канун Нового года, что говорит, что команда компании, вероятно, работала над ним всю ночь
                                                Так вот почему у меня 31-го вечером стала падать винда с BSOD по памяти. Кстати, вылечилось только заменой на новую планку.
                                                  0
                                                  Старая планка абсолютно нормальная — все тесты проходит и в другом компе работает без ошибок.
                                                    0
                                                    Держите нас в курсе!
                                                  0
                                                  Но Шварц столкнулся с ещё одной проблемой: как сохранять в секрете такую серьёзную уязвимость достаточно долго, чтобы её можно было исправить?.

                                                  Ну а почему бы и нет? Прежде всего — компании такого масштаба беспокоит репутация, оборот, продажи! Помимо этого, чипами данной компании пользуется огромное кол-во потребителей (и даже я))) и если среднестатический потребитель просто откажется от использования, то крупные компании потребуют неустойку!
                                                  «Из того, что описал программист Том Лендаки из AMD, следует, что ЦП от Intel грешат спекулятивным выполнением кода без проверок на безопасность»
                                                  Отсутствие изоляции ядра. Читала.
                                                  А сайты — следствие и, возможно, маркетинговый ход, чтоб как можно большее кол-во клиентов воспользовались патчем!
                                                  Ух!.. На втором ПК у меня чип AMD! Как же хорошо, что мы не устанавливали последние обновления! Кстати, впервые до оповещения в СМИ данную информацию я нашла здесь. Вот, чем ценен ресурс! И именно благодаря ему не устанавливали обновления.
                                                    0
                                                    Еще раз, для тех, кто очень далек от всех этих тонкостей и нюансов. С AMD все ОК? Или нет?
                                                      +1
                                                      Не всё ок, и AMD неохотно признаёт проблемы, из-за чего получило иск , ещё линк
                                                        –1
                                                        Все ок. meltdown мимо. спектр практически не применим. Иски — ерунда, высосанная из пальца. AMD с самого начала достаточно четко описала, что и как.
                                                          –1

                                                          Поправьте меня если не прав, но получается, что наиболее критичные по производительности патчи, это патчи как раз для meltdown? Получается, что на ADM действительно просадки по производительности будут ниже, чем на Intel?

                                                        –1
                                                        тут даже уже новые фантомасы полезли skyfallattack.com
                                                          0
                                                          я вот что не понимаю — если об уязвимости стало известно аж в середине 2017 — то почему патчи пришлось «срочно писать» в декабре?? что они пол-года то делали? запихивали червяков обратно в банку и надеялись что само пройдёт?
                                                            0

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

                                                            0
                                                            Поясните. Процессор Байкал подвержен данным рискам?
                                                              +1

                                                              https://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 нет за счет дополнительной проверки.
                                                              0
                                                              Это все классно, но я так и не понимаю чего хотят вендоры дальше. Кржанич, явно стреманулся и слил свои акции Microsoft, Intel зная об уязвимости решила выпустить поколение процессоров в которых по прежнему сохранена уязвимость, без компании с отзывом. Т.е. алчность победила, здравый смысл, я правда так не понимаю кто будет покупать их новые процессоры, но наверное от безысходности будут.
                                                              Я полагал, что все таки замена CPU должна стать основным решением а все эти заплатки должны только выиграть время для реализации главного плана. Но судя по действиям основных виновников не видно никаких намеков на решение основной проблемы — на что менять текущие CPU?
                                                                0
                                                                без компании с отзывом

                                                                А это вообще возможно без банкротства Intel?
                                                                  0

                                                                  Думаю возможно. Samsung в Британии работает по схеме — платишь таксу ежемесячно и получаешь новый топовый продукт сразу после выхода, в обмен на старый. Т.е. от схемы с разовой оплатой по сути перешли на подписку. Интел тоже мог так сделать, мол вот вам устройства но мы знаем о проблеме поэтому в следующем поколении исправим и продадим в обмен на старые за пол или треть цены. Лояльность потребителей дороже стоит.

                                                                    0
                                                                    платишь таксу ежемесячно и получаешь новый топовый продукт сразу после выхода

                                                                    Что-то мне кажется, что это выйдет не меньше, чем полная стоимость, с учётом переработки старого.
                                                                +2

                                                                Это в очередной раз доказывает, что единственная нормальная стратегия добронамеренного ресерчера — это 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. И плевать сколько людей пострадало бы из-за действий детишек, а удар по репутации производителей уязвимых чипов от этого был бы вполне заслужен, всё-таки не исследователи создали эту уязвимость (бекдор?), главное чтобы фикс был как можно скорее, а производители наконец стали прилагать все необходимые усилия, чтобы такого не повторилось.

                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                    0
                                                                    Чем проверяли?

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

                                                                  Самое читаемое