Comments 96
характерен ли Meltdown только для Intel (чипы от AMD тоже пострадали)а нет ли тут какого-то уточнения, что значит «пострадали»? Кто-то смог воспроизвести Meltdown на процессорах AMD?
В оригинале там ARM (ARM chips are also affected).
Перепутать AMD и ARM — это нечто уровня интернет-магазина с китайфонами. Мне известны как минимум 2 таковых.
По существу: если эта уязвимость так трудна в обнаружении, то очевидно, что и в эксплуатации она также очень трудна. Следовательно, вероятность того, что какой-нибудь хакер сможет к ней присосаться, причём не абы как, а результативно — крайне низка. Я бы даже сказал так: эксплуатация Meltdown и Spectre практически невозможна.
По существу: если эта уязвимость так трудна в обнаружении, то очевидно, что и в эксплуатации она также очень трудна. Следовательно, вероятность того, что какой-нибудь хакер сможет к ней присосаться, причём не абы как, а результативно — крайне низка. Я бы даже сказал так: эксплуатация Meltdown и Spectre практически невозможна.
Я бы даже сказал так: эксплуатация Meltdown и Spectre практически невозможна.
Ну вам конечно виднее
А вот тут вы не правы ибо при наличии готового эксплойта использующего эту уязвимость применять её в своих тёмных делишках сможет любой малолетний прыщавый скрипткидди.
Правда вот реалистичность такого сценария сомнительна. Все примеры демонстрируют идеальные условия — взяли готовый адрес из подопытного примитивного приложения и читаем, что нам нужно. Для начала, этот адрес надо найти и сделать это в рантайме, что далеко не так уж тривиально. И работает это все слишком медленно, чтобы парсить гигабайты памяти в поиске заветной строчки. Таки это совершенно другой сложности уязвимость, нежели когда у тебя на руках RCE, где только и остается что собрать код для выполнения.
Она поразила практически все крупные технокомпании мира, от серверных ферм Amazon до производителей чипов вроде Intel и ARM.
Корректно ли это высказывание? ARM — архитектура процессоров, ARM ltd., впрочем, чипы тоже не производит.
ИМХО, уязвимость затронула чипы на архитектуре ARM, соответственно это предложение можно считать верным. Может быть не все, но всё-таки.
Так проблема как раз с архитектурой. Так что любой производитель чипов с ядром от АРМ соответсвующей архитектуры будет подвержен уязвимости. Правда не все типы АРМ имеют такие проблемы. Список проблемных — developer.arm.com/support/security-update
UFO just landed and posted this here
Так вот как ФСБ получила доступ к секретным данным против предвыборной кампании Хилари.
UFO just landed and posted this here
Боролась не только Интел, но ещё и команда ядра Линукса, Гугл, Амазон, Майкрософт, Амд и прочие. А разглашать информацию до этого означало проинформировать хакеров о проблеме до того, как у кого-нибудь будет решение.
Собственно, поэтому некоторые патчи были применены до того, как о проблеме стало известно широкой публике. И в статье об этом говорится.
Собственно, поэтому некоторые патчи были применены до того, как о проблеме стало известно широкой публике. И в статье об этом говорится.
UFO just landed and posted this here
Почему Intel должен это делать? Не должна ли Apple опубликовать полную спецификацию iPhone X, чтобы любой мог дополнить его нужными фичами?
UFO just landed and posted this here
Я думаю, что нет, не должна.
UFO just landed and posted this here
Вы сейчас предлагаете компаниям заниматься иррациональными вещами. Польза для общества — не самоцель для компаний. Заработать денег — вот смысл существования любого бизнеса.
UFO just landed and posted this here
Вы, случайно, не с Альфы-Центавра сюда прилетели?
Ваше мнение мало значит, пока вы не поруководили многотысячными коллективами и не поуправляли трилионными ресурсами. Это примерно как пара уборщиц, обсуждающих «нахапавшего» гендиректора корпорации.
Не хочу сказать, что на верхнем уровне управления работают ангелы с нимбиками, но уверен, что скилл товарищей весьма высок, а количество входящих условий известных им, критично больше, чем известно вам. Это не гарантирует безошибочности действий корпораций или правительств, но практически гарантирует ошибочность ваших выводов.
Кроме того, управляющие решения, затрагивающие миллионы людей не могут быть всемилостливыми от слова «никогда». Поэтому открытость информации на верхних уровнях управления, как я понимаю, разрушительна по определению. Пока вы будете кормить семью хлебами голодных, обязательно найдутся: 1) недовольные продавцы зерновых; 2) мошеники, предлагающие накормить шестью хлебами; 3) еб… тые, которые будут утверждать, что выпив два литра водки и закусив вашим хлебом они отравились; 4) невыбранный депутат от мафии, который будет утверждать, что источник получения ваших семи хлебов дурно пахнет; 5) журналист, который для тиража напишет статью о том, что ваши хлеба генномодифицированы, иначе как можно так накормить; 6) террорист, который во имя Великой цели будет искать способ ваши хлеба отравить или хотя бы заплесневеть…
И еще будет желтая печать и форумы называющие вас… составьте сами список ушат дерьма плиз…
Не хочу сказать, что на верхнем уровне управления работают ангелы с нимбиками, но уверен, что скилл товарищей весьма высок, а количество входящих условий известных им, критично больше, чем известно вам. Это не гарантирует безошибочности действий корпораций или правительств, но практически гарантирует ошибочность ваших выводов.
Кроме того, управляющие решения, затрагивающие миллионы людей не могут быть всемилостливыми от слова «никогда». Поэтому открытость информации на верхних уровнях управления, как я понимаю, разрушительна по определению. Пока вы будете кормить семью хлебами голодных, обязательно найдутся: 1) недовольные продавцы зерновых; 2) мошеники, предлагающие накормить шестью хлебами; 3) еб… тые, которые будут утверждать, что выпив два литра водки и закусив вашим хлебом они отравились; 4) невыбранный депутат от мафии, который будет утверждать, что источник получения ваших семи хлебов дурно пахнет; 5) журналист, который для тиража напишет статью о том, что ваши хлеба генномодифицированы, иначе как можно так накормить; 6) террорист, который во имя Великой цели будет искать способ ваши хлеба отравить или хотя бы заплесневеть…
И еще будет желтая печать и форумы называющие вас… составьте сами список ушат дерьма плиз…
UFO just landed and posted this here
Нет, не «сперва добейся». Я говорю о том, что обсуждать действия на таком уровне управления, не находясь там и не владея всей информацией — пустое. Вы никогда не поймете в каком русле их скилл (я писал: «Это не гарантирует безошибочности действий корпораций или правительств»), не потому что вы тупы, а потому что вам никто не даст полной информации. Будь вы семи пядей во лбу, вы будете опираться на сообщения в массмедиа, а не на реальную информацию и сделаете неверные или неполные выводы.
Простая вводная — допустим в какой-то момент представители Интел и подобных совещались с Пентагоном, ЦРУ и ФРС по поводу проблемы. И были приняты решения, связанные в первую очередь с соображениями госбезопасности западных стран, а не с недовольством сообщества или миллионами в кармане. И никто вам об этом сообщать не будет (а если попробует — под машину попадет например). И со стороны решения будут озвучиваться частично и выглядеть не совсем понятно.
Никто вас не допустит к реальным мотивам.
Кстати, мотивы создания экономической системы, которая вам отвратительна, я уверен — были далеки от отвратительности. Ну, возможно по-хорошему циничны.
Простая вводная — допустим в какой-то момент представители Интел и подобных совещались с Пентагоном, ЦРУ и ФРС по поводу проблемы. И были приняты решения, связанные в первую очередь с соображениями госбезопасности западных стран, а не с недовольством сообщества или миллионами в кармане. И никто вам об этом сообщать не будет (а если попробует — под машину попадет например). И со стороны решения будут озвучиваться частично и выглядеть не совсем понятно.
Никто вас не допустит к реальным мотивам.
Кстати, мотивы создания экономической системы, которая вам отвратительна, я уверен — были далеки от отвратительности. Ну, возможно по-хорошему циничны.
UFO just landed and posted this here
«Так что я имею на это право. А то, что никто не даст мне полной информации, не моя вина.» — вот поэтому существуют силовые структуры. Если начнете мешать системе, вас подавят.
Справедлива ли система?
Давайте я приведу несколько попсовых заголовков и прочего. А уж как их интерпретировать…
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 году планета погибнет от перенаселения?»
Вот какая-то хитрая штука, эта справедливость и равноправие. Если почитать каждый пункт в отдельности, то можно как-то запутаться. То ли бездушно уничтожают человечество в своих корыстных войнах; то ли заботятся о пропитании растущего населения, все поднимая и поднимая агрокультуру; то ли ни хера не заботятся о медицине — люди мрут! как мухи в руках эскулапов!!; то ли перестарались с человеколюбием и народа расплодили — не прокормишь…
Борьба за ресурсы, на самом деле, как и миллион лет до нашей эры — дело частное. Станьте миллионером-губернатором-знаменитостью и включитесь в эту борьбу! Ну… либо обсуждайте.
Справедлива ли система?
Давайте я приведу несколько попсовых заголовков и прочего. А уж как их интерпретировать…
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 году планета погибнет от перенаселения?»
Вот какая-то хитрая штука, эта справедливость и равноправие. Если почитать каждый пункт в отдельности, то можно как-то запутаться. То ли бездушно уничтожают человечество в своих корыстных войнах; то ли заботятся о пропитании растущего населения, все поднимая и поднимая агрокультуру; то ли ни хера не заботятся о медицине — люди мрут! как мухи в руках эскулапов!!; то ли перестарались с человеколюбием и народа расплодили — не прокормишь…
Борьба за ресурсы, на самом деле, как и миллион лет до нашей эры — дело частное. Станьте миллионером-губернатором-знаменитостью и включитесь в эту борьбу! Ну… либо обсуждайте.
Я что-то сомневаюсь, что любой производитель микрокодов будет раздавать их направо и налево.
По статье: можно сделать вывод, что секретность «поломал» инженер AMD? Типа «мы не знаем почему ездят танки, но в наш город революция обойдет стороной!»
По статье: можно сделать вывод, что секретность «поломал» инженер AMD? Типа «мы не знаем почему ездят танки, но в наш город революция обойдет стороной!»
1) Я очень надеюсь, что потребители процессоров и прочих электронных чипов — наконец-то сообразят, что нельзя доверять крупным корпорациям. Операционные системы с открытым кодом уже есть — теперь пора думать о процессорах с открытой архитектурой (полностью открытой — на всех уровнях, включая чертежи, где расписано расположение транзисторов на кристалле).
2) Производителям компьютеров давно пора думать над альтернативной архитектурой. Например, об архитектуре, где есть много процессоров с раздельной памятью. Понятно, что такая архитектура не ликвидирует описанные в статье проблемы полностью — но возможный ущерб хотя бы будет ограничен памятью того процессора, на котором работает зловредный код. Тогда особо секретные приложения смогут потребовать себе физическую изоляцию на отдельном процессоре в отдельной памяти.
3) Мне достаточно очевидно то, что значительная часть проблемы вызвана разделением производителей аппаратуры и операционки. Если бы аппаратуру (в т.ч. процессор собственной архитектуры) и операционку производила одна корпорация — то неразберихи было бы на порядок меньше.
UFO just landed and posted this here
1. Каким образом это поможет? Архитектура современных процессоров давно известна и, в принципе, понятна людям. Там нет никаких секретов уж прямо. Уж про спекулятивное исполнение и работу кэшей знают даже окологеймерские сайты, а всякие игровые разработчики так вообще на каждой конференции об этом рассказывают, т.к. для них очень важно понимать эти вещи. Опенсорс не решает проблем безопасности.
2. А можно сделать проще и реализовать изоляцию на уровне серверов, стоек и т.д., как это и делается собственно. У AMD есть SEV примерно для этих целей. Выдумывать что-то дальше видится как трата ресурсов на слишком нишевые фичи.
3. Неразберихи — конечно. В остальном, никаких преимуществ для индустрии в целом от этого не было бы. Вон Apple чето никак не выиграла от того факта, что iOS устройства она делает сама от и до.
2. А можно сделать проще и реализовать изоляцию на уровне серверов, стоек и т.д., как это и делается собственно. У AMD есть SEV примерно для этих целей. Выдумывать что-то дальше видится как трата ресурсов на слишком нишевые фичи.
3. Неразберихи — конечно. В остальном, никаких преимуществ для индустрии в целом от этого не было бы. Вон Apple чето никак не выиграла от того факта, что iOS устройства она делает сама от и до.
об архитектуре, где есть много процессоров с раздельной памятью.
У людей несколько чипов в одном сокете по latency проседают так, что мама не горюй, а если эти чипы еще и в разных местах на плате будут… Это прямо «верните мой 2007» получится.
Очевидно — это потому, что люди не умеют организовывать многозадачность. Например, драйверы файловой системы и жёсткого диска переходят с процессора на процессор — туда, откуда их вызывает прикладная программа; и когда разные экземпляры этих драйверов параллельно выполняются на нескольких процессорах — приходится синхронизировать их работу. А надо — организовать это дело по архитектуре типа файлового сервера и его клиентов.
И вообще, сейчас всё больше компьютеров работают в качестве аппаратного носителя множества вирт.машин. Эти вирт.машины — автономные, в синхронизации не нуждаются (а если синхронизируются — то по вирт.сети). Почему Вы против разнесения их на разные чипы — я не понимаю.
Ну и не забываем, что многие задачи не нуждаются в FPU. Запускать их на процессоре с FPU — это безумное расточительство.
UFO just landed and posted this here
Но вы конечно лучше знаете, чем разработчики популярных ОС, программ и процессоров.Совершенно очевидно, что:
1) Существующая система многозадачности — не идеальна. Т.е. — можно лучше.
2) Разработчикам важно, чтобы работало надёжно. Поэтому разработчики выбирают известные опробованные решения.
3) Разработчики не готовы делать рефакторинг, пока для этого нет серьёзных оснований. Т.е. нужно доказать, что новая система многозадачности намного лучше старой. Причём — именно доказать им.
4) Система многозадачности очень сильно завязана на многие вещи, в т.ч. на архитектуру аппаратуры и на работу других компонентов системы, вплоть до пользовательских программ (например, система многозадачности исторически недавно переделывалась под многотредовость программ). (См.ниже.)
Поэтому я реально могу знать то, что разработчики — может, знают, может, не знают, но в любом случае пока не готовы реализовывать.
Подобное есть в ОС с микроядром, но они не показывают высокой производительности- затраты на передачу сообщений между разными процессами оказываются выше, чем блокировки внутри одного.Выше в 4-м пункте я сказал о связи многозадачности с архитектурой аппаратуры. Разумеется, попытка разделения ядра на микроядра — будет неэффективна, если аппаратура заточена на монолитное ядро.
Или для Вас является новостью тот факт, что аппаратуру (в т.ч. процессор) делают под некую ожидаемую модель программ?
Микроядро — это вообще не на тему производительности. Это на тему надёжности и безопасности — а эти две вещи всегда работают против производительности.
А я агитирую не за микроядро. И т.б. не за микроядро на традиционной (на данный момент) аппаратуре.
Я агитирую за дальнейшее развитие и углубление традиций AsMP. Если на HDD есть свой процессор, выполняющий весьма сложную работу — то надо развить эту идею дальше и поручить этому процессору (или не этому, а другому) и обслуживание файловой системы.
Я надеюсь, Вы не возражаете против того, что на брюхе у HDD живёт двухядерный процессор?
Сейчас на одном сервере можно запустить как 10 относительно мощных виртуалок, так и 500 слабых. Жёсткое разделение процессоров ограничивает выбор несколькими оптимальными конфигурациями.Если я сделаю в своей архитектуре десять процессоров (возможно, многоядерных; каждый процессор с собственной памятью) (и ещё пару специализрованных — один для сети, второй для файловой системы) — то смогу запустить и десять относительно мощных виртуалок, и полтысячи слабых.
UFO just landed and posted this here
Всегда можно сделать лучше. Вопрос в том, выгодно ли это.Если рассматривать понятие «выгодно» в капиталистическом смысле — то эволюция запросто может привести человечество к экологической или какой-то другой катастрофе. У меня чёткое ощущение, что катастрофа в IT уже наступила — просто мы её не заметили. Впрочем, в космической отрасли похоже, аналогичная катастрофа.
Надёжность важна не только разработчикам, но и потребителям.Решения принимают разработчики. Но при этом они ориентируются на потребителей.
Поэтому (повторю) разработчики очень часто предпочитают проверенные временем решения — даже если есть серьёзные основания полагать, что новые решения лучше и по производительности, и по надёжности.
Про переделку про многотредовость не понял.Идея многопоточных программ стала популярной сравнительно недавно, на моей памяти. Сначала многопоточность была реализована в виде библиотеки, работавшей на уровне процесса; она не могла распараллелить потоки одного процесса по разным процессорам/ядрам и не давала работать всему процессу, если один из тредов делал блокирующий вызов в ядро. Потом многопоточность реализовали на уровне ядра — вот это и была переделка.
Конечно нет, поэтому я и написал про «разработчики популярных ОС, программ и процессоров».Беда современного IT — в том, что аппаратуру, операционку и приложения разрабатывают разные конторы. Обратите внимание: в автопроме автомобильный концерн разрабатывает автомобиль целиком (либо заказывает на аутсорсе — но по своему ТЗ).
К сожалению, в IT мало кто разрабатывает собственную экосистему. А те, кто разрабатывают — те сидят в узкой нише и даже не пытаются сделать свою платформу широко-функциональной.
Например, у меня есть один товарищ, имеющий Sony PlayStation; от него у меня вся информация по ней. Судя по его словам, Sony поступила феерически глупо (оценка — моя, от него только факты): PlayStation невозможно использовать ни для чего, кроме игр. По идее, эта железка по аппаратной мощности запросто м.б. и WWW-браузером, и текстовым редактором, и офисным пакетом (Word+Excel+etc), и даже редактировать картинки/звук/видео. Но Sony принципиально не развивает свою приставку в эту сторону.
А вот при 11 две из них будут ютится на одном кластере и дико тормозить, хотя со стороны остальных может быть запас.А давайте не менять условия задачи на ходу. Любая IT-система строится под определённый круг задач и не обязана хорошо работать при выходе за этот круг.
AMD из-за этого завозит режим отключения одного блокаЯ так понимаю, Вы не заметили слово «NUMA», хотя оно там многократно повторяется.
И опять же, я повторю: Я считаю большой ошибкой использование многоядерных чипов. Хорошо хоть на CPU не возлагают управление жёстким диском (перемещение сбойных секторов, etc), а держат для этого отдельный процессор на брюхе жёсткого диска.
Поэтому при первой возможности все стремятся к одному кристаллу и однородному доступу к памяти.Странно то, что некоторые люди предпочитают ставить отдельную видеокарту с GPU в отдельном чипе и с собственной памятью.
UFO just landed and posted this here
Всё равно не понял. Какая библиотека, какое ядро? Вы про какие годы вообще?Я об многопоточности и потоках выполнения. Год найти не удалось — но это примерно 199*-е.
Так может это связанные проблемы? Ну не может одна компания сделать всё на свете.Ну, почитайте про спектр занятий японских и южнокорейских фирм — Вас ждёт много удивительных открытий на тему того, как фирма может выпускать смартфоны и военные миномёты.
Вы это бизнесу скажите {«не менять условия задачи на ходу»}.Ой, а разве в бизнесе не принято составлять ТЗ до начала работы?
Или типа запустили сайт на 100к клиентов, и всех лишних отстреливать на балансере?По мере запуска новых клиентов — в стойку добавляются новые мощности. Или Вы знаете бизнес, который работает как-то иначе?
Любая архитектура с множеством процессоров будет страдать такой фигнёй как неравномерный доступ к памяти и к данным другого процессора.Пожалуйста, не надо соскакивать с темы. Мы обсуждает вирт.машины. Зачем вирт.машине доступ к данным другой вирт.машины? Для воровства данных? А вот нефиг!
Просто никому ещё не удалось объединить мощный ЦПУ и ГПУ на одном кристалле с раздельной памятью для каждого.Ну так и не удастся! Это стало понятно ещё в тот момент, когда память перестала успевать кормить процессор кодом и данными — так что пришлось ставить кэш-память.
А сейчас — надо перенести выполнение X-сервера на видеокарту.
И ещё надо аналогично отделить сетевую подсистему и файловую систему.
Но я против раскидывания приложений по разным ЦП.Наверно, Вы ещё и сторонник терминальной схемы — когда все приложения выполняются на одном центральном компьютере, а у юзеров только тонкие терминалы?
UFO just landed and posted this here
Хорошо. Дальше?Ну, собственно, я доказал, что система многозадачности регулярно очень серьёзно переделывается. В качестве дополнительного примера могу привести тоже относительно недавний хайп на тему того, что в 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. для файловой системы — тоже.
Если это выгодно, то почему бы и нет. Но в общем случае это лишнее.Ой, а как же Ваша любимая консолидация ресурсов? На терминальном сервере — память консолидирована, а не раскидана по отдельным компьютерам.
Современная концепция вирт.машины — это нечто феерически дебильное.
Поубавьте пыл, а то совсем смысл постов потерялся, одним эмоции. Современная концепция виртуальных машин это следствие определения этой технологии — виртуальная машина должна работать, не подозревая, что она виртуальная. Из этого следует, что никакой папки ей выделить мы не можем — ей нужен диск, который она сама разметит. То, что вам так хочется, называется контейнерами и давно существует, только не дает должного уровня изоляции, для которого придумали виртуальные машины. Вы начинаете перемешивать уровни абстракции в поисках какого-то идеала вами выдуманного, а на самом деле извращаете всю суть того, зачем это все делается.
Meltdown чётко показал, что изоляция процессов — совершенно недостаточна.
У вас явное непонимание сути уязвимости. Meltdown показал ровно одну единственную вещь и больше ничего — intel слишком вольно обходилась со своей архитектурой и нарушила гарантии, которые обязан предоставлять процессор. Никто здесь не виноват больше, ни архитектура процессоров в целом, ни тем более ПК вообще — виноват intel и его конкретная реализация. AMD реализация правильная и уязвимости этой не имеет, а значит изоляция процессов продолжает прекрасно работать и выполнять свою цель. Вас куда-то уносит с одной темы в другую, а на самом деле надо всего лишь разобраться для начала в одной.
Современная концепция виртуальных машин это следствие определения этой технологии — виртуальная машина должна работать, не подозревая, что она виртуальная.Значит, гостевой системе создают имитацию физической машины, верно? Ок, а что это за машина? Это — писюк!
А писюк (персональный компьютер) — это изначально дебильная система. Я не шучу, это реально дебильная система, построенная предельно неудобно для программистов, которые потом героически преодолевали препятствия, создаваемые аппаратурой.
Для начала надо вспомнить, что писюк имеет «родные» устройства и «неродные». Родные — это те, которые предполагались изначально (или если не изначально — то были аналогичными изначальным); ещё один признак — это наличие драйверов устройства в BIOS. Т.е. мы видим, что FDD/HDD и COM/LPT-порты — это родные устройства; а сеть и мышь — не родные.
Если бы сеть была родной — то вирт.машине можно было бы выделить папку, предоставив к ней сетевой доступ.
Я думаю, Вам надо ознакомиться с архитектурой компьютеров, созданных фирмой Acorn: Atom, B, B+, Master, Archimedes. Все они вообще не нуждались в локальном диске — т.к. операционка была записана в ПЗУ.
intel слишком вольно обходилась со своей архитектуройВы так говорите, как будто у Intel были какие-то обязательства/ограничения на тему того, что она может делать со своей архитектурой! Может, у Вас есть ссылки на нормативные документы, ограничивающие вольности корпораций — этого современного дворянства?
виноват intel и его конкретная реализацияТ.е. про то, что данная проблема есть и у ARM — Вы не слышали???
В данном случае уязвимость порождена именно разделением системы на уровни абстракции (хотя правильнее — «области абстракции»). Есть три компонента, каждый безопасен сам по себе. А втроём — они образуют дыру.
UFO just landed and posted this here
Переделываются частности реализации в угоду производительности или нового оборудования.Вообще-то, переделываются отнюдь не частности реализации. Там регулярно делается полный рефакторинг; это примерно как переход от 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 — которую я вообще не смог запустить ни в одной операционке (возможно — недостаточно сильно старался).
Вы не представляете число проблем, костылей и уступок, на которые нужно будет пойти, чтобы вынести обработку файловых систем из ядра ОС.Вообще-то, основная работа уже сделана — в виде микроядерных систем. Так что проблем — не очень много.
А главная проблема — тупые манагеры — никуда не делась и не денется.
И поверьте, это будет медленнее и будет жрать больше оперативной памяти.Больше памяти — да, пожалуй. Разделение памяти на пулы фиксированного размера всегда ведёт к понижению КПД использования памяти.
А вот по скорости — ожидается ускорени. Чисто за счёт того, что каждый пул памяти обслуживает свой процессор, и процессоры не конфликтуют за доступ к памяти.
Заодно мы избавляемся от необходимости синхронизировать кэши процессоров (если кэши процессоров раздельные) или устраним конфликты при доступе в кэш (если кэш у процессоров общий).
UFO just landed and posted this here
С появлением 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-сервер; а можно засунуть что-то другое.
Вы то как, последовательны, и используете именно такую ОС на вашем ПК?Нет, очевидно. Ведь аппаратура моего компьютера — заточена на монолитную систему.
Ещё раз повторю: «основная работа уже сделана — в виде микроядерных систем». Но сделанная работа — не является окончательным решением.
А я, неплохо знающий архитектуру ОС, ожидаю замедления. Кто же прав?Эксперимент покажет.
И часто {ли процессоры конфликтуют за доступ к памяти}?Это сильно зависит от архитектуры.
При общем «плоском» кэше — будут конфликты за доступ к кэшу.
При общем «многослойном» кэше — конфликты подавляются, но это достигается за счёт двухслойного диспетчера запросов, что увеличивает латентность.
При раздельном кэше — падает КПД использования кэша, а конфликты происходят при операциях записи в память, когда кэши надо синхронизировать.
Гланое преимущество раздельной памяти — это снижение потребности в кэшировании.
UFO just landed and posted this here
Из головы? Что поделать, я лучше знаю 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-сервер (менее универсально — потому более эффективное и безопасное решение там, где оно пригодно) не даёт доступа не только к системным областям диска, но и к системным областям базы данных (а вот древние СУБД предполагали, что клиенты сами корректно лазают в системные области базы данных — что порождало массу проблем).
И вот так же надо поступать со всеми данными, доступ к которым хочет получить много программ:
Данные коллективного доступа располагаются в какой-то памяти. В процессоре, который привязан к этой памяти (имеет туда прямой доступ), запускается программа-сервер. И все, кто хотят получить доступ к данным — обращаются к этому серверу. А сервер уже решает — осуществлять операции последовательно или выставлять блокировки.
UFO just landed and posted this here
А я не знаю, откуда вы взяли, что я утверждал {что потоки появились именно в Windows}.Как понимать фразу «С появлением NT потоки появились в их современном виде»? Вероятно, что до NT их вообще не было.
Я утверждал, что концепция потоков, появившись в первых версиях NT (не впервые, а в первых), кардинально после этого не менялась.Концепция потоков существенно поменялась с возникновением многопроцессорных и многоядерных систем.
Я не отрицаю необходимость изменений. Я уверен, что предлагаемый вами путь не есть тот, который будет реализован.Ну так я и не спорю — бизнес крайне редко выбирает оптимальные решения. Поэтому будут реализованы идеи, которые понравятся дебильным менеджерам — а им в основном нравятся дебильные идеи.
Даже не представляю, что это за процессоры {не имеют аппаратных фичей — переключать процессы, потоки и вообще что-либо}. Калькуляторы?Ну, как минимум — для принудительного переключения потока/процесса нужны аппаратные прерывания. У большинства процессоров они есть, но это не обязательная фича — вполне м.б. процессоры без прерываний.
Для работы с процессами нужна аппаратная защита памяти (страничная, сегментная или ещё какая-то). Процессоры без такой защиты — известны, хотя в наше время они практически сошли со сцены.
Но я надеюсь, Вы согласны с тем, что для принудительной многозадачности требуются аппаратные ичи?
(А вот для добровольной-кооперативной многозадачности — не требуется ничего, кроме способности выполнять программы, что требуется и для однозадачных систем.)
Смейтесь дальше.Гы, реально смешно. Вы бы хоть саму ссылку прочитали — речь о переключении контекста, а вовсе не о многозадачности. (Я в курсе, что переключение контекста — это важная часть многозадачности. Но часть — не равна целому!)
Защита через аппаратные возможности процессора вполне себе принципиальная… Была.Хорошо, я напомню второй аргумент: для микроядерных систем не работает защита через Ring Level — тот самый механизм, который является одним из трёх компонентов, сочетание которых и породило уязвимость.
Чтобы не ждать Вашего вопроса «Почему не работает???» (ожидаемо от человека, который постоянно упоминает свою высочайшую квалификацию), отвечу сразу:
Потому что защита через Ring Level работает в одну сторону. А при микроядерности надо защищать десятки компонетов друг-от-друга.
И кому это нужно {построение надёжных систем из ненадёжных компонентов}? Где нужно, это давно используется- космическая промышленность, авиация, атомная. Простому пользователю надёжная система, которая будет стоить в пять раз больше нынешних «ненадёжных», не нужна.Ну, начнём с определения слова «нужно». Ибо есть объективная нужда, а есть осознаваемая — и они не всегда сопадают.
Надёжные системы нужны всему человечеству; ну, той части, которая сильно зависит от компьютеров.
А осознанная потребность в таких системах — только у тех, кто понимает, что ущерб от ненадёжности гораздо дороже, чем пятикратная цена системы.
Но беда в том, что разрабатывают системы — одни фирмы; а эксплуатационные убытки несут совсем другие. Причём разработчики стараются экономить где только можно, и в первую очередь — на квалификации работников и на сроках разработки/тестирования. Это значит, что при повышении цены в пять раз — разработчик всё равно не станет повышать надёжность своей системы, а просто положит разницу в карман.
Ещё одна проблема в том, что разные компоненты разрабатываются разными фирмами. И за общее качество никто не отвечает.
В перечисленных Вами отраслях — методы построения надёжных систем не используются. Хотя бы потому, что если бы эти методы там использовались, что эти методы достаточно быстро портировались бы в остальные отрасли. Потому что компьютерные ехнологии очень легко портируются.
Реально же в этих отраслях используется технология построения надёжных систем — в виде дублирования компьютера простыми (даже тупыми) предохранителями, часто вообще аналоговыми. А попытки сделать компьютеры надёжными — никому не нужны.
Тогда бы их вообще никто не использовал.Это почему же? Вы так говорите, как будто решения принимаются на разумных основаниях, а не потому, что «так положено».
Кем, где, для кого?Производителями RAID-контроллеров!
Майнинг, основанных на хешах, прекрасно ложится на архитектуру ГПУ, в отличии от задач Х-сервера.Значит, надо думать в сторону изменеия архитектуры GPU.
Впрочем, это не имеет смысла, пока не поменяют архитектуру взаимодействия задачи-владельца окна с X-севрером: надо отказаться
И будет дико тормозить, так как потоки в ГПУ значительно слабее потоков ЦП.Зато их много!
Но ведь от этих систем {с отдельной памятью для этих процессоров} отказались, и не просто так.Конечно же, не просто так. А потому, что тандем Intel+MicroSoft захватил рынок — и вовсе не техническим совершенством своих решений.
Так вот, намного проще и производительнее расширить эту шину, увеличить скорость и уменьшить латентность, чем переписывать весь софт на свете под специально разработанную архитектуру процессоров.Расширить шину, говорите? Ну и куда её расширять, если и сейчас платы уже шестислойные?
Увеличить скорость? Каким же это образом?
Уменьшить латентность? Ой, Вы делаете мне смешно — её давно уже не могут уменьшить!
А зачем переписывать весь софт? Я предлагаю решение для тех систем, в которых работают изолированные процессы — ти они прекрасно распределяются по разным модулям.
Боюсь, производительность этого решения {клиент-серверной архитектуры} будет совсем унылой.Пока что унылой стала производительность общепринятой архитектуры — из-за патча против Meltdown.
UFO just landed and posted this here
маски, по которым делают процессоры. Хотя мне стало интересно, сколько будет весить такая схема, скажем, для ГПУ с миллиардом транзисторов?
Те маски, по которым изготавливают чипы (после 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
>> для ГПУ с миллиардом транзисторов?
У Nvidia GV100 — 21 миллиард транзисторов (815mm²)
У Nvidia GV100 — 21 миллиард транзисторов (815mm²)
1) Ну, я тут говорил про то, что открытыми д.б. все уровни — от верхних до нижних. Т.е. нужно открыть и задание для автогенератора(это как бы программа на языке верхнего уровня), и сгенерированную по этому заданию схему (как бы бинарный код), и маску тоже.
Сколько оно весит — я не знаю. Но на каких-то накопителях оно размещается.
3) Неразбериха — та, что описана в последнем абзаце статьи. Там явно указывают на проблему согласований между разными группами лиц, не имеющими общего начальника.
Apple использует процессоры i*86 от Intel в настольльных компьютерах и ноутбуках; и процессоры ARM в айфонах — такие же, как используются в Android-устройствах. Естественно, эти продукты затронуты общей проблемой.
Я как бы намекаю, что чем больше разнообразие продуктов — тем меньше ущерб от эпидемий (это и в сельском хозяйстве так, и в компьютерных экосистемах).
del
Меня в этой истории отдельно неприятно удивило то, как Intel и Google грубо и недальновидно работали с вендорами открытого софта и коммьюнити.
Популярные дистрибутивы Linux почему-то получили disclosures еще в ноябре, а *BSD и многие другие ничего не знали до последнего момента (Тео, как всегда, не стесняется в выражениях по этому поводу). Чуваки даже не подумали (или им было пофиг), что крупные коммиты в VM-подсистему ядра без внятного объяснения неизбежно вызовут у публики вопросы со всеми вытекающими последствиями. Чуваку из AMD разрешили (или не уследили, по факту неважно) раструбить про спекулятивные ссылки до окончания эмбарго. Вот эти все организационные фейлы едва ли не затмевают собственно главный фейл (проблемы в процессорах).
Популярные дистрибутивы Linux почему-то получили disclosures еще в ноябре, а *BSD и многие другие ничего не знали до последнего момента (Тео, как всегда, не стесняется в выражениях по этому поводу). Чуваки даже не подумали (или им было пофиг), что крупные коммиты в VM-подсистему ядра без внятного объяснения неизбежно вызовут у публики вопросы со всеми вытекающими последствиями. Чуваку из AMD разрешили (или не уследили, по факту неважно) раструбить про спекулятивные ссылки до окончания эмбарго. Вот эти все организационные фейлы едва ли не затмевают собственно главный фейл (проблемы в процессорах).
Видел информацию о том, что разработчики FreeBSD получили инфу вовремя, а с Тео произошла забавная история. Когда нашли баг в WPA2 ему сообщили о уязвимости наряду со всеми, но он раскрыл инфу о ней широкой общественности до оговоренной даты релиза. После этого случая ему сказали, что будут сообщать ему о таких уязвимостях в последний момент. Снятие эмбарго на мелтдаун планировалось на 9 января и вероятно ему бы сообщили детали уязвимости 6-7 января, но инфу разболтали раньше времени.
Не важно, было им пофиг или нет, но что вы предлагаете делать? У большинства дистрибутивов открытые исходники ядра, других вариантов не было.
Коммиты можно было скоординировать по времени, можно было заранее согласовать (не)включение KPTI (mitigation для Meltdown) с ребятами из AMD. Можно было договориться, кому и что можно, а что нельзя говорить в паблике. При желании всё можно было сделать быстро и прозрачно (запатчить ядра Linux/*BSD, выпустить официальное заявление), но было сделано как было сделано. :-(
Ситуация описывает почему невозможно достаточно долго реализовывать любую теорию заговора.
Так, исключительно с целью пофантазировать — представьте себе хаос, если когда-нибудь окажется, что факторизацию или логарифм по модулю можно за полиномиальное время решить…
Ещё один патч от Microsoft был скомпилирован и выпущен в канун Нового года, что говорит, что команда компании, вероятно, работала над ним всю ночьТак вот почему у меня 31-го вечером стала падать винда с BSOD по памяти. Кстати, вылечилось только заменой на новую планку.
Но Шварц столкнулся с ещё одной проблемой: как сохранять в секрете такую серьёзную уязвимость достаточно долго, чтобы её можно было исправить?.
Ну а почему бы и нет? Прежде всего — компании такого масштаба беспокоит репутация, оборот, продажи! Помимо этого, чипами данной компании пользуется огромное кол-во потребителей (и даже я))) и если среднестатический потребитель просто откажется от использования, то крупные компании потребуют неустойку!
«Из того, что описал программист Том Лендаки из AMD, следует, что ЦП от Intel грешат спекулятивным выполнением кода без проверок на безопасность»Отсутствие изоляции ядра. Читала.
А сайты — следствие и, возможно, маркетинговый ход, чтоб как можно большее кол-во клиентов воспользовались патчем!
Ух!.. На втором ПК у меня чип AMD! Как же хорошо, что мы не устанавливали последние обновления! Кстати, впервые до оповещения в СМИ данную информацию я нашла здесь. Вот, чем ценен ресурс! И именно благодаря ему не устанавливали обновления.
Еще раз, для тех, кто очень далек от всех этих тонкостей и нюансов. С AMD все ОК? Или нет?
тут даже уже новые фантомасы полезли skyfallattack.com
я вот что не понимаю — если об уязвимости стало известно аж в середине 2017 — то почему патчи пришлось «срочно писать» в декабре?? что они пол-года то делали? запихивали червяков обратно в банку и надеялись что само пройдёт?
Поясните. Процессор Байкал подвержен данным рискам?
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 нет за счет дополнительной проверки.
Это все классно, но я так и не понимаю чего хотят вендоры дальше. Кржанич, явно стреманулся и слил свои акции Microsoft, Intel зная об уязвимости решила выпустить поколение процессоров в которых по прежнему сохранена уязвимость, без компании с отзывом. Т.е. алчность победила, здравый смысл, я правда так не понимаю кто будет покупать их новые процессоры, но наверное от безысходности будут.
Я полагал, что все таки замена CPU должна стать основным решением а все эти заплатки должны только выиграть время для реализации главного плана. Но судя по действиям основных виновников не видно никаких намеков на решение основной проблемы — на что менять текущие CPU?
Я полагал, что все таки замена CPU должна стать основным решением а все эти заплатки должны только выиграть время для реализации главного плана. Но судя по действиям основных виновников не видно никаких намеков на решение основной проблемы — на что менять текущие CPU?
UFO just landed and posted this here
Думаю возможно. Samsung в Британии работает по схеме — платишь таксу ежемесячно и получаешь новый топовый продукт сразу после выхода, в обмен на старый. Т.е. от схемы с разовой оплатой по сути перешли на подписку. Интел тоже мог так сделать, мол вот вам устройства но мы знаем о проблеме поэтому в следующем поколении исправим и продадим в обмен на старые за пол или треть цены. Лояльность потребителей дороже стоит.
Это в очередной раз доказывает, что единственная нормальная стратегия добронамеренного ресерчера — это 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. И плевать сколько людей пострадало бы из-за действий детишек, а удар по репутации производителей уязвимых чипов от этого был бы вполне заслужен, всё-таки не исследователи создали эту уязвимость (бекдор?), главное чтобы фикс был как можно скорее, а производители наконец стали прилагать все необходимые усилия, чтобы такого не повторилось.
UFO just landed and posted this here
Sign up to leave a comment.
Как ошибку Spectre, способную сломать индустрию, держали в тайне семь месяцев