Акела промахнулся! В смысле, Интел обосрался

[StrangerR]

...
Тогда ничего ценного на компе не хранить или вообще от компа избавится. Нет процессора - нет проблемы

Из лекции которую я читал администрации президента в России в примерно 93м году:
- нет проблем с абсолютной защитой. Делаем на раз-два-три
* взяли сервер, выключили
* положили в сейф
* закрыли дверку.
Идеально защищенный сервер.

Проблема не в защите, проблема в ДОСТУПЕ. И чем больше его требуется тем сложнее.

Слабость например AWS супротив всего этого в том, что они дают доступ ВСЕМ. И если на одном хосте встретятся хакер и банк, то не факт, что хакер до банка не доберется, через ихнюю криворукую виртуализацию. Не давали бы доступ хакеру, не было бы проблемы. Не давали бы доступ с улицы в банк, никто бы банки не грабил (наш дата центр в Канаде был в бывшем золотохранилище. В общем, там 4 человека могут неделю от партизан отстреливаться...). Ну и так далее.

(Кстати, поэтому AwS держит отделные зоны для гавермента. Без физического пересечения с народом с улицы, так сказать. )

[ALV00]

Это учитывая стоимость переноса - возможно. А так ни один дурак сегодня и смотреть не будет на такие решения если с нуля.

Интересно, а на чем бы сейчас стали делать систему, подобную Visa? При том что eventual data consistency - неприемлемо.

[ALV00]

Поправлю
Данные разумеется НЕ предоставляются. Вы что думаете, в партии дураки сидят?

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

Не по биту, а все таки по байту а то и по два. Делается так:
- Обнуляем кэш
- Делаем косвенное чтение, где чужая ячейка используется как адрес, но обращение идет к своей ячейке. (Значение попадает в кеш)
- Сканируем свою память, замеряя время чтения, и находим, по какому адресу прочиталось быстрее других. Адрес = значение чужой ячейки.
Хорошая статья на тему

[Dmitry67]

Кстати, у нас все железо обязательно меняется раз в три года

[flip_flop]

Кстати, у нас все железо обязательно меняется раз в три года

Вот! И это правильно!

[Dmitry67]

Кстати, у нас все железо обязательно меняется раз в три года

Вот! И это правильно!

Влад, а какого года у вас железо?

[flip_flop]

Кстати, у нас все железо обязательно меняется раз в три года

Вот! И это правильно!

Влад, а какого года у вас железо?

Такого обращения я не ожидал Вопрос ко мне? Или риторически я подвернулся, а вопрос таки к Владу?

Я в принципе могу ответить, но, наверное, надо таки дождаться Влада.

[mskmel]

Смех смехом, а Visa до сих пор процессирует платежи на MF. Утверждают, что это лучшее решение для их объема транзакций.

Работает - не трогай. Тем более IBM инвестирует и развивает платформу. Могу наврать, но 40% прибыли IBM всё еще делают на МФ.
У кого-то должно быть очень много денег, стальные ХХХ и серьёзные причины для того чтобы взять и переписать.
Серьёзной причиной может стать отсутствие людей которые согласны это учить, т.к. текущие специалисты уходят на пенсию.

[мухобой]

Поправлю
Данные разумеется НЕ предоставляются. Вы что думаете, в партии дураки сидят?

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

Не по биту, а все таки по байту а то и по два. Делается так:
- Обнуляем кэш
- Делаем косвенное чтение, где чужая ячейка используется как адрес, но обращение идет к своей ячейке. (Значение попадает в кеш)
- Сканируем свою память, замеряя время чтения, и находим, по какому адресу прочиталось быстрее других. Адрес = значение чужой ячейки.
Хорошая статья на тему

ещё одна
https://habrahabr.ru/post/346078/

[мухобой]

Делается так:
- Обнуляем кэш
- Делаем косвенное чтение, где чужая ячейка используется как адрес, но обращение идет к своей ячейке. (Значение попадает в кеш)
- Сканируем свою память, замеряя время чтения, и находим, по какому адресу прочиталось быстрее других. Адрес = значение чужой ячейки.
Хорошая статья на тему

Насколько я понял не совсем так, не "Адрес = значение чужой ячейки", значение найденное в массиве быстрее других, и есть искомое значение, расположенное по адресу, который мы ранее "атаковали".

Собственно, суть атаки то очень проста и достаточно красива:


Сбрасываем кэш процессора.

Code: Select all

char userspace_array[256*4096];
for (i = 0; i < 256*4096; i++) {
_mm_clflush(&userspace_array[i]);
}

Читаем интересную нам переменную из адресного пространства ядра, это вызовет исключение, но оно обработается не сразу.

Code: Select all

const char* kernel_space_ptr = 0xBAADF00D;
char tmp = *kernel_space_ptr;

Спекулятивно делаем чтение из массива, который располагается в нашем, пользовательском адресном пространстве, на основе значения переменной из пункта 2.

Code: Select all

char not_used = userspace_array[tmp * 4096];

Последовательно читаем массив и аккуратно замеряем время доступа. Все элементы, кроме одного, будут читаться медленно, а вот элемент, который соответствует значению по недоступному нам адресу — быстро, потому что он уже попал в кэш.

Code: Select all

for (i = 0; i < 256; i++) {
if (is_in_cache(userspace_array[i*4096])) {
    // Got it! *kernel_space_ptr == i
}
}

Таким образом, объектом атаки является микроархитектура процессора, и саму атаку в софте не починить.

[zVlad]

Кстати, у нас все железо обязательно меняется раз в три года

Вот! И это правильно!

Влад, а какого года у вас железо?

Походу вопрос ко мне. По разному было. И через два года меняли и через три. Сейчас у нас пятилетний контракт. Железо мэйнфрэйм лизуется, не покупается.
Последнее время популярен upgrade, когда из предыдущего карты ввода-вывода переносятся в новый. Экономия, понимаешь.

zBC12 у нас, 2013 год.

[мухобой]

Хорошая статья на тему

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

[zVlad]

Смех смехом, а Visa до сих пор процессирует платежи на MF. Утверждают, что это лучшее решение для их объема транзакций.

Работает - не трогай. Тем более IBM инвестирует и развивает платформу. Могу наврать, но 40% прибыли IBM всё еще делают на МФ.
У кого-то должно быть очень много денег, стальные ХХХ и серьёзные причины для того чтобы взять и переписать.
Серьёзной причиной может стать отсутствие людей которые согласны это учить, т.к. текущие специалисты уходят на пенсию.

Не думаю что кто-то стал бы упираться, мол не хочу учиться, если с учебой связано трудоустройство. Только с совсем тухлыми, зазомбированными мозгами можно отказываться учить мэйнфрэймы и их системы.
Кроме того последнее время много сделано такого что и учить то не надо. Программирование на Java для WAS for zOS ничем не отличается мало чем отличается от того же для Линукс. Для администрирования zOS понаписано разных gui-ев, zVM и вовсе администрируется, наверное, как и любып другие виртуальные визоры.

[mskmel]

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

Программирование на Java для WAS for zOS ничем не отличается мало чем отличается от того же для Линукс.

Вопрос не в администрировании, а в разработке софта на коболе, который скорее всего используется в Visa. Не думаю что выпускники ВУЗов горят желанием учить этот архаизм.

Когда начинается переход на Java, то не понятно зачем надо WAS в наши то дни. А если не надо WAS, то и за Z нет смысла платить, т.к. экономии на лицензиях больше нет, а производительность х86 на доллар сильно выше. То что я вижу\видел jvm грузящие тысячи ядер, т.е. сотни VMs 12vCPU\120GB.

IBM посчитали 32 IFLs ~= 240 х86. Если приложение использует 2400 ядер х86, то надо 320IFLs (столько в один Z и не влезет ведь) и где-то 24TB памяти. Стоит это будет 10ки М$, на х86 это до 1М$ влезет и даже скорее всего поместится в одну стойку с парой свитчей.

[zVlad]

.

IBM посчитали 32 IFLs ~= 240 х86. Если приложение использует 2400 ядер х86, то надо 320IFLs (столько в один Z и не влезет ведь) и где-то 24TB памяти. Стоит это будет 10ки М$, на х86 это до 1М$ влезет и даже скорее всего поместится в одну стойку с парой свитчей.

У Вас есть перед глазами приложение на х86 с 2400 ядрами?