Комментарии 44
Cтарый добрый 386 тоже «не допускает никакого спекулятивного доступа к памяти» по причине отсутствия спекулятивного выполнения как такового.
То-то и оно…
Спекулятивный доступ дает выигрышь в быстродействии. Если его нет, то получится более медленное исполнение. Вот и выбирайте… Быстро, но с уязвимостью, или медленно, но без уязвимости.
Спекулятивный доступ дает выигрышь в быстродействии. Если его нет, то получится более медленное исполнение. Вот и выбирайте… Быстро, но с уязвимостью, или медленно, но без уязвимости.
Интересно, а для эксплуатирования Meltdown на старых INTEL CPU программный код будет отличаться? Т.е. надо ли для каждого отдельного проца писать свой код или он будет одинаковый для всех INTEL CPU?
либо можно попробовать построить более простое ядро без излишних вычислительных блоков, без переупорядочивания, зато ядер побольше.
Сейчас и программисты получше научились работать с многопоточностью, и инструменты появились.
Сейчас и программисты получше научились работать с многопоточностью, и инструменты появились.
будет жуткое падение производительности.
все эти изменения порядка выполнения инструкций нужны для того, чтобы утилизировать все блоки проца. иначе каждый такт почти все мозги будут простаивать.
все эти изменения порядка выполнения инструкций нужны для того, чтобы утилизировать все блоки проца. иначе каждый такт почти все мозги будут простаивать.
тут спорный момент. В современных процессорах слишком много вычислительных блоков. И и так очень много протаивает. Если их количество уменьшить, но ядер сделать сильно больше — на этом вполне можно сыграть. Плюс — можно ввести отдельные специализированные ядра для видео, криптографии…
Конечно, софт придется переписывать, чтобы получить преимущества, а не наоборот уйти в прошлое.
Представьте себе, у вас 1000 более простых ядер, и вы даете ядра процессу в единоличное пользование. Без переключений контекста.
Конечно, софт придется переписывать, чтобы получить преимущества, а не наоборот уйти в прошлое.
Представьте себе, у вас 1000 более простых ядер, и вы даете ядра процессу в единоличное пользование. Без переключений контекста.
не все задачи паралелятся.
а если учесть, что, например на десктопе, наиболее критичен поток ГУИ, то совсем печально.
1000 ядер почти бессмыслены в прикладных задачах общего характера.
а если учесть, что, например на десктопе, наиболее критичен поток ГУИ, то совсем печально.
1000 ядер почти бессмыслены в прикладных задачах общего характера.
1. с гуи как раз все намного проще.
Там куча потоков используется просто для удобства, даже не для производительности. Отдельный поток слушает нажатия кнопок, отдельный — движения мыши. А процессор видяхи — так вообще прям создан для параллельных вычислений.
2. Наверное, не все задачи параллелятся, но вот я с ходу не смог придумать такую задачу. Все, что я встречал — это просто такая реализация. И скорее всего, ноги росли из начала 2000-х, когда даже 2-процессорные компы были редкостью.
3. А почему нет? Каждой вкладке браузера можно выдать даже не по одному потоку. Отдельно для гуи, отдельно для бизнес-логики. И это, кстати, может уменьшить латенси. А то, если честно, напрягает, когда набираешь код в idea, а на экране все появляется где-то через секунду. И у меня не дохлый комп. core i7, 16 гб. памяти, ssd.
Там куча потоков используется просто для удобства, даже не для производительности. Отдельный поток слушает нажатия кнопок, отдельный — движения мыши. А процессор видяхи — так вообще прям создан для параллельных вычислений.
2. Наверное, не все задачи параллелятся, но вот я с ходу не смог придумать такую задачу. Все, что я встречал — это просто такая реализация. И скорее всего, ноги росли из начала 2000-х, когда даже 2-процессорные компы были редкостью.
3. А почему нет? Каждой вкладке браузера можно выдать даже не по одному потоку. Отдельно для гуи, отдельно для бизнес-логики. И это, кстати, может уменьшить латенси. А то, если честно, напрягает, когда набираешь код в idea, а на экране все появляется где-то через секунду. И у меня не дохлый комп. core i7, 16 гб. памяти, ssd.
по поводу латенси, кстати, надо вспомнить, что потоки сами по себе добавляют тормозов в виде накладных расходов на переключение контекста.
а непаралелятся все задачи итерационной природы, если нежен полный результат в следующей итерации. таких много
а непаралелятся все задачи итерационной природы, если нежен полный результат в следующей итерации. таких много
да, добавляют. Потому, что потоков сильно больше, чем ядер.
да, я знаю. Но в реальности в голову приходит только какая-нибудь глупость, вроде синуса от синуса от… А на практике часто оказывается, что мат. модель можно изменить, например, сделать ее ассоциативной.
Либо, если результат дискретный — можно попытаться сделать иммитацию тех же спекулятивных вычислений, вроде вычисления на других ядрах наиболее вероятных результатов вычисления предыдущей операции с последующим отбрасыванием того, что не угадал.
да, я знаю. Но в реальности в голову приходит только какая-нибудь глупость, вроде синуса от синуса от… А на практике часто оказывается, что мат. модель можно изменить, например, сделать ее ассоциативной.
Либо, если результат дискретный — можно попытаться сделать иммитацию тех же спекулятивных вычислений, вроде вычисления на других ядрах наиболее вероятных результатов вычисления предыдущей операции с последующим отбрасыванием того, что не угадал.
Безопасность линукса часто объясняют простотой исправлений и обновлений, доступных каждому, а открытые исходники ставят в пример как возможность исследования на предмет ошибок для их последующего исправления.
А как исправлять баги процессора, которые благодаря открытым исходника будет искать значительно проще, чем в процессорах с закрытым описанием?
А как исправлять баги процессора, которые благодаря открытым исходника будет искать значительно проще, чем в процессорах с закрытым описанием?
А как исправлять баги процессора, которые благодаря открытым исходника будет искать значительно проще, чем в процессорах с закрытым описанием?
Если бы Specter/Meltdown наши скажем ещё в 4 пне, то возможно он бы уже давно был исправлен, но его нашли(ну по крайней мере официально) не так давно, в итоге куча чипов да ещё и разных архитиктур оказалась забагована(интересно они что друг у друга покупают модули, или вообще у треттих фирм).
А зачем их исправлять. Напечатал новые процессоры, а старые — выбросил продал врагу. В конце концов, если будут открытые исходники, то неразумно покупать только у одного вендора процессоров — их надо печатать по необходимости, — желательно, самостоятельно.
А в чем тогда принципиальная разница между процессорами с открытым и закрытым описанием?
И было бы очень интересно посмотреть на самостоятельное изготовление процессора.
И было бы очень интересно посмотреть на самостоятельное изготовление процессора.
на таком техпроцессе дома/вгараже — нереально.
а вот всякие ПЛИС… но тоже сомнительный вариант.
было бы интересно если бы в проце был небольшой кусочек плиса. наверное.
а вот всякие ПЛИС… но тоже сомнительный вариант.
было бы интересно если бы в проце был небольшой кусочек плиса. наверное.
Чтобы прошить ПЛИС — нужно иметь рабочую систему, а это либо держать два компьютера, либо усложнять (а значит, увеличивать количество критических элементов) само устройство компьютера.
К тому же ПЛИС, которые могут содержать в себе полноценный процессор, стоят как минимум на порядок дороже процессора. Дешевле регулярно покупать исправленную версию серийного производства.
А на счет «иметь кусочек ПЛИСа в процессоре» — в некотором смысле, микрокод именно эту функцию и выполняет.
К тому же ПЛИС, которые могут содержать в себе полноценный процессор, стоят как минимум на порядок дороже процессора. Дешевле регулярно покупать исправленную версию серийного производства.
А на счет «иметь кусочек ПЛИСа в процессоре» — в некотором смысле, микрокод именно эту функцию и выполняет.
Чтобы печатать — нужны технологии, а «самостоятельно» для печати на приличном уровне есть не так много вариантов. Да и «печать по необходимости» кратно увеличивает цену — будет у вас i386 по цене i3.
Подобного рода уязвимости — это далеко не так страшно, как бекдоры от анб
Еще ядро MIPS забыли.
Вроде бы открытые исходники для академических нужд.
Правда, что-то мне не верится, что открытые исходники процессора, кто-то сможет реально смотреть/исправлять/вести отладку.
Понятно, что openRISC или MIPS можно попробовать в FPGA. А вот аналог Core i7 ни в какой FPGA не поместится.
Вроде бы открытые исходники для академических нужд.
Правда, что-то мне не верится, что открытые исходники процессора, кто-то сможет реально смотреть/исправлять/вести отладку.
Понятно, что openRISC или MIPS можно попробовать в FPGA. А вот аналог Core i7 ни в какой FPGA не поместится.
Понятно, что openRISC или MIPS можно попробовать в FPGA. А вот аналог Core i7 ни в какой FPGA не поместится.
Можно ведь просимулировать, да это медленно но возможно.
Ха. Конечно, можно просимулировать, но это будет не медленно, а ОЧЕНЬ медленно. Сравните сотни килогерц для симуляции (число взято с потолка, так как я точно не знаю частоты), десятки мегагерц на FPGA и гигагерцы в реальных камнях. Эффективнее оказывается моделировать процессор на нескольких FPGA, каким-то образом объединённых в одно устройство, и дебажить логику так.
FPGA избыточна потому что переконфигурируемв. А значит если на ней можно уместить какой-то процессор — значит процессор с такими характеристиками можно сделать дешевле, потому что грубее тех процесс, меньше элементов, меньше площадь кристалла или за ту же стоимость — сделать процессор с тем же тех процессом, количеством элементов и площадью — но с существенно лучшими характеристиками. Разумеется при условии достаточно массового тиража такого процессора, а при тираже больше тиража FPGA — он ещё и дешевле выйдет, потому как затраты на R&D по большему числу экземпляров размажутся.
Ну, "открытые исходники для академических нужд" — это всё-таки не "свободные процессоры" и для разработки своего процессора, наверное, далеко не лучший вариант. Хотя, с точки зрения анализа это, конечно, намного лучше, чем ничего.
А я не понял, каким образом будет происходить обновление тех же процессоров, если будет найдена уязвимость?
В софте уязвимости устраняются и пользователи просто обновляют ПО, а с процессором просто так не обновишься, и в итоге будешь и без обновлений сидеть, и с кучей открытых уязвимостей
В софте уязвимости устраняются и пользователи просто обновляют ПО, а с процессором просто так не обновишься, и в итоге будешь и без обновлений сидеть, и с кучей открытых уязвимостей
Во первых в процессоре бывает микрокод, равно как и софтовые заплатки могут помочь.
Во вторых, речь идёт о том, что в открытой системе серьёзные баги не будут жить годами и поколениями.
Во вторых, речь идёт о том, что в открытой системе серьёзные баги не будут жить годами и поколениями.
И кто их будет искать?
Баги десятилетиями живут в линуксе.
Баги десятилетиями живут в линуксе.
я про хардварные баги, которых найдут к примеру 20 штук в новеньком процессоре тысяч за 40, и единственным решением будет покупка нового, а если не купишь — то уязвим для всех атак, все хаскеры знают как тебя сломать.
Имхо в таком случае лучше и баги пусть не находят, и все закрыто будет, чем каждый раз новый камень покупать.
Имхо в таком случае лучше и баги пусть не находят, и все закрыто будет, чем каждый раз новый камень покупать.
А ещё как я понимаю открытая система предполагает отсутствие лицензионных отчислений, следовательно такой процессор должен стоить дешевле. Так что при обнаружении и последующем устранении уязвимости просто покупается новый процессор.
Достаём прушу, катушку чистогокремния, диаметром 1.75 и печатаем новый процессор.
Ну или идем к другу у которого струйник может на кремниевой болванке допечатать недостающие транзисторы, для устранения уязвимости.
В крайнем случе идем в ларёк покупаем чистую кремниевую болванку, а лучше пачку, и печатаем полупроводниковыми чернилами новый процессор.
Всё как раньше, только вместо оптических болванок — процессорные.
Ну или идем к другу у которого струйник может на кремниевой болванке допечатать недостающие транзисторы, для устранения уязвимости.
В крайнем случе идем в ларёк покупаем чистую кремниевую болванку, а лучше пачку, и печатаем полупроводниковыми чернилами новый процессор.
Всё как раньше, только вместо оптических болванок — процессорные.
Как мне кажется, стоит вспомнить heartbleed в openssl. Код, открытый сообществу, все равно содержал уязвимость. Прежде всего, уязвимость — это баг, такой же баг, как и все остальное. И баги будут всегда, хоть в закрытом, хоть в открытом проекте, хоть в коде, хоть где-либо ещё.
Зато в открытом коде меньше/нет закладок.
А вот в железе… Ха!
А где гарантия, что в милли(-онах/-ардах) транзисторов нет аппаратной закладки, которая хитро рассредоточена по всей площади? (Ладно, это и в софте может быть)
А где гарантия, что тот кристалл, который вы купили в магазине, сделан по той же схеме, что вы нашли в интернете? (В софте бывает, но его можно пересобрать, а вот 10нм принтер микросхем есть не у каждого дома)
В общем, open hardware — хорошо, но…
А где гарантия, что в милли(-онах/-ардах) транзисторов нет аппаратной закладки, которая хитро рассредоточена по всей площади? (Ладно, это и в софте может быть)
А где гарантия, что тот кристалл, который вы купили в магазине, сделан по той же схеме, что вы нашли в интернете? (В софте бывает, но его можно пересобрать, а вот 10нм принтер микросхем есть не у каждого дома)
В общем, open hardware — хорошо, но…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пришло время для открытых и свободных процессоров?