<?xml version="1.0" encoding="UTF-8"?>

<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" >

  <channel>
    <title><![CDATA[Комментарии к публикации «Для устранения Spectre и Meltdown, возможно, придётся создать процессор совершенно нового типа»]]></title>
    <link>https://habr.com/ru/articles/422547/</link>
    <description><![CDATA[Комментарии к публикации «Для устранения Spectre и Meltdown, возможно, придётся создать процессор совершенно нового типа»]]></description>
    <language>ru</language>
    <managingEditor>editor@habr.com</managingEditor>
    <generator>habr.com</generator>
    <pubDate>Wed, 27 May 2026 17:04:42 GMT</pubDate>
    
    
      <image>
        <link>https://habr.com/ru/</link>
        <url>https://habrastorage.org/webt/ym/el/wk/ymelwk3zy1gawz4nkejl_-ammtc.png</url>
        <title>Хабр</title>
      </image>
    

    
      

      
        
  
    <item>
      <title>14.09.2018 19:35:37 sumanai</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19112481</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19112481</link>
      <description><![CDATA[Ага, особенно когда кошельки реализованы в этом самом браузере.]]></description>
      <pubDate>Fri, 14 Sep 2018 19:35:37 GMT</pubDate>
      <dc:creator><![CDATA[sumanai]]></dc:creator>
    </item>
  

  
    <item>
      <title>14.09.2018 16:50:32 DeepFakescovery</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19111985</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19111985</link>
      <description><![CDATA[нужно просто закрывать браузер, когда пользуешься электронными кошельками или конфиденциальной инфой]]></description>
      <pubDate>Fri, 14 Sep 2018 16:50:32 GMT</pubDate>
      <dc:creator><![CDATA[DeepFakescovery]]></dc:creator>
    </item>
  

  
    <item>
      <title>14.09.2018 16:50:31 Gargo</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19111983</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19111983</link>
      <description><![CDATA[мне одному кажется, что эти уязвимости всплыли как бы случайно, но на самом деле это очень выгодно производителям процов — когда не смогли выжать нормальную мощность, то пошли лепить 100500 ядер, потом более «экологичные» процы со снижением энергопотребления, а теперь все процы оказывается суперуязвимые — снова тратить деньги]]></description>
      <pubDate>Fri, 14 Sep 2018 16:50:31 GMT</pubDate>
      <dc:creator><![CDATA[Gargo]]></dc:creator>
    </item>
  

  
    <item>
      <title>14.09.2018 16:50:28 gitKroz</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19111981</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19111981</link>
      <description><![CDATA[То есть архитектура процессора не подверженного Spectre и Meltdown ещё не разработана? А как же тогда заявление про Ice Lake на <a href="https://en.wikipedia.org/wiki/Ice_Lake_(microarchitecture)">Wiki</a>?<br>
<blockquote>It is expected that Ice Lake will have in-silicon mitigations for the Meltdown and Spectre hardware vulnerabilities</blockquote>]]></description>
      <pubDate>Fri, 14 Sep 2018 16:50:28 GMT</pubDate>
      <dc:creator><![CDATA[gitKroz]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 20:25:33 napa3um</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19094341</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19094341</link>
      <description><![CDATA[Для разработчика не проблема поработать и на уязвимой машине с нормальной скоростью (и с соблюдением гигиены), а у конечного пользователя кроме браузера уже и не осталось ничего :).]]></description>
      <pubDate>Mon, 10 Sep 2018 20:25:33 GMT</pubDate>
      <dc:creator><![CDATA[napa3um]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 20:12:07 Yo1</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19094305</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19094305</link>
      <description><![CDATA[в эльбрусе вроде был некий защищенный режим, когда вместе с кодом некий таг процесса передавался. вполне возможно таг спасет…]]></description>
      <pubDate>Mon, 10 Sep 2018 20:12:07 GMT</pubDate>
      <dc:creator><![CDATA[Yo1]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 19:48:26 0xd34df00d</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19094241</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19094241</link>
      <description><![CDATA[Только в этом случае оно получится только в рамках браузера, а не ещё и компилятора, IDE и числодробилки вдовесок.]]></description>
      <pubDate>Mon, 10 Sep 2018 19:48:26 GMT</pubDate>
      <dc:creator><![CDATA[0xd34df00d]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 18:30:05 napa3um</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19093989</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19093989</link>
      <description><![CDATA[И получится то же самое замедление производительности, что и при решении на уровне патча микрокода (а так же всё равно решение в браузере не будет полным, «временнОй шум» аппаратуры всё равно будет «протекать» в последовательность выполнения фрагментов приложения). Ведь рандомизировать и замедлить придётся не просто таймеры, а абсолютно ВСЁ, ведь сравнивать скорости различных вычислительных процессов можно и вовсе без таймера (скажем, сравнить, сколько выполнится CSS-анимаций за время отрисовки какого-нибудь хитрого дива, или ещё что-то такое же косвенное).]]></description>
      <pubDate>Mon, 10 Sep 2018 18:30:05 GMT</pubDate>
      <dc:creator><![CDATA[napa3um]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 08:46:48 Lofer</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19091473</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19091473</link>
      <description><![CDATA[<blockquote>Я слабо представляю, как работают современные процессоры, но неужели нельзя вместо «не читать лишние данные» и «очищать кэш после каждой операции» пойти немного другим путём — «очищать в кэше только те данные, которые не должны были туда попасть»?</blockquote><br>
Нюанс в том, как именно организована память и ее адресация. Физическая адресация. Кеш вычитывает данные не побайтово, а целыми кусками/страницами. <br>
Такая логика имеет смысл по нескольким причинам причинам: <br>
<ul>
<li>исполнимый код расположен одним непрерывным куском в памяти,</li>
<li>обрабатываемые данные с большой степенью вероятности расположены последовательно</li>
<li>сменить физическую адресацию памяти занятие не дешевое само по себе (на планках памяти DDR4 CAS Latencies 14- 20 t, DDR3 CL9-CL11 t )</li>
</ul><br>
Если тонким слоем «размазать» данные по памяти — производительность сильно упадет.<br>
<blockquote>«очищать в кэше только те данные, которые не должны были туда попасть»</blockquote><br>
По дизайну именно так и задумано «не должно попасть» — все нарезано на странички, каждая со своими пометками, все помещено в какой-то контекст, свои таблицы трансляции и т.д. <br>
А по факту — весьма странный «баг дизайна»]]></description>
      <pubDate>Mon, 10 Sep 2018 08:46:48 GMT</pubDate>
      <dc:creator><![CDATA[Lofer]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 04:36:24 Darth_Malok</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090795</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090795</link>
      <description><![CDATA[Я слабо представляю, как работают современные процессоры, но неужели нельзя вместо «не читать лишние данные» и «очищать кэш после каждой операции» пойти немного другим путём — «очищать в кэше только те данные, которые не должны были туда попасть»? Можно даже какое-то микроядро прикрутить, которое только и занимается тем, что чистить кэш от «некорректных» данных. Процессор же на каком-то этапе отбрасывает результаты вычислений. Пусть где-нить записывает что-то типа «я тут немного погорячился, почисти тут и тут».<br>
<br>
Да, производительность немного упадёт, но не нужно будет изобретать «процессор совершенно нового типа».<br>
<br>
Или у меня искажённые представления, и программы постоянно лезут в недоступные области памяти, «разгоняя» друг друга за счёт кэширования?]]></description>
      <pubDate>Mon, 10 Sep 2018 04:36:24 GMT</pubDate>
      <dc:creator><![CDATA[Darth_Malok]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 03:34:06 Kobalt_x</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090759</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090759</link>
      <description><![CDATA[<p>Причем тут задача останова к сигнатурному поиску это же не проактивка какая</p>]]></description>
      <pubDate>Mon, 10 Sep 2018 03:34:06 GMT</pubDate>
      <dc:creator><![CDATA[Kobalt_x]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 03:01:10 michael_v89</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090739</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090739</link>
      <description><![CDATA[<p>Там в файле <a href="https://xlab.tencent.com/special/spectre/js/check.js">https://xlab.tencent.com/special/spectre/js/check.js</a> есть такой код:</p><br>
<pre><code>    if(window.SharedArrayBuffer)
    {
        output_cache_log(8);
        check(8, [88,117,97,110,119,117]);
    }
    else
    {
        output_not_info_leak();
    }</code></pre>]]></description>
      <pubDate>Mon, 10 Sep 2018 03:01:10 GMT</pubDate>
      <dc:creator><![CDATA[michael_v89]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 00:51:50 Mad__Max</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090711</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090711</link>
      <description><![CDATA[От Meltdown — точно. От Spectre — c высокой вероятностью. <br>
Правда кэш тут не причем. Просто Meltdown уязвимости вообще в процессорах AMD нет за счет отличающейся архитектуры. А Spectre сложнее реализовать.<br>
<br>
Структура кэш же важна при делении процессора «с соседями» — если к началу ветки вернуться, обсуждали работу на серверах и облачных вычислениях. Когда один физический процессор делится между несколькими разными клиентам разными системами виртуализации и один из клиентов может с помощью этих уязвимостей пытаться «выуживать» информацию из работающего софта у «соседей».]]></description>
      <pubDate>Mon, 10 Sep 2018 00:51:50 GMT</pubDate>
      <dc:creator><![CDATA[Mad__Max]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 00:32:34 Mad__Max</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090703</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090703</link>
      <description><![CDATA[Забавно что старый хром, наоборот пишет НЕ подвержен. И старый (ESR) Лис тоже.<br>
<br>
Или это из-за того, что процессор AMD? Хотя Spectre вроде и на AMD можно реализовать в отличии от Meltdown.]]></description>
      <pubDate>Mon, 10 Sep 2018 00:32:34 GMT</pubDate>
      <dc:creator><![CDATA[Mad__Max]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 00:09:20 0xd34df00d</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090687</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090687</link>
      <description><![CDATA[<blockquote>Еще можно хостить не нативные приложения, а байткод, котовый верифицировать на экслуотацию известных уязвимостей.</blockquote><p>Ща, пять сек, только задачу останова дорешаю.</p>]]></description>
      <pubDate>Mon, 10 Sep 2018 00:09:20 GMT</pubDate>
      <dc:creator><![CDATA[0xd34df00d]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 00:07:18 0xd34df00d</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090685</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090685</link>
      <description><![CDATA[<p>Те куски, о которых тут речь, куда мельче отдельных строк и даже инструкций программы (см. μops, конвертация во внутреннее RISC-представление, вот это всё).</p><br>
<p>Там, кстати, свои забавные баги бывают. ЕМНИП одно время одно из относительно недавних поколений процов считали, что, условно, <code>xor eax, eax</code> имеет зависимость по данным от <code>eax</code>, хотя где-то со второго пня процессоры умеют распознавать этот паттерн как зануление регистра и тупо мапят <code>eax</code> на нулевой/обнулённый регистр.</p>]]></description>
      <pubDate>Mon, 10 Sep 2018 00:07:18 GMT</pubDate>
      <dc:creator><![CDATA[0xd34df00d]]></dc:creator>
    </item>
  

  
    <item>
      <title>10.09.2018 00:04:02 0xd34df00d</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090679</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090679</link>
      <description><![CDATA[<p>На указанном примере это смысла действительно не имеет. Спекулятивное исполнение куда важнее для того, что называется tight loops.</p><br>
<p>Например, для большого ArrSize,</p><br>
<pre><code>for (int i = 0; i &lt; ArrSize; ++i)
{
    // handle i
    if (!(i % 10))
        // special handling for i = 10k
}</code></pre><br>
<p>Более того, вам даже внутри цикла условий не нужно, чтобы ощутить профит от спекулятивного исполнения: сам цикл — тоже условие, в конце концов (<code>if predicate goto loop</code>). И вам не нужно дожидаться окончания текущей итерации цикла, если следующая итерация от текущей не зависит (умножение матриц там, всё такое, ага).</p><br>
<p>А для выбора того, какой файл читать, это всё нафиг не нужно, да.</p>]]></description>
      <pubDate>Mon, 10 Sep 2018 00:04:02 GMT</pubDate>
      <dc:creator><![CDATA[0xd34df00d]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 23:40:51 0xd34df00d</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090665</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090665</link>
      <description><![CDATA[Это вполне может решаться на уровне браузера огрублением таймеров и прочими рандомизациями из этой серии.]]></description>
      <pubDate>Sun, 09 Sep 2018 23:40:51 GMT</pubDate>
      <dc:creator><![CDATA[0xd34df00d]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 23:06:42 Lofer</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090635</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090635</link>
      <description><![CDATA[Есть и для этого инструментарий давно как и на уровне оптимизации в компиляторе, так и на уровне языков/библиотек.<br>
<blockquote>Но и если бы вся инфа была загружена заранее — выполнение функции (по условию) — час, выполняя лишнюю функцию, проц бы выполнил безумно много лишней работы ;-) </blockquote><br>
Так процессору все равно заняться нечем — данных нет, кода нет. блоки вычисления и конвейры стоят пустые. Почему бы их не занять чем-то, что в будущем может окупиться? Так сказать «инвестиции свободных ресурсов в <u>возможное</u> светлое будущее»]]></description>
      <pubDate>Sun, 09 Sep 2018 23:06:42 GMT</pubDate>
      <dc:creator><![CDATA[Lofer]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 23:01:44 arielf</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090627</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090627</link>
      <description><![CDATA[На лицо несоответствие модели ЯП — железу. Хорошо, ежели программа выполняется именно так, как она написана. Не правильнее было бы явно указывать, какие куски программы можно выполнять параллельно, а какие нельзя?]]></description>
      <pubDate>Sun, 09 Sep 2018 23:01:44 GMT</pubDate>
      <dc:creator><![CDATA[arielf]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 22:55:04 imanushin</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090621</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090621</link>
      <description><![CDATA[<blockquote>по сравнению со скоростью написания</blockquote><p>Вы забыли добавить слово «компиляторов». Java/.Net/JS программы ведь не надо переписывать. </p>]]></description>
      <pubDate>Sun, 09 Sep 2018 22:55:04 GMT</pubDate>
      <dc:creator><![CDATA[imanushin]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 22:54:13 arielf</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090617</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090617</link>
      <description><![CDATA[Спасибо! Но вы привели как раз параллелизуемый пример — <i>a</i> и <i>x</i> можно считать независимо. В моём примере, вычисления не прараллелизуемы — файлы загружены после проверки — ну, например, <i>x</i> нужно чтобы решиь, какие файлы загружать. И функции можно вызвать лишь после проверки. Но и если бы вся инфа была загружена заранее — выполнение функции (по условию) — час, выполняя лишнюю функцию, проц бы выполнил безумно много лишней работы ;-) <br>
<br>
В общем на низком уровне — умножение и прочее — всё хорошо, а на высоком уровне? Ежели у вас b, с, y и z — матрицы 1000 x 1000, или вызовы функции, выполняющейся часы? <br>
<br>
Хм, а раньше early exit как раз и был призван избавить мир лишних вычислений! А щаз, получается, все компилеры наплевали на порядок инструкций.]]></description>
      <pubDate>Sun, 09 Sep 2018 22:54:13 GMT</pubDate>
      <dc:creator><![CDATA[arielf]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 21:57:20 Antervis</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090541</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090541</link>
      <description><![CDATA[рассмотрим простые инструкции на современных процах, например <a href="https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_mul_ss&amp;expand=3699,3699">умножение вещ. чисел одинарной точности</a>, для skylake: latency = 4, CPI = 0.5. Это значит, что за один такт процессор может засунуть в конвеер две инструкции умножения, но результат выполнения каждой из них будет доступен только через четыре такта. Теперь предположим, что мы между этими двумя операциями вставим условный переход, что-то типа:<br>
<pre><code class="cpp">float a = b * c;
if (a &gt; d) // допустим, это холодная ветка
    return 0;
float x = y * z;
// Считаем дальше...
</code></pre><br>
В общем случае нам понадобится дождаться вычисления результата <i>a</i> (4 такта), посчитать условие (1-2 такта), и если мы не уходим в холодную ветку можно просто считать дальше, но с проверкой 7 тактов вместо 1.<br>
<br>
А если выполнять спекулятивно — одновременно считается x и перепроверяется, что холодную ветку выполнять на самом деле не надо. И там либо всё ок и к моменту перепроверки уже несколько тактов насчитано (а сама проверка словно ничего и не стоила), либо насчитано несколько тактов вхолостую и надо прыгать в холодную ветку. Уязвимости как раз и используют результат этих холостых вычислений<br>
<br>
п.с. на истину в последней инстанции не претендую, если где не прав — поправляйте]]></description>
      <pubDate>Sun, 09 Sep 2018 21:57:20 GMT</pubDate>
      <dc:creator><![CDATA[Antervis]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 21:41:17 equand</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090525</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090525</link>
      <description><![CDATA[Сейчас программно так и реализовали (KPTI), по сути ОС загружает и выгружает данные из кеша, когда они больше не нужны.<br>
<br>
Однако ускорение от спекуляции в том как раз таки, что доступ разрешен спекулятивному выполнению.]]></description>
      <pubDate>Sun, 09 Sep 2018 21:41:17 GMT</pubDate>
      <dc:creator><![CDATA[equand]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 21:37:58 equand</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090521</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090521</link>
      <description><![CDATA[АМД безопасней в некотором плане. Но спектру все подвержены в том или ином виде процы связанные со спекулянтством.<br>
<br>
Антивири к этому не имеют отношения. Фактически это прямой доступ к ring0 из browser javascript. Решается латанием дыр (по сути запретом выполнения определенных вещей, например в firefox уменьшили разрешение gettime() колов) в компиляторах и интерпретаторах, оси и др.]]></description>
      <pubDate>Sun, 09 Sep 2018 21:37:58 GMT</pubDate>
      <dc:creator><![CDATA[equand]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 21:34:59 equand</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090513</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090513</link>
      <description><![CDATA[Там не в прямом чтении дело. А в том что в процессе подбора байт проверка происходит либо быстро либо медленно, в зависимости от того, какой байт подошел. Если тот же байт то отказ приходит быстрее нежели не тот.]]></description>
      <pubDate>Sun, 09 Sep 2018 21:34:59 GMT</pubDate>
      <dc:creator><![CDATA[equand]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 20:24:45 Lofer</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090439</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090439</link>
      <description><![CDATA[<blockquote>Ибо чтобы реально выполнить функции из примера нам нужна инфа, получаемая лишь после проверки условия! А раз нету реальной инфы — знач нету и угрозы?</blockquote><br>
А на это есть алгоритмы пресказания ветвления — один из самых охраняемых «секретов фирмы». В последних процессорах пытаются приделать для этого нейронные сети, как раз потому что разное ПО с разным поведением сильно влияет на «утилизацию вычислительных ресурсов» и штрафы за ошибки предсказания.<br>
Дабы уменьшить штрафы — и загружают все что может пригодится «на всякий случай»]]></description>
      <pubDate>Sun, 09 Sep 2018 20:24:45 GMT</pubDate>
      <dc:creator><![CDATA[Lofer]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 19:36:02 masv</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090365</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090365</link>
      <description><![CDATA[У меня Athlon ii X3 вообще без L3 кэша. Я застрахован от этих атак?]]></description>
      <pubDate>Sun, 09 Sep 2018 19:36:02 GMT</pubDate>
      <dc:creator><![CDATA[masv]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 18:55:48 Vilgelm</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090299</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090299</link>
      <description><![CDATA[Vivaldi последней версии, написал что неподвержен. Хром последней версии, написал что подвержен.]]></description>
      <pubDate>Sun, 09 Sep 2018 18:55:48 GMT</pubDate>
      <dc:creator><![CDATA[Vilgelm]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 18:48:09 Diordna</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090269</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090269</link>
      <description><![CDATA[Уязвимость только х64 задела?]]></description>
      <pubDate>Sun, 09 Sep 2018 18:48:09 GMT</pubDate>
      <dc:creator><![CDATA[Diordna]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 18:47:03 arielf</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090267</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090267</link>
      <description><![CDATA[Как бы без реальных вычислений? Ну, например, конвертация машинных инструкций в низкоуровневые инструкции микропроцессора и прочее? Ибо чтобы реально выполнить функции из примера нам нужна инфа, получаемая лишь <i>после</i> проверки условия! А раз нету реальной инфы — знач нету и угрозы?<br>
<br>
И ещё, не является ли неравномерная нагрузка процессора — проблемой «линейных» языков программирования? И как её решить без спекуляции? <br>
<br>
Решение ну явно некрасивое ;-)]]></description>
      <pubDate>Sun, 09 Sep 2018 18:47:03 GMT</pubDate>
      <dc:creator><![CDATA[arielf]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 18:43:11 sumanai</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090261</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090261</link>
      <description><![CDATA[<blockquote>В чём проблема подписывать данные в кэше идентификатором процесса? </blockquote><br>
Уже, гуглить PCID.<br>
<blockquote>«Ну а что, а вдруг?»</blockquote><br>
Так и есть. Есть общесистемные библиотеки, разделяемые данные.<br>
<blockquote>Так и кеш будет работать быстрее — не потратит время на поиск данных там, где их нет и быть не может, и безопасность будет выше.</blockquote><br>
Медленнее, потому что придётся учитывать ещё один параметр. Кеш реализован в железе, и тут дополнительыне параметры только портатят транзисторный бюджет.]]></description>
      <pubDate>Sun, 09 Sep 2018 18:43:11 GMT</pubDate>
      <dc:creator><![CDATA[sumanai]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 18:42:50 Diordna</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090259</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090259</link>
      <description><![CDATA[Амд быстрее/безопасней?<br>
Авиры смогут как-то бороться с пооблемой?]]></description>
      <pubDate>Sun, 09 Sep 2018 18:42:50 GMT</pubDate>
      <dc:creator><![CDATA[Diordna]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 18:34:04 sumanai</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090247</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090247</link>
      <description><![CDATA[У меня наоборот, не подвержен уязвимости, FF на ОС, у которой отключены все эти патчи. В общем фигня всё это, что через яваскрипт.]]></description>
      <pubDate>Sun, 09 Sep 2018 18:34:04 GMT</pubDate>
      <dc:creator><![CDATA[sumanai]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 17:18:16 Tyusha</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090109</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090109</link>
      <description><![CDATA[Проблема в наличие конвейера в современных процессорах. Обработка команд, если так можно выразиться, начинается сильно заранее их непосредственного «выполнения». Поэтому пока не получен результат if-а (пусть даже самого простого вычислительно), конвейеру пришлось бы простаивать без дела. А потом, когда исход условия прояснился бы, пришлось «раскочегаривать» конвейер заново, и ждать, пока нужная ветвь пройдёт все его стадии. Как я понимаю, в нынешних процессорах длина конвейера захватывает десятки команд.<br>
<br>
А так процессор может спекулятивно предположить результат if-а и заняться подготовкой на конвейере какой-либо ветви впрок. Поэтому к моменту разрешения условия всё уже готово без простоя.<br>
<br>
И ещё замечу, что дело не сложности или простоте условия, а в том, что его значение не может быть вычислено ранее определённого момента.]]></description>
      <pubDate>Sun, 09 Sep 2018 17:18:16 GMT</pubDate>
      <dc:creator><![CDATA[Tyusha]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 17:17:25 inferrna</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090107</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090107</link>
      <description><![CDATA[Насколько я понимаю, многозадачность современных системах реализована на уровне процессора. Т.е. в процессор уже заложено разграничение между процессами на доступ к ресурсам и т.д. В чём проблема подписывать данные в кэше идентификатором процесса? Процесс что-то вычислял, получал данные из своей области памяти и часть данных отпечаталась в кэш. Потом пришёл другой процесс со своей памятью и своими данными — зачем вообще процессор тратит время на поиск в области кеша, в которую этот новый процесс ничего не писал? «Ну а что, а вдруг?» Что стоит изолировать данные в кеше между процессами? Так и кеш будет работать быстрее — не потратит время на поиск данных там, где их нет и быть не может, и безопасность будет выше.]]></description>
      <pubDate>Sun, 09 Sep 2018 17:17:25 GMT</pubDate>
      <dc:creator><![CDATA[inferrna]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 17:10:49 Tyusha</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090089</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090089</link>
      <description><![CDATA[Мне кажется, что x86 это навсегда! Уж насколько Itanium был лучше, и то умер.]]></description>
      <pubDate>Sun, 09 Sep 2018 17:10:49 GMT</pubDate>
      <dc:creator><![CDATA[Tyusha]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 16:43:37 arielf</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19090033</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19090033</link>
      <description><![CDATA[Ну, всё равно не ясно — чем ужасны условия? Неужели на вычисление условия нужно больше времени, чем на выполнение целой кучи инструкций? <br>
<br>
<pre><code class="cpp">if(x) { 
    get_file(a, b, c);
    big_func(a, b, c); // Processing one hour 
else { 
    get_file(e, f, g); 
    another_big_func(e, f, g); // Processing one hour 
}  
// x, a, b, c, e, f, g -- are known in runtime 
</code></pre><br>
Разъясние плиз на указанном примере принцип. Как правило условия нужны, ежели решение принимаеся во время выполнения, а знач и функции мы заранее не вычислим, ибо нужная инфа ещё не загружена.]]></description>
      <pubDate>Sun, 09 Sep 2018 16:43:37 GMT</pubDate>
      <dc:creator><![CDATA[arielf]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 16:00:20 Lofer</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19089981</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19089981</link>
      <description><![CDATA[<blockquote>Еще можно хостить не нативные приложения, а байткод, котовый верифицировать на экслуотацию известных уязвимостей.</blockquote><br>
Это скрестить сигнатурный анализатор с JIT-компилятором? Так МС вас опередила — на уровне компилятора с 2003 года нельзя дергать системные функции без критериев безопастности (явного размера данных), в .Net встроены декларативные механизмы безопастности, в для нативных приложений используются манифесты. Это решило часть проблем. Что делать с остальным — пока не очень понятно.]]></description>
      <pubDate>Sun, 09 Sep 2018 16:00:20 GMT</pubDate>
      <dc:creator><![CDATA[Lofer]]></dc:creator>
    </item>
  

  
    <item>
      <title>09.09.2018 13:19:45 potan</title>
      <guid isPermaLink="true">https://habr.com/ru/articles/422547/#comment_19089801</guid>
      <link>https://habr.com/ru/articles/422547/#comment_19089801</link>
      <description><![CDATA[Можно отказаться от out-of-order, и вообще от суперскаларности, а для закрузки конвеера использовать гипертрединг с большим количество нитей.<br>
Еще можно хостить не нативные приложения, а байткод, котовый верифицировать на экслуотацию известных уязвимостей.]]></description>
      <pubDate>Sun, 09 Sep 2018 13:19:45 GMT</pubDate>
      <dc:creator><![CDATA[potan]]></dc:creator>
    </item>
  

      

      

    
  </channel>
</rss>
