Вобщем да, можно. Но все равно какой-то он кривой, а параметр expected — по сути костыль. Например, мест, в которых оно может упасть с сообщением «assertion failed» может быть много, и мы проверяем, что упало в любом из них, а не в конкретном.
Кстати, #[should_panic] в нормальных тестах лучше не применять — обычно когда ты хочешь панику, то хочется. чтобы она была в определенной строке, а #[should_panic] подразумевает панику в любой строке, что для тестов не является приемлемым.
ладно, спасибо за инфу. Реально это чтобы знать точно, нужно в исходниках копаться, а на это нет времени. Я если этот вопрос когда-нибудь изучу — то отпишу сюда.
спасибо. «for transaction lists [1,2,3,4,5,6] and [1,2,3,4,5,6,5,6] (where 5 and 6 are repeated) result in the same root hash A (because the hash of both of (F) and (F,F) is C).»
Я правда непонимаю почему хеши от (F) и (F,F) одинаковые, но если исходить из того, что это работает именно так, то с выводами согласен.
Картинки красивые, и гуглом находятся красивые — но что если количество листьев не 2^x? Например, как будет выглядеть дерево, если у нас 5 блоков, и что будет менятся при добавлении 6,7,8 блоков? Насколько я понял, будут использоваться дубликаты ключей, но при добавлении нового листа, хеши придется пересчитать и это инвалидирует предыдущий root.
ну то есть вся энергия вырабатываемая в мире в 5 раз больше той, что вырабатывается на газу. Следовательно, 420тераватт — это в ~20 раз больше, чем вырабатывается во всем мире.
420 тераватт, говорите?
Давайте так, будем считать, что датацентры работают 24х7, следовательно, если 420 серверами потреблялось бы столькотераватт, то в год потреблялось бы 3679200 тераватт-часов. Мировое потребление газа ~3500млрд м^3.
1 куб газа при сгорании выделяет 9...10кВт*ч (если верить гуглу). Округлим до 10.
Дла производства 3679*10^12 кВт*ч понадобится 367*10^12 кубов газа,
или 367000 млрд кубов. Это на 2 порядка выше мирового потребления газа.
Не похоже, что 420 тераватт — сколь-нибудь близкая к реальности цифра.
Нет доказательств. И я не соображу, как это поменять хотя бы примерно. Строго говоря, я тоже не привел доказательств.
Сотни тактов — это я слышал, что из памяти. А если из соседнего L0 — то может и быстрей (там, где L3 общий)
Смотря для чего и что надо.
У атомарных счетчиков — барьеры «под капотом».
Где-то у Шипилева была статья про исследование поведения при помощи jcstress, и там было наглядно показано, что можно нарваться на баги. Эти баги неособо частые, но они есть. И я тогда крутил эти тесты на своем амд — эти баги были.
Но тут с вами я согласен: поскольку мы говорим про взлом, то некоторое кол-во некорректных результатов нас устроит. Если 1 раз из 1000 происходит глюк — это не ок для «обычного» софта, для банковского — вообще смерть, а для задач взлома систем — нормально, даже если 1 раз из 1000 все сработает как хочется :).
Так что, пожалуй, что да. Загрублять rdtsc — не способ.
В том то и дело, что несовсем: мы же на микроархитектурном уровне. Несколько ядер на одну память? Как вы себе это представляете? L0, L1 у каждого ядра — свой. L2 — иногда общий, и то не всегда (Xeon Clovertown E5345). Можете lstopo попробовать (под линуксом). Можно в гугл вбить — и включить картинки, и посмотреть, как вообще бывает. Там иногда такое, что даже не представляю что это.
А теперь представьте себе: из L0 одного ядра нужно число переправить в L0 другого ядра. Это сотни тактов, и этот эффект больше, чем то, что мы хотим измерять. И это надо сделать так, чтобы не повлиять на кэш, потому что момент, в который мы это все меряем — очень «нежный». Любая подтяжка в кэш сама по себе уже повлияет на результат.
И это еще не все. Команды исполняются на конвеере. Там еще есть всякие буферы валидации и прочие оптимизации. То, что придет в соседний проц, если не использовать барьеры памяти, может весьма слабо отражать значение реального счетчика.
Во-первых, один атомарный инкремент
Атомарные операции выполняются с барьерами памяти. Ну ок, можно мои рассуждения выше про конвеер убрать. Но барьеры не отменят остального.
N раз провести атаку
Это приходится делать даже с rdtscp. В том коде они это делают 999 раз — и то не всегда помогает. Другие процессы сильно влияют. Счетчик в другом потоке — гораздо более грубый источник времени, а его получение — гораздо более дорогое, чем тот эффект, который измеряется.
Без понятия. Возможно, то, что написано по ссылке, соответствует реальному положению дел. Но на моем phenom b40 уязвимость есть.
Да и то, что они написали — «Resolved by software / OS updates to be made available by system vendors and manufacturers» — это же отмазка! Хочется же, чтобы и баз был закрыт — и производительность не падала. А патчи существенно снижают производительность (уже есть статья про это), повышают энергопотребление и тепловыделение.
Как из одного потока в другой передать этот счетчик?
И вообще, что такое «счетчик» и что такое «поток» если мы говорим о микроархитектуре?
Время переключения потоков (которые потоки операционки) — десятки микросекунд. Это гораздо больше времени чтения, пускай даже и из кэша, и само по себе связано с уходом исполнения в ядро.
Если под понятием «поток» вы подразумевали нечто, что выполняется вторым ядром — то как передавать этот счетчик из второго ядра в первое ядро, еще и ненарушив кэш? Для таких вещей есть барьеры памяти, но они влияют на кэш. По сути передача данных между ядрами — через L3 (хотя это от архитектуры может зависеть) Думаю, там не померяешь так просто такой короткий интервал времени…
Процентов на 30 просядет производительность.
Меня бы больше устроило, если бы команды rdtsc, rdtscp перевели в разряд привелегированных, или совсем отключили, или повысили гранулярность. Для большинства пользователей это будет ок. Нет часов с хорошей гранулярностью — нет проблемы. Как быстры фикс это — ок.
И вообще, пускай юзают hpet.
интел не устойчив к обеим типам
амд не устойчив только к spectre
Но почему-то народное внимание акцентировано на интелах и meltdown, а амд в головах людей «надежны». Думаю, не последнюю роль тут сыграли маркетологи амд.
На самом деле, это означает, что уязвимость есть везде. Я еще не разбирался с meltdown, но навскидку уязвимости весьма похожи. По сути, это 1 тип уязвимости, просто мы meltdown-это вид в фас, а spectre — вид в профиль. И основная уязвимость — та, которой подвержены обе фирмы, то есть spectre.
Я правда непонимаю почему хеши от (F) и (F,F) одинаковые, но если исходить из того, что это работает именно так, то с выводами согласен.
Давайте так, будем считать, что датацентры работают 24х7, следовательно, если 420 серверами потреблялось бы столькотераватт, то в год потреблялось бы 3679200 тераватт-часов. Мировое потребление газа ~3500млрд м^3.
1 куб газа при сгорании выделяет 9...10кВт*ч (если верить гуглу). Округлим до 10.
Дла производства 3679*10^12 кВт*ч понадобится 367*10^12 кубов газа,
или 367000 млрд кубов. Это на 2 порядка выше мирового потребления газа.
Не похоже, что 420 тераватт — сколь-нибудь близкая к реальности цифра.
О таких вещах нужно просить перед тем, как публикуешь ссылку, иначе просьба не поможет. Я вот прочитал ее уже после того, как зашел на сайт.
Сотни тактов — это я слышал, что из памяти. А если из соседнего L0 — то может и быстрей (там, где L3 общий)
У атомарных счетчиков — барьеры «под капотом».
Где-то у Шипилева была статья про исследование поведения при помощи jcstress, и там было наглядно показано, что можно нарваться на баги. Эти баги неособо частые, но они есть. И я тогда крутил эти тесты на своем амд — эти баги были.
Но тут с вами я согласен: поскольку мы говорим про взлом, то некоторое кол-во некорректных результатов нас устроит. Если 1 раз из 1000 происходит глюк — это не ок для «обычного» софта, для банковского — вообще смерть, а для задач взлома систем — нормально, даже если 1 раз из 1000 все сработает как хочется :).
Так что, пожалуй, что да. Загрублять rdtsc — не способ.
В том то и дело, что несовсем: мы же на микроархитектурном уровне. Несколько ядер на одну память? Как вы себе это представляете? L0, L1 у каждого ядра — свой. L2 — иногда общий, и то не всегда (Xeon Clovertown E5345). Можете lstopo попробовать (под линуксом). Можно в гугл вбить — и включить картинки, и посмотреть, как вообще бывает. Там иногда такое, что даже не представляю что это.
А теперь представьте себе: из L0 одного ядра нужно число переправить в L0 другого ядра. Это сотни тактов, и этот эффект больше, чем то, что мы хотим измерять. И это надо сделать так, чтобы не повлиять на кэш, потому что момент, в который мы это все меряем — очень «нежный». Любая подтяжка в кэш сама по себе уже повлияет на результат.
И это еще не все. Команды исполняются на конвеере. Там еще есть всякие буферы валидации и прочие оптимизации. То, что придет в соседний проц, если не использовать барьеры памяти, может весьма слабо отражать значение реального счетчика.
Атомарные операции выполняются с барьерами памяти. Ну ок, можно мои рассуждения выше про конвеер убрать. Но барьеры не отменят остального.
Это приходится делать даже с rdtscp. В том коде они это делают 999 раз — и то не всегда помогает. Другие процессы сильно влияют. Счетчик в другом потоке — гораздо более грубый источник времени, а его получение — гораздо более дорогое, чем тот эффект, который измеряется.
Да и то, что они написали — «Resolved by software / OS updates to be made available by system vendors and manufacturers» — это же отмазка! Хочется же, чтобы и баз был закрыт — и производительность не падала. А патчи существенно снижают производительность (уже есть статья про это), повышают энергопотребление и тепловыделение.
И вообще, что такое «счетчик» и что такое «поток» если мы говорим о микроархитектуре?
Время переключения потоков (которые потоки операционки) — десятки микросекунд. Это гораздо больше времени чтения, пускай даже и из кэша, и само по себе связано с уходом исполнения в ядро.
Если под понятием «поток» вы подразумевали нечто, что выполняется вторым ядром — то как передавать этот счетчик из второго ядра в первое ядро, еще и ненарушив кэш? Для таких вещей есть барьеры памяти, но они влияют на кэш. По сути передача данных между ядрами — через L3 (хотя это от архитектуры может зависеть) Думаю, там не померяешь так просто такой короткий интервал времени…
Меня бы больше устроило, если бы команды rdtsc, rdtscp перевели в разряд привелегированных, или совсем отключили, или повысили гранулярность. Для большинства пользователей это будет ок. Нет часов с хорошей гранулярностью — нет проблемы. Как быстры фикс это — ок.
И вообще, пускай юзают hpet.
интел не устойчив к обеим типам
амд не устойчив только к spectre
Но почему-то народное внимание акцентировано на интелах и meltdown, а амд в головах людей «надежны». Думаю, не последнюю роль тут сыграли маркетологи амд.
На самом деле, это означает, что уязвимость есть везде. Я еще не разбирался с meltdown, но навскидку уязвимости весьма похожи. По сути, это 1 тип уязвимости, просто мы meltdown-это вид в фас, а spectre — вид в профиль. И основная уязвимость — та, которой подвержены обе фирмы, то есть spectre.