Перейти к содержимому
Калькуляторы

ttttt

VIP
  • Публикации

    1 360
  • Зарегистрирован

  • Посещение

О ttttt

  • Звание
    Доцент

Информация

  • Пол
    Не определился
  1. Серьезный баг в архитектуре интела?

    Нельзя так, это не делает никого никаким экспертом, особенно в компьютерных архитектурах и иногда заставляет разносить всякие выдумки по форумам :) Out-of-order - это не фича, это архитектурный подход. Он не имеет никакого смысла вообще на одних регистровых данных, в нем вся суть в том, чтобы делать что-то, пока ждем данных, которые прилетят в эти самые регистры. Нацитировал, как Silvermont работает: The low-power Atom design has finally moved a major step forward after several years of only small improvements. The Silvermont processor is now a serious competitor for the ARM processors. It has limited out-of-order execution capabilities for integer instructions, but not for floating point and vector instructions. The Silvermont has five pipelines: One for memory read and write operations, two for integer operations, and two for floating point and vector operations. Most instructions generate only 1 μop from the decoders. Read-modify, and read-modify-write instructions generate a single μop from the decoders, which is later split into two or more μops for the memory and execution units. Instructions on general purpose registers can execute out of order to a limited degree. Apparently, no more than eight instructions can be pending at the same time. The same logical register can be allocated to different physical registers in order to remove false dependencies. This also applies to floating point and vector registers, even though they cannot execute out of order in the same pipeline. The memory bandwidth is one 128-bit read or write per clock cycle. The size of the branch target buffer is unknown. The prediction rate is fair. The misprediction penalty is relatively low. Indirect branches have no pattern prediction. (c) An optimization guide for assembly programmers and compiler makers By Agner Fog
  2. Серьезный баг в архитектуре интела?

    Нет, только in-order атомы не подвержены, до Silvermontа. Вы просто не разобрались с регистрами в out-of-order архитектурах: https://en.wikipedia.org/wiki/Register_renaming https://en.wikipedia.org/wiki/Re-order_buffer https://en.wikipedia.org/wiki/Tomasulo_algorithm
  3. Серьезный баг в архитектуре интела?

    Да все одинаково "недосмотрели", AMD такое же дерьмо и только из чистой случайности их процессоры не подвержены Meltdown. Вы же не думаете что у них там никто не в курсе о side channel атаках? Конечно в курсе и могли во время верификации все проблемы найти. Но зачем, Intel-AMD - это же олигополия, держат рынок пк очень крепко, и давно забили и на безопасность, и на архитектуры процессоров и просто высасывают деньги с рынка. Кто ж им что сделает. Могут десятилетиями не замечать изменившиеся потребности к безопасности. Дожились до того, что даже у госушного Эльбруса под распил лучше архитектура получилась. И уже чуть ли ни каждый студент компьютерных наук знает, как сделать лучше процессор, чем у Интела, с той самой программной спекуляцией, а не хардверной. Короче мир так устроен, что монополизация приводит к деградации.
  4. Серьезный баг в архитектуре интела?

    Говорили, говорили и опять за свое. Я же тебе выше показал пример 100% работающей программной защиты. Второе, лучшая защита может быть только программная, когда харда делающего неизвестно что спекулятивно вообще нет. Третье, очищать кэш после спекулятивного исполнения никто никогда не будет, кэши критичны для производительности. Четвертое, защиту процессов друга от друга ядра не обеспечивают в контексте Spectre, ядро только себя защищает от Spectre из юзерспейса и от Meltdown. Раз это до сих пор не понятно, то я сдаюсь.
  5. Серьезный баг в архитектуре интела?

    Архитектура от компилятора неотделима, если в компиляторе это "ручками", то и в архитектуре тоже "ручками". У VLIW архитектур, например, спекулятивное исполнение генерируется компилятором. А вот мипсовая EVA тут причем - не знаю.
  6. Серьезный баг в архитектуре интела?

    Это компилятор должен пихать или статический анализатор, о борьбе ручками со Spectre конечно можно забыть.
  7. Серьезный баг в архитектуре интела?

    Да, оно точно возможно. Это if (i < array_length) { array[ i ] ... } может спекулятивно лезть в массив по любому значению i, но если, например, заменить array[ i ] на array[ i & mask ] то спекулятивно невозможно узнать индекс по которому лезть, пока не применить маску, а после маски уже нельзя лезть куда попало. Это только один из вариантов, можно и без маски, можно использовать какой-нибудь shadow индекс, который никогда не выходит за область памяти массива.
  8. Серьезный баг в архитектуре интела?

    Ну мы сейчас говорим конкретно о bounds check bypass, который Тоша объявил, как невозможный для защиты, это Spectre 1. По нему защита основывается либо на отключении спекулятивного исполнения либо на невозможности спекулятивно выходить за область памяти объектов.
  9. Серьезный баг в архитектуре интела?

    Я не понимаю, что тебе не понятно. Компиляторы обычно знают где память выделяется, где хранятся метаданные для динамических массивов и т.д., более того эти вещи фундаментально важны для memory safety. Дальше смотри, если сторонний код не может выйти за область памяти, которую он выделяет, ни явно, ни спекулитявно, то он не может получить доступ к другой памяти процесса ни на прямую, ни через side channel timing атаки. Так понятнее?
  10. Серьезный баг в архитектуре интела?

    Ну вот зачем споришь о чем не знаешь? У тебя calloc() не может выделить память не зная размера, и этот размер в рантайме можно везде использовать, если понадобится. Есть С компиляторы c bounds checking, которые этот размер и используют. Да хотя вон даже ASAN по твоему откуда размеры берет? Не с неба же. И security through obscurity - это как раз когда прячут внутренности и объявляют, что никто не показал уязвимость. Но гарантировать отсутствие не могут, потому что прекрасно понимают, что уязвимость точно есть, никто же не заботился о side channel атаках. В общем как АМДшный пиар и делает. Концепция известна давно, как неработающая. Вообще все намного хуже с этими уязвимостями, это не конкретные уязвимости, а концепции. Они оставляют много пространства для дальнейших исследований. Еще будет интересно. Уже кто-то говорил о работе по возможным уязвимостям в in-order процессорах со спекулятивным исполнением.
  11. Серьезный баг в архитектуре интела?

    "Ошибку контроля границ" легко заткнуть, достаточно никогда не давать индексам/указателям принимать значения выходящие за пределы области памяти, в которой их разрешено использовать. Допустим если есть массив длинной 256 байт, то для него индексы могут принимать значения только от 0 до 255, что соотвествует маске 0xff. Теперь перед использованием индекса можно просто наложить на него маску (index & 0xff) и все, спекулятивное исполнение никогда не наткнется на индекс за пределами массива. Процессор о размерах не в курсе, но компилятор еще как в курсе, даже для таких языков, как С. Песочницы всегда были возможны только в отдельном процессе. А вот фича хрома с отдельными процессами на каждый сайт - не песочница и сама по себе никакой изоляции в контексте данных уязвимостей не дает. Текущая затычка в хроме - это понижение разрешения таймера и отключение фичи, через которую можно смоделировать таймер. Больше будет в хроме 64.   И еще, по Spectre 2 в память соседнего процесса можно залезть без всяких других уязвимостей, если в его коде нет защиты от этого. Типичная программа с высокой вероятностью имеет много кусков кода подходящих для этого. А, кстати, заявления амд, что никто не показал эту уязвимость на их процессорах - это на самом деле называется security through obscurity, т.е. своего рода признание, что они тоже уязвимы, вопрос времени и желания.
  12. Для начала найти все лица, но не заидентить. Идентификация лица никогда не будет точным, там не может быть алгоритма, когда на каждом кадре идентифицируется лицо с нуля, максимум - уточняется идентификация имея больше фоток конкретного лица, которое уже трекается.
  13. При чем тут алгоритм трекинга? Старые результаты по распознованию здесь: http://megaface.cs.washington.edu/KemelmacherMegaFaceCVPR16.pdf А вот блумберга сюжет о их стартапе, с интервью: https://youtu.be/tICL-lwI7KM?t=1752 Меньше секунды надо на распознование одного лица из миллионов. Следить за всеми одновременно на такой скорости хоть и невозможно, но это уже очень близко. От распознования десятка тысяч людей в час до сотен тысяч, миллиона в час - как рукой подать. Менты вдруг получат просто нереальные возможности, особенно учтя, что менты и так главные заказчики их стартапа.   Дык потому и не порог входа школьника. Нужно дохера железа, времени и экспертизы. Они вон свой кластер только чтобы хоть какие-то вменяемые результаты получить пол года тренировали.
  14. "Железный" брелок для ssh ключей

    Кстати, а что за хрень с кастомным ssh-agentом, который, судя по тексту, отделен от прошивки? Как-то это никуда не вписывается, ssh-agent должен крутиться на девайсе и быть частью той самой прошивки, и не быть никаким кастомным. Если агент ставится на комп, то это мало чем от зашифрованных ключей на флэшке отличается, ну только менее безопасно. :) Или вы там, боже упаси, еще и крипто пишите? Ну и от троянов это все не спасет, но модели нету, так что и так понятно, что не понимаете этого.
  15. "Железный" брелок для ssh ключей

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