История изменений

Исправление uin, 05.12.18 00:22 (текущая версия) :

Ну этот не будет а вот этот вот будет:

char a1[10]="0123456789";
char secret[10]="secret";
char* a2;

char func(int offset)
{
   if (offset<10)
      a2[a1[offset]*64];
}

Т.е. При вызове функции с передачей ей аргумента в виде числа он спекулятивно загрузит a2[a1[offset]*64]; еще до того как проверит условие (ну хорошо, в интеле загрузит, а в эльбрусе компилятор просто поставит ее самой первой). Но в защищенном режиме это ничего не даст потому что строго контролируются границы чего откуда можно загружать. В данном примере оно так и так куда то перелазит за диапазон и программа либо грохнется (если условие удовлетворено) либо не грохаясь проскочит но в любом случае (в защищенном режиме) данных в кэше не окажется.

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

Удивляет только почему раньше на это внимание не обратили.

Исправление uin, 05.12.18 00:19:

Ну этот не будет а вот этот вот будет:

char a1[10]="0123456789";
char secret[10]="secret";
char* a2;

char func(int offset)
{
   if (offset<10)
      a2[a1[offset]*64];
}

Т.е. При вызове функции с передачей ей аргумента в виде числа он спекулятивно загрузит a2[a1[offset]*64]; еще до того как проверит условие (ну хорошо, в интеле загрузит, а в эльбрусе компилятор просто поставит ее самой первой). Но в защищенном режиме это ничего не даст потому что строго контролируются границы чего откуда можно загружать. В данном примере оно так и так куда то перелазит за диапазон и программа либо грохнется (если условие удовлетворено) либо не грохаясь проскочит но в любом случае (в защищенном режиме) данных в кэше не окажется.

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

Удивляет только почему раньше на это внимание не обратили.

Исходная версия uin, 05.12.18 00:19:

Ну этот не будет а вот этот вот будет.

char a1[10]="0123456789";
char secret[10]="secret";
char* a2;

char func(int offset)
{
   if (offset<10)
      a2[a1[offset]*64];
}

Т.е. При вызове функции с передачей ей аргумента в виде числа он спекулятивно загрузит a2[a1[offset]*64]; еще до того как проверит условие (ну хорошо, в интеле загрузит, а в эльбрусе компилятор просто поставит ее самой первой). Но в защищенном режиме это ничего не даст потому что строго контролируются границы чего откуда можно загружать. В данном примере оно так и так куда то перелазит за диапазон и программа либо грохнется (если условие удовлетворено) либо не грохаясь проскочит но в любом случае (в защищенном режиме) данных в кэше не окажется.

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

Удивляет только почему раньше на это внимание не обратили.