Здравствуйте, ononim, Вы писали:

O>инкремент volatile int переменной через __sync_add_and_fetch:
Ну хорошо, пусть будет явный барьер в виде инструкции. Смысл не меняется.

C>>И с барьером тоже будет всё нормально. Максимум придётся статистику посчитать.
O>Удачи ее считать если у тебя разрешение таймера будет хуже необходимой разницы. Кроме того, есть стойкое подозрение что использование memory-barrier'а в цикле просто убьет саму атаку на корню.
Я могу повторять пробу много раз, так что статистически даже намного менее точный таймер будет достаточен.

C>>Кроме времени исполнения есть ещё потребление питания, занятость шины памяти, прямые пробы на DRAM contention и т.д.
O>Нене. Все это требует физического подключения логическим анализатором. Сценарии атак нужно разделять. Мы тут про атаку когда хакер может запускать свой код на машине и не более того.
Не требует, кроме питания. Остальное можно косвенно обнаружить.

C>>Более правильным будет убирание side-channel с помощью железных мер. Типа переключаемого кэша, эксклюзивной аренды шины и т.д. Железячники уже думают.
O>side-channel через канал времени лучше всего убить убив этот самый канал, то есть — загрубив потенциально возможные результаты измерения времени.
Это невозможно. Проще перейти на in-order выполнение, да и быстрее оно будет, чем 100500 затычек.