C>>>Я специально написал "volatile". Все барьеры есть. Разрешения более чем достаточно для точных таймеров.
O>>volatile барьеров не ставит.
C>Вообще-то, ставит.
Сюрприз-сюрприз:
GCC 5.4:
инкремент volatile int переменной через ++:

  400710:    8b 05 36 09 20 00        mov    0x200936(%rip),%eax        # 60104c <counter>
  400716:    83 c0 01                 add    $0x1,%eax
  400719:    89 05 2d 09 20 00        mov    %eax,0x20092d(%rip)        # 60104c <counter>
  40071f:    eb ef                    jmp    400710

инкремент volatile int переменной через __sync_add_and_fetch:

  400710:    f0 83 05 34 09 20 00 01     lock addl $0x1,0x200934(%rip)        # 60104c <counter>
  400718:    eb f6                    jmp    400710

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

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

C>Пытаться перекрыть атаки с помощью запрета точного времени в машине с разделяемой памятью — это как раз затыкание дыр. Способы взять статистически точное время будут находиться примерно постоянно.
C>Более правильным будет убирание side-channel с помощью железных мер. Типа переключаемого кэша, эксклюзивной аренды шины и т.д. Железячники уже думают.
side-channel через канал времени лучше всего убить убив этот самый канал, то есть — загрубив потенциально возможные результаты измерения времени. То что я выше предложил — только один способ. Второй может быть например "дрыгать" частоту ядер рандомом. Тут в принципе ничего особенного нету — динамическим изменением частоты никого не удивишь нынче, речь о том чтоб ее дрыгать _всегда_ и часто в целях секурности. Вплоть до рандомизации скважности тактового генератора. Решения, типа понаставлять везде в ядре LFENCE — это просто затычки в решете.

ЗЫ Есть тут у меня одна смутная ассоциация с неопределенностью Гейзенберга. Он, не случайно она захардкожена в этой Вселенной.

C>>>Я специально написал "volatile". Все барьеры есть. Разрешения более чем достаточно для точных таймеров.
O>>volatile барьеров не ставит.
C>Вообще-то, ставит.
Сюрприз-сюрприз:
GCC 5.4:
инкремент volatile int переменной через ++:

  400710:    8b 05 36 09 20 00        mov    0x200936(%rip),%eax        # 60104c <counter>
  400716:    83 c0 01                 add    $0x1,%eax
  400719:    89 05 2d 09 20 00        mov    %eax,0x20092d(%rip)        # 60104c <counter>
  40071f:    eb ef                    jmp    400710

инкремент volatile int переменной через __sync_add_and_fetch:

  400710:    f0 83 05 34 09 20 00 01     lock addl $0x1,0x200934(%rip)        # 60104c <counter>
  400718:    eb f6                    jmp    400710

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

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

C>Пытаться перекрыть атаки с помощью запрета точного времени в машине с разделяемой памятью — это как раз затыкание дыр. Способы взять статистически точное время будут находиться примерно постоянно.
C>Более правильным будет убирание side-channel с помощью железных мер. Типа переключаемого кэша, эксклюзивной аренды шины и т.д. Железячники уже думают.
side-channel через канал времени лучше всего убить убив этот самый канал, то есть — загрубив потенциально возможные результаты измерения времени. То что я выше предложил — только один способ. Второй может быть например "дрыгать" частоту ядер рандомом. Тут в принципе ничего особенного нету — динамическим изменением частоты никого не удивишь нынче, речь о том чтоб ее дрыгать _всегда_ и часто в целях секурности. Вплоть до рандомизации скважности тактового генератора. Решения, типа понаставлять везде в ядре LFENCE — это просто затычки в решете.

ЗЫ Есть тут у меня одна смутная ассоциация с неопределенностью Гейзенберга. Ох, не случайно она захардкожена в этой Вселенной.