Компания AMD опубликовала отчёт с анализом безопасности технологии оптимизации PSF (Predictive Store Forwarding), реализованной в процессорах серии Zen 3. В ходе исследования теоретически подтверждена применимость к технологии PSF метода атаки Spectre-STL (Spectre-v4), выявленного в мае 2018 года, но на практике способных привести к атаке шаблонов кода пока не найдено и общая опасность оценена как незначительная...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54890
RISC-V приди да порядок наведи, и заодно составь конкуренцию этой дырявой x86_64.
Как будто у RISC-V не будет кеша и предсказаний ветвлений...
Там не будет исследователей безопасности. На x86 их несколько десятилетий не было.
Маховик раскрутился, теперь исследователи аппаратной безопасности будут всюду для любой, более-менне засветившейся архитектуры.
Любой устоявшейся архитектуры. Драфты все еще никому не нужны.
Только x86 довольно закрытая технология, а RISC открытая. Так что исследователи безопасности там есть уже, зато и сообщить о проблеме можно на береге (и там же исправить) и с большой вероятностью исправить можно прямо в лодке (во время налаженной линии производства), а не как в интеле - несколько лет проектируют, полгода выводят на рынок, опа проблема, ну в следующем процессоре мы ничего править не будем, вот через поколение что-нибудь посмотрим.
> Так что исследователи безопасности там есть ужеНу да, сами зобесплатно зоводяцо и чекают и репортят неистово.
>Как будто у RISC-V не будет кеша и предсказаний ветвлений...Желающие на RISC-V могут один из этих блоков отключиь или сильно поменять его работу.
> Как будто у RISC-V не будет кеша и предсказаний ветвлений...Где-то будет, где-то нет. От разработчиков ядра зависит. В non-OoO этих проблем нет как категории, например. Это же и ARM'ов касается.
> В non-OoOВ первом Atom так было, ни проблем, ни производительности :D
Эпикфэйл атома состоял в том что при этом не было ни простоты системы, ни экономичности. А без этого подобное сочетание уже нахрен не уперлось, пардон муа. Поэтому этот крап на мобильных девайсах и не взлетел, несмотря на бредни интелья таблетпцом уже чуть не 2 десятка лет и потуги приплачивать OEM-ам.Как ARM, только хреновее по всем мыслимым аспектам - не жизнеспособно.
Только вот современные тем мобильным атомам армы были совсем грустными и по производительности, и по энергопотреблению.
Некоторых армов таки касается.
Не хочу RISC-V-приди, хочу OpenPOWER-приди!
Только, если все, кому не лень, начнут клепать эту архитектуру. А то цены на продукцию IBMHat не для среднего пользователя.
Spectre-компашке подвержен далеко не только х86, ведь проблема в концепции спекулятивного выполнения вообще, а не каких-то конкретных х86 приколах
Проблема спекулятива бы решилась, если бы при отмене неудачного исполнения, также и из кеша удалялись бы оставленные неудачным исполнением данные.
Эх, вас бы, дорогие смузихлебы, да в зазработчики процессоров, вы бы точно показли всем как на...угробили бы цивилизацию в надежде что у любой проблемы есть простое решение, особенно, если рассматривать ее как гвоздь.Процессор, к сожалению, не знает, какие именно данные надо удалить. Кэш прозрачен - данные подгружаются туда при чтении их из медленной памяти. Выполнять команды задом-наперед, чтобы удалить то что они прочитали, процессор тоже не умеет, и лишнего обратного пайплайна у него для этого не предусмотрено.
о том и речь, нормальной архитектуры у интела не было с 8080 и i432, только непредусмотренные хаки, открывающие доступ ко всем ресурсам, для компетентных "товарисчей" из разведок, и вагон уникальных неиспользуемых команд, а теперь и для MachLearninG.
> Эх, вас бы, дорогие смузихлебы, да в зазработчики процессоров,Накаркаешь! Вон chisel - вообще какая-то неведома хрень на яве, и сам яваобразный. А, да, на этом RISCV написан и выхлоп этой вундервафли таки можно на фабу отгрузить...
> Выполнять команды задом-наперед, чтобы удалить то что они прочитали, процессор тоже не умеет
Вообще-то OoO примерно это и пытается делать с переменным успехом. В этом весь пойнт. Так можно за такт более 1 команды сжевать, если прокатило. Ессно это не всегда и не везде прокатывает, но если ты обратишь внимание, про очень нагло юзают это в скоростных алгоритмах.
А вот в Эльбрусе никакого спекулятивного выполнения не надо. Там все это решается на уровне компиляции. Вообще свойственно всем VLIW архитектурам
На уровне компиляции никакое предсказание ветвлений ты не сделаешь никогда.
Да и прочие низкоуровневые оптимизации многие так же не зайдут. Префетчи надо руками делать. И т.п.
Одна из очень весомых причин того, почему VLIW мёртв.
> На уровне компиляции никакое предсказание ветвлений ты не сделаешь никогда.Откуда это следует? Глядя на то как GCC вообще лихо выпиливает половину функции, _доказав_ что он никогда не вызывается с этими параметрами _глобальным анализом программы_ у меня есть здоровый скепсис насчет этого тезиса, как минимум в таком его виде.
> Да и прочие низкоуровневые оптимизации многие так же не зайдут.
Откуда сие следует? И что такого может железо что не может софт? В каком месте возникает отличие?
> Префетчи надо руками делать. И т.п.
А какие принципиальные проблемы для компилера это сделать?
> Одна из очень весомых причин того, почему VLIW мёртв.
То что никто это не накодил != тому что это _невозможно_. Просто VLIW'ам как-то не повезло в этой вселенной, в том числе по линии проприетарской жабы, когда все зажимали свои "улучшения" этсамого. Ну и дозажимались.
Предсказание ветвления по определению подразумевает, что оно работает на runtime-данных. То, чего GCC никогда не наанализирует. Скажем, если у тебя одна переменная установлена в рантайме в True (например, опция) - и в цикле if по ней всегда идёт по этой ветке. В рантайме предсказатель ветвлений увидит, что бранч тут всегда идёт по одной ветке и будет это предсказывать, давая буст для каждой следующей итерации. А GCC такое никогда не соптимизирует, потому что опция по определению может быть как True, так и False. И компилятор _никогда_ не сможет доказать, что ты в рантайме программы жмякнешь (или не жмякнешь) какой-нибудь checkbox в программе и этот кейс нужно соптимизировать. Более того - если ты захочешь отключить эту опцию - предсказатель ветвлений перестроится, и начнёт предсказывать уже ветку else. Как ты такое будешь на этапе компиляции оптимизировать, гений?)))
Ну можно сгенерировать 2-3-100 разные эффективные ветки на этапе компиляции, исходя из разных предположений, и ужэ между ними переключаться в рантайме. Разницы размера особой не будет. Кроме того, можно проанализировать, что скорее всего там true, поскольку при false количество и характер связанной логики отличается, и использовать её как предпочтительную (или же использовать указание программиста о likely). AoT именно так и работает.
Не, ну, это был достаточно простой пример. В теории да, можно сгенерить два цикла и переходить в одну или другую версию цикла в зависимости от значения переменной. А если значение переменной может меняться в цикле? А если таких if'ов в цикле много? А если условие намного сложнее чем просто True/False? Генерировать по 1000 версий одного и того же цикла? Быстро закончится место на диске, да и многогигабайтные бинарники таскать неудобно.
likely/unlikely, к слову - это всего лишь хинт для оптимизации первой итерации, и программист всего лишь просит таким образом подгрузить наиболее вероятную по его мнению ветку. Тем не менее, это имеет смысл только для реально тяжёлых веток + когда точно известно, что в большинстве случаев хинт будет верным (например, если итераций много и likely будет исполняться для всех итераций, кроме последней), ведь если запрефетчить неправильную ветку и потом окажется, что мы наступили на маловероятную ветку - придётся сбрасывать то, что мы закэшировали в CPU, а это дорогая операция.Тем не менее - likely/unlikely никак не противоречит предсказанию ветвлений, и даже наоборот - дополняет систему branch prediction процессора. Поскольку после первой итерации цикла в дело вступает уже предсказатель ветвлений процессора.
> Предсказание ветвления по определению подразумевает, что оно работает на runtime-данных.И это компилеры нынче тоже таки умеют, PGO как раз о чем-то таком.
> предсказатель ветвлений увидит, что бранч тут всегда идёт по одной ветке
> и будет это предсказывать, давая буст для каждой следующей итерации. А
> GCC такое никогда не соптимизирует, потому что опция по определению может
> быть как True, так и False.Ему в ряде случаев можно и захинтить likely/unlikely, равно как оптимизировать можно более популярный у юзерей code path.
> checkbox в программе и этот кейс нужно соптимизировать.
В принципе некий пойнт в этом есть. Но даже так - хинтят likely/unlikely.
> Более того - если ты захочешь отключить эту опцию - предсказатель ветвлений перестроится, и
> начнёт предсказывать уже ветку else. Как ты такое будешь на этапе
> компиляции оптимизировать, гений?)))Два варианта code path, отптимизнутые каждый на свой вариант? Да, это может раздуть код.
Два варианта по каждому ветвлению?
Это не просто раздует код. Это раздует его в 2^N раз, где N - число последовательных ветвлений.
Короче удачи бороться с ветряными мельницами :D
> Откуда это следует?Оттуда, что реальные данные известны только в рантайме.
> То что никто это не накодил != тому что это _невозможно_
Это невозможно потому, что у тебя нет конкретных входных данных на момент компиляции.
И не будет.
И как же это процы неплохо-себе работают, а проги - исполняются, ведь заранее неизвестно, какие данные в ту прогу будут вводиться :)
Даже если никаких ветвлений предсказываться не будет, код как работал, так работать и будет, просто в рамках отдельно взятой архитектуры и ее реализации работать будет медленней.Вы пытаетесь рассуждать об Эльбрусах аккурат как об х86_только_без_блока_предсказания_ветвлений( от которого у интела уже мозги кипят, этот блок занимает дофига места на кристалле, жрет немало энергии, притом, при каждом выполнении программы с одним и тем же набором данных ).
Да только Эльбрус - это совсем не х86. Настолько, что даже арм - и тот к х86 ближе.И оптимизации да возможности там упираются далеко не только и не столько исключительно в управление ветвлениями( хотя и это тоже ), сколько в максимальном распараллеливании ака распределении нагрузки по всем ядрам, иначе часть ядер "забивается" НОП-ами.
Да, там наверняка есть волшебные руны, позволяющие входные данные, которые одним ногтем вобьёт секретарша, предсказать ещё на этапе компиляции.Инфа 100%.
А кто-то говорил, что код _не будет_ работать без branch prediction?С Эльбрусом проблема как раз в этом. Это звучит офигенно на бумажке. Сейчас выкинем блок предсказания ветвлений, жрёт много энергии, напишем дофига умный компилятор и вынесем все оптимизации из железа в софт (круто же - можно чинить в софте то, что на Интеле требует замены железа) и сделаем много простых и дешёвых ядер, которые можно будет разом нагружать работой одним VLIW-словом и хорошо параллелизовать код.
Только воз и ныне там. На практике оказывается, что нифига это нетривиально - раскидать вычисления в программе, чтобы эффективно забить VLIW-ядра. Хотя бы стабильно выше 50%. Зависимости по данным - они повсюду. А эффективно жонглировать инструкциями и оптимально нагрузить VLIW-процессор - это NP-hard задача. Вот и получается, что есть чудесная и во всех смыслах офигенная архитектура. Без больших и жрущих блоков предсказания ветвлений. Но, к сожалению, в отличие от блока предсказания ветвлений (который реально ускоряет код) - набумажечные преимущества VLIW на практике оказываются его недостатками. Ибо как задумано - это не работает.
Как видим, кроме риально-ускорения-кода в комплекте шло еще over 9000 подстав......по поводу чего идея забить на эту оверинженерию и накопипастить побольше ядер каждое из которых попроще и делать софт heavily threaded уже не смотрится бредом. Это конечно не ускорит единичный поток, но обычно узкие места это всякое крипто, кодеки и т.п. алгоритмика и проч, которые так то довольно неплохо параллелятся.
Любая программа оперирует данными во время выполнения. Ничто не мешает компилятору, видя, что где-то дальше переменная будет использоваться для условного перехода, при присвоения этой переменной значения, сгенерить код предсказания ветвлений и инициировать спекулятивное чтение, в зависимости от значения полученного переменной. Достаточно, чтобы были в наличии свободные блоки CPU, которые могут этим заниматься в параллель основному потоку.
Причем у компилятора в этом случае возможностей намного больше, чем у процессора.
Разница в том, что CPU сам предсказывает ветвления и инициирует спекулятивное чтение руководствуясь одной и той же микропрограммой на все случаи жизни, тогда как компилятор VLIW формирует аналогичную микропрограмму, но уже оптимизированную для конкретного случая.Другое дело, что из-за этого сложность VLIW компилятора возрастает существенно. И для тех же Эльбрусов существующие компиляторы используют потенциал VLIW, не намного больше, чем на половину. Там еще огромный простор для математики и разработки. С неведомыми перспективами.
Разница в том, что CPU делает это в процессе работы.
А любая попытка реализовать это программно - особенно префетч - сожрёт драгоценные такты и линейки кеша.
Более того, если мы говорим об одном проце фиксированной конфигурации - это ещё более-менее реализуемо, пусть даже и полностью неэффективно. Когда у нас появляются вариации (напомнить, сколько вариаций того же x86 за последние хотя бы 5 лет сменилось?) - хардкод оптимизаций будет промахиваться ещё и по ним. Вся прелесть рантайм-оптимизаций в том, что проц "знает" собственную структуру и "имеющиеся на руках" данные и адреса в каждый момент времени.
> А любая попытка реализовать это программно - особенно префетч - сожрёт драгоценные
> такты и линейки кеша.В честь чего, если общением память-кеш в обоих случаях занимается отдельный блок CPU? Просто в одной случае он делает это по фиксированной в CPU микропрограмме, а в случае VLIW - по пользовательской.
> Более того, если мы говорим об одном проце фиксированной конфигурации
Отчасти Вы правы, дополнительные сложности появляются. Но если окончательную компиляцию в VLIW производить уже при установке программного обеспечения из того же LLVM/CLR, то эта проблема решаема.
> А вот в Эльбрусе никакого спекулятивного выполнения не надо. Там все это решается на уровне компиляции. Вообще свойственно всем VLIW архитектурамОпыт Титаника никого ничему не учит. Ну что же, дойдите и вы до того же тупика, в который пришли Intel с HP 10 лет назад.
Как это всё уже надоело. Там вроде у интела сейчас уже меньше оверхэд от заплаток, чем у амд без заплаток.
Оверхед на переключение контекста у интелей сейчас такой, что mitigations=off почти безальтернативно.
Ну и в новых моделях после затычки мылдауна работа с памятью похреновела до общих уровней, необычно низкой latency старых новые модели похвастаться уже не могут.
На похорониксе вон сравнили последние камни, в итоге 2% у интела и 4% у амд. Так что твоё безальтернативно выглядит очень странно.
Сравнили в чём?
В одной операционке с одним приложением?
Переключения контекста становятся критичны например в массовой виртуализации - там оверхед легко доходит до 1/3.
подтверждаю, как началась это вакханалия с патчами на уязвимости - винда в vmware стала заметно медленее отзываться чем раньше.
И да, про 2% ты звездишь, потому что в том же фурри у них на 11900k вылезло аж 16% даже в такой же конфигурации - только от спектра. Потому что там тредов чуть более одного, и тормоза контекст свитча начинают себя проявлять.
Важно то, что у амд он в 2 раза выше.
Важно то, что ты звездишь.
> Важно то, что ты звездишь.Я только упомянул о результатах похороникса, из того что тестировал лично я, с заплатками один и тот же код исполняется быстрее чем без них. IO я не сравнивал -- там были серьёзные проблемы с aes-ni, которые сейчас нашли. Вот из-за них были сильные просадки. Раз их нашли только сейчас, значит, они не стоит и важны.
Надо безальтернативно переходить на ARM. Что на десктопе что на серверах.
_Безальтернанивно_ переходить на что бы ни было, не следует. А то это _безальтернативно_ начнёт забивать на безопасность.
Кстати, да. Если в мире будет 150 архитектур и 500 дистрибутивов линукса для них, безопасность существенно подрастёт. Удобство - не очень.
> Кстати, да. Если в мире будет 150 архитектур и 500 дистрибутивов линукса
> для них, безопасность существенно подрастёт. Удобство - не очень.Удобство и безопасность живут по разную сторону улицы.
Переходите, кто мешает.
А нам и на x86 неплохо.
На рабочем десктопе перешел без вопросов. RPi4 с 8 гигами оперативки прекрасно работает в качестве десктопа для работы.
А вот на игровом фиг перейдешь, увы. Для игр держу на Ryzen 5 3600, фиг ли делать
> На рабочем десктопе перешел без вопросов. RPi4 с 8 гигами оперативки прекрасно
> работает в качестве десктопа для работы.
> На рабочем десктопе перешел без вопросов. RPi4 с 8 гигами оперативки прекрасно работает в качестве десктопа для работы.Это слишком смешно.
Хотя, конечно, какая работа...
И чего смешного?
Хватает за глаза и уши, в чем проблема? Ну понятно, что у тебя работы нет, а комп мамкин, но не у всех так.
> И чего смешного?Всё смешно - везде проблемы.
8 ГБ уже кое как лезет для разработки.
CPU слишком слаб, инфраструктура меньше. Железо тоже - конечно можно затолкать, но смысла около нуля - тем более, что самый слабый будет компактный компьютер будет по сходной цене и явно не хуже.
Да он такой умный что ему и 2ух вкладок в браузере хватает
Ага, в прошлый вой, когда только нашли первую дырку в Интолле тоже были голоса что мол "а вот ARM\MIPS не подвержены такому в принципе", но где-то через месяц появились осторожные такие анонсы, что возможно все не так безоблачно и подобные дырки вполне допустимы и на MIPS\ARM. Они эту тему не педалировали, конечно, ибо зачем отказываться от такой бесплатной рекламы, но было.
множество arm cpu уязвимы
https://developer.arm.com/support/arm-security-updates/specu...Атакам подвержены такие популярные ядра, как Cortex-A57, A72 или A9 (наряду с менее
распространёнными A8, A15, A17, A73 и A75, а также R7 и R8)
А нехрен топовые ништяки хватать, переросткам всегда достается, проверено динозаврами. Какому-нибудь A53 на пару ггц все это до балды и если не борзеть то он и как десктоп катит.
A9 на годы древнее, чем А53
> A9 на годы древнее, чем А53И чего? А какой-нибудь A7 например примерно ровесник ему - но этим скорее всего не страдает, будучи lite версией in-order ядра.
Принципиальная граница водораздела - OoO vs non-OoO ядра. In-order ядра медленее, экономичнее, компактнее, и - не имеют большей части проблем спекулятивных переростков. И A53 хоть и 64-битный и даже на пару ггц бывает, но IIRC - in-order, в отличие от более жирных и топовых.
Если нет спекуляций, то и undo side effects просто ... не требуется. И не может быть забагован. Этой абстракции просто нет, так что она не может быть неидеальной.
non-OoO нормально будет только при коротком конвейере, но тогда нужны выше частоты. Возвращаемся к тому, от чего уходили.
> non-OoO нормально будет только при коротком конвейере, но тогда нужны выше частоты.
> Возвращаемся к тому, от чего уходили.Ну так вон RISCV на 4 ГГц ядро жрало 0.2 ватта, а на 5 - около 1 ватта. При таком соотношении их можно эвон сколько даже в мелкий чипак набить без перегрева, а чип в сумме сможет в весьма непозорную производительность. При том даже единичный тред не в таком уж заду из-за высокочастотности.
И еще это на порадок проще и предсказуемее чем все эти предсказатели бранчей и спекулянты, которых судя по сабжу стоит отправить к динозаврам. За то что слишком большие и страшные.
[i]нормально будет только при коротком конвейере[/i] - с чего бы? Ставят где надо в конвеере bypass и всё нормально как-то.
OoO для того и делали, чтобы заполнять его полностью каждый такт. У ARM с его выровненными опкодами да, больше шансов уложить, но x86 с его неоднородными инструкциями можно забыть об этом. Отличный пример плохой реализации длинного конвейера - prescot, там даже OoO не помог.
[i]У ARM с его выровненными опкодами да, больше шансов уложить[/i] - в mips тоже условно говоря нормально. скорее всего и в risc-v всё будет нормально.в целом если смотреть куда-то в произвольную область, то обычно задержка возникает во время кэш промаха и конвеер колом встает на нужде результата доступа к памяти. если есть хорошего размера кэш, то обычно всё-таки беды нет.
в целом многие вещи можно запросить prefetch, чтобы когда понадобится, чтобы уже было, что нужно.
[i]prescot[/i] - плохо помню те времена.
Ненадо пожалуйста.
Только одна заплатка на интеле дает -40% производительности на CPU, можно довести до -%95 для всего IO, если безопасность важна. Поэтому интел только для игр, даже для браузера нельзя, потому что киберкотлетку могут ломануть черес ссылку на WASM.
Отключите WASM, делов-то. Все равно пока что его никто реально не использует.
Вангую появление Java скрипта для атаки на процессоры AMD Zen 3 через браузеры как это было c интелом. Гугл недавно показывал пример такой атаки.
Для начала разберись чем Java от JavaScript отличается, а уже потом школоло-вангуй.
Saltykoff'а и Щедрина на вас нет.
> Java скриптаЯ конечно все понимаю, но тут русс.... рунглишом черным по белому это и написано. Взрослые дядьки читать разучились?
>> Java скрипта
> Я конечно все понимаю, но тут русс.... рунглишом черным по белому это
> и написано. Взрослые дядьки читать разучились?Microмягкий, Redшляпа, New и Йорк, Город Angels. Нормально выглядит?
Ну что ж, посидим ещё десяток лет на Магни-курсе. А там - глядишь - и светлое будущее настанет.
Купи новый ноутбук, который мощнее твоего старого, но извини: поставь заплатку и пользуйся как своим старым.
Так не ставь заплатку и пользуйся как новым.
Но не ходи в Инет, не запускай софт с закрытым кодом.
ИЧСХ не настолько безумная мера, насколько может на первый взгляд показаться.
Сильно нужон ваш этот инторнет. Гугловщина да великий клоудвол, нету там ничего.
про скотосети забыли
Так не покупаю новый ноутбук. Маркетолухи тебя просто разводят на бабки, как хомячка!
Не, разве что, из-за возможности получить больше памяти.
/ННичего у Интела не проседает. Вы все врете. На АМД же мне до лампочки, проседает там или нет. Держу в курсе.
Сообществу давно пора понять - чтобы секретные данные не утекли, надо не кровати двигать, а алгоритмы их обработки менять.Причем подобная ситуация уже много раз возникала в прошлом. И много раз успешно решалась.
Например, нельзя хранить пароли юзеров в БД на сервере - они всегда могут утечь. Надо хранить хеши паролей и тогда при возможной утечке ваш пароль все равно никто не получит, ведь подбирать его брутфорсом на электроэнергию денег не хватит.
Но нет, все никак не успокоятся. Пускают к себе на машину чужой недоверенный код через браузер и бугуртят, что он открытые пароли/карточки/домашнюю порнуху ворует.
Тут новости из реального мира подвезли: Представляешь что доступ компьютеру только после диплома института пока не ввели. А пользователь без образования он и данные имеет и по сайтам любить лазить, а уж сколько он кода запускает и подумать страшно. И данные в первую очередь утекают у тех кто думает что они в полной безопасности.
Так я об этом и говорю.Поэтому всякий банковский софт, анонимайзеры, и что там еще, программисты должны писать так, чтобы он не содержал всякие свои чувствительные данные открытым текстом.
Пользователь - не программист. Он не пишет себе браузер, он не пишет себе клиент-банк, он не пишет себе, в конце концов, блокнот для записей кто ему что должен и как на самом деле зовут знакомого хакера ДаркВася.
Если ты пишешь для начальства плохой код, тебя никогда не уволят, риторика что больше в нём никто не разберётся.Если ты пишешь код с уязвимостями, ты всегда сможешь отомстить начальству, если тебя таки уволили.
>Надо хранить хеши паролейСразу видно человека, ничего не понимающего в безопасности. Не пароли надо хранить, а публичные ключи.
Это детали, сути его слов это не меняет. Не нужно надеяться на то, что прокатит, или на обсфуркацию, нужно стремиться делать с расчетом на то, что данные могут утечь.
Если он сальсой20/20 похеширует пароль на клиенте и отдаст на сервер - это и будет хешем от пароля.Не придирайся к словам.
>Надо хранить хеши паролей и тогда при возможной утечке ваш пароль все равно никто не получитВообще то, пароли из хешей вполне успешно восстанавливаются, если это не какой то зубодробительный пароль из хаотично выбранных символов A-Za-z0-9!@#$%^&*()_-=+\|/:;'"{}[],.? и длиной не менее 12 символов. Всё остальное легко сбручивается одной видеокартой за разумное время. И пароли в стиле Pa$$worD9 совершенно не помогают, потому, что методы формирования таких паролей хакерам известны и число возможны комбинаций сильно меньше, чем у хаотичных символов.
В доверенном ПО тоже бывают дыры и без работающей изоляции нельзя доверять любым данным из не подконтрольной Вам сети или данным с носителя к которому мог получить доступ не доверенный человек. Доверенный человек вполне может сам занести в подконтрольную сеть червя по своей глупости. И эта проблема не решается вообще, несмотря на то, что происходило это не один раз. Просто цена безопасности слишком высока и ей в таких случаях принято жертвовать ради удобства или большей привлекательности продукта.
Цена безопасности высока для конкретной комбинации абсолютно не безопасных технологий продвигаемых в публичное пользование уже 30 лет.А тот аноним выше правильно пишет, подход нужно менять.
Но это сделать в больших масштабах да в разрез с интересами государств и корпораций видимо невозможно.
Кстати кто знает, если открытые пароли просто в файле в папке zip зашифрованный, этого хватит для безопасности?
Смотря каким алгоритмом зашифрован zip-файл ...Я бы использовал 7z зашифрованный.
Или зашифровал бы с помощью gnupg2.
> Кстати кто знает, если открытые пароли просто в файле в папке zip
> зашифрованный, этого хватит для безопасности?Если там дефолтный старый зиповский метод - не хватит, он достаточно хилый. Если более новые - прокатит. Но это смотреть надо. В общем правильно вам 7z советуют, его крякать на редкость печально...
Чую, рано Itamiumы дропнули, будет VLIW-реннесанс. Эльбрус, не про*** шанс.
Где-то в недрах https://riscv.org/ попадалось, что ISA RISC-V может быть внедрена и во VLIW.
Сам по себе набор команд ничего не говорит о реализации бэкэнда его выполняюшего. Возможны разные реализации. А простой набор команд способствует простоте реализации этого самого. Если кто захочет толкать сие сразу блоками по эн по шине - оно вроде этому не мешает особо.Вопрос правда в том не будет ли проще накопипастить ядер и прогрузить шину до тех же величин менее похабными с точки зрения програмизма методами?
Принципиальная разница между вливом и суперскаляром в том, на ком ответсвенность за распараллеливоние на уровне инструкций: на процессоре или на компилятореОтсюда и основые плюсы и минусы:
1)Влив железо проще, компилятор - сложнее. Но нужно перекомпилировать под каждую архитектуру, если тайминги поменялись, для наилучшего результата.
2)Суперскаляр - сложное железо, много ест энергии, но перекомпиляция не так критичнаМожно в RISCV добавить расширение, которое введёт инструкцию, разделяющая поток инструкций на бандлы и это будет хинтом для процессора, что этот бандл не имеет зависимостей внутри, а для остальных процов это будет nop
Есть 3 вариант, когда между железом и системой компилятор встраивают, чтобы объеденить плюсы обоих архитектур, но комерчески успешных, как я знаю вариантов нет. Кроме Эльбруса, кхе кхе
Ну вот, а то интел да интел. Амудэ само дырявое как бы не хлеще, просто журналы себе купило ручные, чтобы интел гнобили.
По сравнению с мелтдауном, который _реально_ позволяет читать что попало, это так - детский лепет.
У амудэ багов раз так в пять меньше. По поводу чего и импакт от фиксов сильно скромнее. Вот так quality control и приоритеты вендоров и выплыли наружу.
Ну, ну да.Вот для владельцев AMD выкатили патч, отвечающий за вкл/выкл отдельной фигни. Можно выключить, можно ничего не трогать, уязвимость потенциальная.
А вот я, владелец Intel, должен либо весь обклеиться заплатками, просаживающими производительность, либо вписывать в параметры загрузки ядра километр опций, отключающий патчи безопасности с этими заплатками.
Совсем одно и тоже.
Забавная логика: заплатка для AMD - ХОРОШО!, заплатка для intel - помногите, я не многу омклеиться замплатками...
Потому, что уязвимостей, причём не потенциальных, и, соотвественно, заплаток для Intel много. Потому что из-за них проседает производительность.
grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && echo "patched :)" || echo "unpatched :("
CONFIG_PAGE_TABLE_ISOLATION=y
patched :)Почему у меня Хасвел не тормозит? У вас точно Интел???)
Так были тесты, что сэндик - тормозит, хасвелл - уже так себе, а скайлейку вообще без разницы. Вангую, он на i5-2500 до сих пор сидит.
подскажите начиная с какой версии ядра появились первые заплатки от мельдония, спектрума и прочих спекуляций для интела?
4.15 и был бэкпортирован в 4.14.11, 4.9.75, and 4.4.110
По моему единственный выход тут - вводить теневые линии кэша, по аналогии с теневыми регистрами. Чтобы спекулятивно исполняемый код мог быть связан со спекулятивными линиями кэша.
Ты готов за это платить?
А ничего что кэш занимает изрядно площади на кристалле? Вам как, ополовинить кэш за ваши бабки или чип подороже сделать за дополнительную цену? :)
> А ничего что кэш занимает изрядно площади на кристалле? Вам как, ополовинить
> кэш за ваши бабки или чип подороже сделать за дополнительную цену?
> :)Даже L1? Там килобайты же...
> Даже L1? Там килобайты же...Килобайты - но таки сверхскоростного SRAM с обвесом, способного работать на полной частоте проца. Это критичный и жручий кусок. И это, осевшее в L2 или где там, тоже по таймингам весьма измеирмо отличается от DRAM. У DRAM как такового латенси зверская по меркам проца. Настоящие про скоростных алгоритмов делают удобно всей этой механике, если кто не понял, а не просто "пишут программу".
Кэши по возможности максимизируют покуда это не нагибает какие-то другие параметры типа площади и потребления. Shadowing делаеть это непрактичным, половина бюджета просто идет псу под хвост. Вы получаете заметно более хреновый чип при прочих равных. И если это ок, может, проще было накопипастить кучку in-order ядер, просто не имеющих такой проблемы как категории? Это чего доброго оптимальнее окажется чем половину кешей жирноядра подарить под костыль.
Хитронахлобученое ядро приходится терпеть, когда оно единственное. Технологии созрели для нескольких десятков ядер чуть проще. Но не совсем примитивных, для этого есть отдельные видяхи и прочие DSP.
> Хитронахлобученое ядро приходится терпеть, когда оно единственное.Это вообще где такое сейчас практикуется? Современные 1-ядерные системы ща в основном всякая эмбедовака и проч и там хитрое ядро как раз нафиг никому не надо.
> Технологии созрели для нескольких десятков ядер чуть проще. Но не совсем примитивных, для
> этого есть отдельные видяхи и прочие DSP.Их прогать - весьма отдельная канитель.
К сожалению Настоящие Программисты на сишечке органично неспособно программировать многоядерные архитектуры.
Тогда хотя бы добавлять битовые поля для индикации с какими спекулятивными потоками связана линия. Если при сбрасывании спекулятивного потока команд откажется, что линия не связана ни с чем - очищать её.
Тут по идее значимого замедления не будет, спекулятивные вычисления и так жрут кэш, если ветка, что в итоге будет отброшена уводит выполнение в другую область памяти.
Ну или комбинировать. Я не спец по проектированию процессоров, но тот факт, что размер L1 радикально не увеличился со времён первопней, говорит о том, что бутылочное горлышко там не в площади и энергопотреблении, а в управлении сами кэшем. Чем больше у вас линий в кэше, тем больше операций уходит на проверку что запрос в память попадает в кэшированные данные.
>вводить теневые линии кэша, по аналогии с теневыми регистрами. Чтобы спекулятивно исполняемый код мог быть связан со спекулятивными линиями кэша.А как быть, если спекуляция оказалась в попад? Как, в таком случае, быстро перенести результат спекуляции в основной кеш?
> А как быть, если спекуляция оказалась в попад? Как, в таком случае,
> быстро перенести результат спекуляции в основной кеш?Так же как с регистрами. Что оказалось в потоке удачной спекуляции коммутируется в белое, остальное уходит в тень.
Нахер линии, когда можно обойтись несколькими битами в теге?
> Нахер линии, когда можно обойтись несколькими битами в теге?Затем что спекуляция уменьшает эффективный размер кэша. Допустим на некотором jxx код расходится. Одна ветка читает из одной области памяти, другая из другой. Процессор спекулятивно выполняет обе, загружая данные для каждой из них в свою линию кэша. Затем он отбрасывает ненужную ветку и теперь чтобы избежать всяких спектров должен сбросить и спекулятивную линию. Когда она загрузилась там были какие-то данные, которые могут пригодится позже. Теперь их нет. И того, что было загружено - нет. Получается размер кэша как бы стал меньше.
А у меня AMD FX :P
> А у меня AMD FX :PХорошо квартиру обогревает?
>> А у меня AMD FX :P
> Хорошо квартиру обогревает?Лучше покупных рукогреек! https://picua.org/image/pZ6uLk
Харашо шо БП голдовый xD
Интересно, сколько камень проживёт на 1,58 В.
> Интересно, сколько камень проживёт на 1,58 В.32 нм SOI техпроцес + среднебюджетная СВО за 2 года показали шо долго.
А так то 1,58 В выставляет Load Line Calibration в максимальной нагрузке, но тем не более 1,5 В на загруженых ядрах у меня давно и без последствий.
Тоже FX, больше 50 градусов не бывает. Это ж не Интел.
Вместо PSF лучше-бы отключили PSP.
Ещё лучше, позволили бы туда заливать пользовательскую прошивку. Наприме, из Coreboot.
Может тебе еще и мастерключ Management Engine дать прописывать, вместо интеля? А как тогда ощущать себя богами и карать тебя внезапной молнией и прочим DRM'ом с небес на твою бошку?!
Да, и мастер-ключ тоже.
> Да, и мастер-ключ тоже.В ряде ARM так даже можно.
AMD, спасибо за честное признание проблемы.
Ждём Мишу, с заявлением, что у него на Эльбрусе такого нет.
И скромно молчащего, чего там генерит закрытый LCC.
Не получается загуглить LCC, можно полное название? Интересно просто что это за штуковина
Не знаю, как аббревиатура раскрывается. Это штатный набор компиляторов архитектуры Эльбрус.
> Не получается загуглить LCCДока не этот проц тоже не гуглится, и вообще, там NDA при покупке ;)
На Эльбрусе есть как спекулятивный, так и предикативный режимы исполнения веток. Но решение о возможности наличия таких веток делается не run-time на стороне CPU, а build-time на уровне компилятора и при необходимости управляется программистом (например, можно запретить полуспекулятивный режим или отлючить спекулятивный режим вовсе). Читайте официальный учебник МЦСТ по Эльбрусам и руководство по разработке (оба публично доступны). Ну и делайте выводы сами.
Занятно читать как два противоборствующих лагеря студентов и школьников (благо выходные) AMD и INTEL сруться между собой, как будто эти две компании завтра им выпишут пожизненные ежемесячные стипендии. Но это не только на этом сайте, это везде так))...
> срутьсяА вы к которому лагерю примкнули?
Я с попкорном в роли зрителя, читателя.. как угодно.. Человек читающий новости, скажем так)). Мне глубоко плевать на мнение этих "экспертов", т.к. в разное время были процессоры и от Intel и от AMD , и те и другие со своими задачами справлялись более чем. Тестить на взрывоустойчивость процессор разными тестировщиками, проверять силу тяги на взлет в космос "киберпанком" и "метро" , мерять температуру в комнате при выключенных батареях не собираюсь - вышел с детского возраста, да и не занимался таким никогда.
"проверять силу тяги на взлет в космос "киберпанком"" и - это логично, игры больше к GPU требовательны чем к процессору.
А как же "процессор раскрывающий возможности видеокарты"(с)?
Этим вашим GPU не покомпиляешь, тут CPU однозначно.
> Я с попкорном в роли зрителя, читателя.. как угодно.В роли чукчи, который не читатель. "Cруться", блин. Это вообще какой падеж по вашему?!
Своим ответом ты подтверждаешь что ты либо школьник, либо студент. Взрослый человек, имеющий как минимум семью, не станет отвечать в подобном русле.
> Своим ответом ты подтверждаешь что ты либо школьник, либо студент. Взрослый
> человек, имеющий как минимум семью, не станет отвечать в подобном русле.ИМХО, взрослому человеку должно быть стыдно так лажаться. Хотя возможно это старческий маразм, тогда простительно, конечно (после зобана, чтоб не выражовывался).
Ты про мягкий знак в слове "сруться"? О , Господи ! Во-первых, не падежи, а "на какой вопрос отвечает"... во-вторых, ну очепятался, поставил мягкий знак, но видно что ты как раз проходишь падежи в школе, раз обращаешь на это внимание. В-третьих, какое отношение имеет правописание к теме данной статьи? Хороших оценок тебе в дневнике и подарков от родителей!))
Есть мнение, что это не столько очепятка, сколько безграмотность напополам с выпендрёжем. Пациент уже стал определять возраст и семейное положение по комментариям, что характерно.
И тут Остапа понесло..Иди уже уроки учи "эксперт IT". Нельзя ли просто прочитать новость и для себя решить подходит мне это или нет?! Обязательно всем пытаться доказать что твое мнение о том или ином процессоре самое правильное?
>> сруться
> А вы к которому лагерю примкнули?Судя по мягкому знаку - к лагерю грамматических партизан...
Ну наконец-то! А то уже прям неловко себя чувствовал счастливым обладателем AMD :)
А ничего, что у них там целая проприетарная закрытая ОС в биосе крутится?
Прямо как в интелах? А, нет, подождите, в интелах целых две ОС! Я боюсь представить, что там в ARM. В общем выкидываем все процессоры и переходим обратно на калькуляторы.
Вы путаете BIOS и PSP. Либо вы называете вполне обычную (и заменимую) реализацию UEFI операционной системой.
> Вы путаете BIOS и PSP.А у них фирмвари в 1 флешке обычно...
> Либо вы называете вполне обычную (и заменимую)
> реализацию UEFI операционной системой.Особенно хорошо оно "заменимое" у интеля с прописаным бутгадом.
BIOS (не UEFI). Ничего не крутится. Учи матчасть.
> BIOS ... Ничего не крутится.Какой ты наивный. Сразу видно, ты никогда даже не слышал о протоколах перехвата у биоса управления железом.
> перехвата у биоса управления железом.ME и PSP до 3.14-ы на эти протоколы, это вообше отдельные процы с отдельным кодом side by side c вашим кодом, там вообще похрен что вы на основном проце запустили и что оно делает :). Умеючи DMA в основную память можно вон оттуда вас пропатчить вдоль и поперек, если мутный проприетарный блоб так захотел.
А у интеля вообще оно очень интересно сделано, когда ME даже в сеть может по отдельному data path в обход основного проца и операционки, так что зафайрволить сие - агащаз.
Разработка Aries Embedded PolarFire SoC FPGA Module уже завершена. Продаётся за 395 €.
> Разработка Aries Embedded PolarFire SoC FPGA Module уже завершена. Продаётся за 395 €.Что сие за вундервафля? Жирная FPGA'шка на платке?
ПЛИС на базе RISC-V среднего уровня, обеспечивающая низкое энергопотребление, тепловую эффективность и безопасность встраиваемых систем.
Кто там говорил, что когда в AMD найдут подобную уязвимость - тогда и поговорим? Ну, начинаейте оправдываться :) А я говорил, что компьютеры - один большой костыль и шерето. Что интел, что амуде хороши.
> Кто там говорил, что когда в AMD найдут подобную уязвимость - тогда и поговорим?Информация про Meltdown и Spectre появилась в январе 2018 года. И о том, что Spectre есть в AMD (и некоторых процессорах ARM) было известно сразу же. Только Spectre труднее в эксплуатации, чем Meltdown, поэтому степень опасности объявлена малозначительной.
Проблема не в процессорах, а в современном вебе, где победила концепция скачивания и запуска непонятного кода, без участия пользователя.
И эту проблему решать не собираются.
Нет, просто в Web Development стало слишком много дегенератов.Нормальные сайты работали и продолжают работать без JS.
>Нормальные сайтыСписок в студию
У каждого он свой.
> Список в студиюНу, вот, сабж. Хотя существуюшую новость подредактивровать без JS уже не дает, падло. Ну, не очень то и хотелось...
RUST
https://rust-lang.github.io/rustup/installation/index.html
"""
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- --default-toolchain none -y
"""Haskell
https://www.haskell.org/ghcup/
"""
curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org | sh
"""
>Наводку на новость прислал Artem S. TashkinovНу прямо гебешные формулировки.
https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi?az=l...
AMD неуязвима, Intel pешето, говорили они.
ну кто бы мог подумать