Вход на сайт

Облако тегов

АШ-YouTube

Баги в процессорах (Intel, AMD, ARM64, Power8, Power9). Неприятные.

Аватар пользователя v.p.

Если кратко - из юзерлэнд под любой ОС на Intel и ARM64(?) можно получить доступ к системной памяти. Багфикс в процессе, но он убивает производительность. PoC Интел:

 

Here's everything I've been able to find so far:

  • The issue impacts all modern Intel CPUs. (Edit: It's been confirmed that the latest unaffected CPU is the original Pentium.) According to an AMD engineer, "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault." In short, AMD does not have the bug.

  • If successfully exploited, it could allow any program running on your computer (including a webpage with JavaScript) to access memory used by the operating system, giving it total control over your computer.

  • There is a patch in the works for both Windows and Linux that protects against this. However, the patch can cause a large impact on performance. It slows down any "syscalls" - function calls where the program talks directly to the operating system. This includes everything from opening files to communicating over the network; it is almost impossible to write a modern program without them.

  • The performance impact seen depends on the amount of syscalls the application makes. Raw number-crunching applications will see very little performance impact, whereas applications that have to talk to the OS a lot can see a large impact.

  • Raw numbers are hard to find due to the secretive nature of these patches, but here are some basic benchmark impacts we've seen so far:

    • Linux, on an i7 6700, calling the getpid syscall 100,000,000 times:

      • Before the patch: ~3.8 seconds.
      • After the patch: ~15 seconds.
    • PostgreSQL, a database application, i7-6820HQ, SELECT 1 benchmark:

      • Before the patch: 420490.162391 transactions per second
      • After the patch: 350746.065039 transactions per second

 

Итак, благодаря бдительному и неленивому камраду Нехороший имеется расширенное толкование и пояснение:

 

Разработчики из Google Project Zero опубликовали детали уязвимостей, которые затрагивают не только процессоры Intel и ARM64, но и AMD тоже (есть сообщения, что только при включении BPF JIT в ядре, что по умолчанию выключено). Названия им дали: Meltdown и Spectre (расплавление ядерного реактора и призрак).

Meltdown позволяет приложению читать любую память компьютера, включая память ядра и других пользователей. Этой атаке подвержены процессоры Intel (по неподтвержденным данным все модели с 1995 года, кроме Itanium и Atom) и ARM64.

Spectre создаёт брешь в изоляции различных приложений и позволяет атакующему обманным способом получить данные чужого приложения. Этой атаке подвержены процессоры Intel, AMD, ARM64, Power8 и 9.

Эксплоит, эксплуатирующий Meltdown позволяет читать память ядра со скоростью 2000 байт в секунду на процессоре Intel Xeon архитектуры Haswell.

Уязвимостям назначены следующие CVE: CVE-2017-5753, CVE-2017-5715 и CVE-2017-5754.

Напомню, что пользователи ежедневно запускают чужой код на своих компьютерах, посещая веб сайты с JavaScript (>99%), поэтому применение патча (здесь и здесь) обязательно, если вы дорожите своими данными. Есть PoC (п.4.3) , демонстрирующий атаку с этой уязвимостью через JavaScript.

Разработчики ARM приводят подробности атаки для ARM, заявляют о том, что уязвимы лишь некоторые процессоры ARM, дают их список и меры по повышению безопасности

 

Авторство: 
Копия чужих материалов
Комментарий автора: 

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

 

Добавлено: больше процессоров, больше багов. PoC публичное для Meltdown (Intel) и Spectre (документ), это весело.

Комментарий редакции раздела хакеры

 эта фича заложена в конструкцию ВСЕХ без исключения вычислительных устройств, произведенных
последние 10 лет в тщетных попытках инженеров обойти НЕИЗБЕЖНЫЙ тепловой тупик, с которым
продвинутые люди в теме были хорошо знакомы уже лет пятнадцать и каждое упоминание которого
неизбежно вызывало оскорбительные эпитеты в адрес автора со стороны подлецов и подонков.

Теперь выход один - или радикально УХУДШИТЬ производительность ВСЕХ процессоров, отбросив состояние
дел на пятнадцать лет назад, где оно по всем фундаментальным основам и должно было пребывать уже НАВЕЧНО,
либо смириться с тем что ЛЮБЫЕ вычислительные устройства будут напрочь ОТКРЫТЫ ВСЕМ кому не лень их взломать.

Никаких “облаков”, никаких “амазонов”, никаких смартфонов - все без исключения надо выбросить сегодня
и сейчас, если там есть нечто стоящее, выжидая несколько лет пока интел не наладит снова выпуск более устойчивых процессоров образца 2004-го года, куда мы все неизбежно откатимся.

https://golos-dobra.livejournal.com/1057823.html

Фонд поддержки авторов AfterShock

Комментарии

Аватар пользователя iUser
iUser(5 лет 1 месяц)(13:26:42 / 04-01-2018)

Это не баг, это фича.
 

Аватар пользователя v.p.
v.p.(7 лет 1 неделя)(13:29:07 / 04-01-2018)

 ну да, типа недавней про IME. многовато у Интела фич в последнее время на тему очень клёвых бэкдоров :-)

Аватар пользователя katu
katu(7 лет 7 месяцев)(03:13:01 / 05-01-2018)

а не загнул ли автор насчет опасности выполнения джаваскрипта в браузере?

Аватар пользователя monk
monk(7 лет 7 месяцев)(07:10:57 / 05-01-2018)

Не загнул: https://www.react-etc.net/entry/exploiting-speculative-execution-meltdow...

Правда разработчики браузеров вроде могут это побороть. Скорее всего с таким же падением производительности.

Аватар пользователя katu
katu(7 лет 7 месяцев)(17:55:07 / 05-01-2018)

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

Аватар пользователя 11
11(1 год 11 месяцев)(15:37:04 / 04-01-2018)

Комментарий администрации:  
*** Лживый ублюдок ***
Аватар пользователя vs451
vs451(2 года 6 месяцев)(00:07:08 / 05-01-2018)

Грейтэгейн! Придется новый комп покупать, блин...!

Аватар пользователя vlkamov
vlkamov(7 лет 8 месяцев)(09:08:03 / 05-01-2018)

Не новый, а старый ;-)

Аватар пользователя vs451
vs451(2 года 6 месяцев)(21:30:26 / 05-01-2018)

Кроме шуток. Где-то видел заметку о том, что айфоны тормозят старые версии, типа чтобы заряд батареи дольше держался (на самом деле, чтобы лохи поскорее новые телефоны покупали), а Интел рассказывает о жуткой дырке в процессоре в тот момент, когда нужно сделать Америку грейтэгейн, а именно продать кучу барахла за большие деньги - новые процессоры.

Аватар пользователя Ахура Мазда
Ахура Мазда(3 года 11 месяцев)(00:20:39 / 05-01-2018)

Я понимаю, что звучит как ТЗ, но что если суть именно в том, чтобы все срочно накатили какой-то там патч, который чего-то там добавит, но по большому счету никто не станет смотреть что?

Аватар пользователя monk
monk(7 лет 7 месяцев)(07:21:33 / 05-01-2018)

Микрософт и так регулярно патчи выдаёт. В Linux kernel патч уже все посмотрели и даже внесли изменения (убрали тормоза на AMD и Intel Atom)

Аватар пользователя saenara
saenara(2 года 10 месяцев)(13:31:56 / 04-01-2018)

Самое неприятное, что этот жирный песец внимательно смотрит в сторону виртуализации :-(

Комментарий администрации:  
*** Уличен в розжиге по нацпризнаку ***
Аватар пользователя ata
ata(7 лет 8 месяцев)(13:33:57 / 04-01-2018)

Да уж.

Если ВМы не изолированы друг от друга на аппаратном уровне, то все облака накрываются медным тазом.

"Будет ласковый дождь..."

Аватар пользователя v.p.
v.p.(7 лет 1 неделя)(13:34:28 / 04-01-2018)

я уже добавил в авторский. последствия реально чудовищные.

Аватар пользователя saenara
saenara(2 года 10 месяцев)(13:40:28 / 04-01-2018)

К херам-то они может и не пойдут, запатчат же, но просад производительности виртуальных сред будет адский. 

Комментарий администрации:  
*** Уличен в розжиге по нацпризнаку ***
Аватар пользователя v.p.
v.p.(7 лет 1 неделя)(14:23:03 / 04-01-2018)

почему я думаю чо будет грустнее? ну как надо было реализовывать VT extesions чтобы их вот так всё обходило? текущую-то проблему попатчат, а что делать с концепцией реализации виртуализации на интелах?

Аватар пользователя BarBoss
BarBoss(4 года 9 месяцев)(02:55:36 / 05-01-2018)

Юные геймеры уже в ужасе от такой перспективы. Деть сказал - "Не буду свой линух обновлять!!! angry " Через несколько часов - "А придётся. sad "

Аватар пользователя iStalker
iStalker(7 лет 7 месяцев)(14:50:27 / 04-01-2018)

Учитывая что этому багу уже 20+ лет, последствия все какие могли быть уже случились.

 

Аватар пользователя v.p.
v.p.(7 лет 1 неделя)(14:54:06 / 04-01-2018)

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

Аватар пользователя rukav
rukav(3 года 3 месяца)(23:22:29 / 04-01-2018)

Apple: Мы сокращаем производительность яйфонов, как только приходит конец их батареям и не сообщаем об этом вам. 

Intel: Мы сокращаем производительность каждого процессора в мире на 30% из-за старой дырки в нашей архитектуре процессоров.

Итоги:

Аватар пользователя лабиринт разума

Разве полмиллиона доморощенных хомячков, которым это сейчас слили, уже наклепали из конструкторов эксплойтов на базе этих уязвимостей?

Аватар пользователя Nordicx86
Nordicx86(7 лет 8 месяцев)(03:15:34 / 05-01-2018)

от публикации критичной дыры до эксплойта  обычно 8-10 часов..... развертывание в интернете системы эксплуатирующей "дыру" 3-5 дней.... и это С НУЛЯ, если уже есть схемы "вывода" и тп то все в разы быстрее.......

ДУМАЙТЕ.....
 

Комментарий администрации:  
*** Криптобес ***
Аватар пользователя joho
joho(5 лет 11 месяцев)(22:17:13 / 04-01-2018)

Фигня, аналог проблемы 2000. 

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

Ну, если не считать массовую закупку нового железа и принудительные тормоза для всех операционок, заботливо вставленное в них вендорами

Аватар пользователя Ахура Мазда
Ахура Мазда(3 года 11 месяцев)(00:22:11 / 05-01-2018)

Выше написал, что вся эта шумиха (а сегодня такой прием не новость) просто для отвлечения и накатки определенного  кода.

Аватар пользователя Nordicx86
Nordicx86(7 лет 8 месяцев)(03:17:02 / 05-01-2018)

для хомячков - да

главная жопа это "виртуализация" и Публичные облака

Комментарий администрации:  
*** Криптобес ***
Аватар пользователя joho
joho(5 лет 11 месяцев)(07:56:40 / 05-01-2018)

значит, будут платить за толковый файрвол, либо гонять в публичном облаке код с ценностью, равной нулю. А всякие вордпресы как ломали так и будут ломать

Очевидно, что раз запускаешь свою подсистему на неизвестно чьём железе в компании с неизвестно кем, значит не стоит надеться на конфиденциальность своих данных. Ситуация равна той, что тормознули виртуалку, скопировали из неё всё, что надо, и дальше запустили. И совершенно нет разницы, было ли это ЦРУ, СБУ, вендор или вася с соседней улицы.

Аватар пользователя monk
monk(7 лет 7 месяцев)(07:31:24 / 05-01-2018)

Для эксплуатации уязвимости требуется совершенно конкретное поведение - экстремально высокий темп ошибок по защите памяти, столь же высокий темп переключения контекстов

Если бы. Псевдокод выглядит так:

int x = 0;
double y;
time_t times[256];
for(int n = 0; n < 256; ++n) {
   t1 = get_time();
   do_1000000times {
      if (likely(x!=0)) {
          if (readbyte(address)==n)
            y = atan(23143242.0);
      }
   }
   t2 = get_time();
   times[n] = t2;
}
n = find_greatest_time(times);
printf("byte at address %p = %02x\n",address,n);

Код  readbyte(address) никогда не выполняется (так как x=0), поэтому ошибки памяти нет, но из-за спекулятивного выполнения, в тот момент, когда readbyte(address)==n всё равно должен довычисляться atan. А значит в этот момент время выполнения станет чуть больше.

P.S. На самом деле if (readbyte(address)==n) делать нельзя, так как он даст ещё одну ветку конвейера, там нужно использовать функцию, которая для разных значений выполняется разное время. Но суть того, что отловить такое поведение через контроль того, что выполнилось, невозможно.

Аватар пользователя joho
joho(5 лет 11 месяцев)(07:49:49 / 05-01-2018)

сдаётся мне, что железу безразлично, было ли чтение в "опережающем" режиме, или в обычном потоке исполнения. Я бы поставил на срабатывание исключения по защите памяти от чтения.

Аватар пользователя monk
monk(7 лет 7 месяцев)(08:27:13 / 05-01-2018)

Не безразлично. Было бы странно получать ошибку чтения памяти на код x = 0; if(x) { /* здесь доступ к памяти */ }.

Поэтому проверка прав и вызов исключения происходят только если выполнение действительно пошло по этой ветки (предсказание было верно). Ошибка в том, что предсказанная ветка выполняется без проверки прав. Права проверяются только если исполнение действительно пошло по этому пути. Типа оптимизация.

Аватар пользователя joho
joho(5 лет 11 месяцев)(08:41:09 / 05-01-2018)

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

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

Проблема есть, но не ужосужос 

Аватар пользователя monk
monk(7 лет 7 месяцев)(08:42:17 / 05-01-2018)

нормальные компиляторы такой код выкусывают при оптимизации и у правильных пацанов всё оки.

Код может быть и такой: int x = factorial(5) - 120; if(x) { ... };

А гики, задачей которых является поиск недокументированных фич, могут перетоптаться и с исключением.

С учётом того, что 99% кода с исключением будет выглядеть как if(p) { x = *p } (если указатель заполнен, то разыменоваваем) или даже if(o.alive) { x = *o.ref } (здесь как раз будет ошибка доступа, а не разыменование пустого указателя, если условие игнорировать), то я очень сомневаюсь, что это хорошая идея.

Аватар пользователя joho
joho(5 лет 11 месяцев)(09:02:51 / 05-01-2018)

Код может быть и такой: int x = factorial(5) - 120; if(x) { ... };

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

Поэтому в нормальном коде такой кусок не сработает. 

говорю же, вы копаете не туда. Утечка идёт по побочному каналу. Железо не даёт прочитать данные напрямую, это исключение. Изучается быстродействие - что именно попало в кэш в качестве prefetch. Проблему, ИМХО, можно решить загрублением таймера, атаку выявить его интенсивным использованием

Аватар пользователя monk
monk(7 лет 7 месяцев)(09:26:59 / 05-01-2018)

константные выражения вычисляются загодя, по ним же делается оптимизация, в том числе исключение неисполнимого кода

Откуда компилятор знает, что функция factorial из внешней библиотеки возвращает константное выражение? И не форматирует диск, например. Ведь если форматирует, то это должно происходить не при компиляции программы, а при выполнении.

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

 Проблему, ИМХО, можно решить загрублением таймера, атаку выявить его интенсивным использованием

 В JS так сделано. "JavaScript does not provide access to the rdtscp instruction, and Chrome intentionally degrades the accuracy of its high-resolution timer to dissuade timing attacks using performance.now() [1]. However, the Web Workers feature of HTML5 makes it simple to create a separate thread that repeatedly decrements a value in a shared memory location [18, 32]. This approach yielded a high-resolution timer that provided sufficient resolution." © https://spectreattack.com/spectre.pdf

То есть достаточно сделать второй поток с циклом и считать такты.

Аватар пользователя joho
joho(5 лет 11 месяцев)(13:42:07 / 05-01-2018)

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

Да, конечно, вы правы.

То есть достаточно сделать второй поток с циклом и считать такты.

собственно, с этим уже борются.

Specifically, in all release channels, starting with 57:

  • The resolution of performance.now() will be reduced to 20µs.
  • The SharedArrayBuffer feature is being disabled by default.

Furthermore, other timing sources and time-fuzzing techniques are being worked on.

https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-cla...

Аватар пользователя monk
monk(7 лет 7 месяцев)(15:28:37 / 05-01-2018)
  • The SharedArrayBuffer feature is being disabled by default.

Для JS в браузере это подойдёт. Для виртуалок и  произвольного кода это фактически запрет на многопоточные приложения.

Аватар пользователя Praetor12
Praetor12(6 лет 9 месяцев)(12:36:12 / 05-01-2018)

Большое спасибо за код, так намного понятнее в чем проблема. Только подправьте плз, вместо x=0 на тот же факториал, ибо реально даже gcc с -O0 просто выкинет эту проверку нафиг. Добиться желаемого поведения на C++ компиляторах та ещё задача. И вот это бы тоже развернуть: 

do_1000000times {

А то не особенно понятно, то ли это должно выполниться много раз, то ли просто непонятная инструкция непонятного псевдокода. 

Я даже не знал до сегодня о такой фиче процессоров как спекулятивное выполнение, впрочем на том языке в котором я работаю такого наверное и не добиться(

Аватар пользователя joho
joho(5 лет 11 месяцев)(14:03:08 / 05-01-2018)

суть вот в чём

Есть область памяти, недоступная для user. Мы хотим прочитать один байт по некоторому адресу А.

Для этого берётся массив B[ 256 х длину строки кэша], нам доступный, и пытаемся адресоваться в нём байтом из недоступной нам области памяти. Однако, код, который это делает, помещаем в недостижимый по потоку исполнения фрагмент.

Процессор, обнаружив ожидаемую попытку косвенной адресации, подтягивает в кэш строку B[@A х длину строки кэша] из нашего буфера, соответствующую содержимому байта из недоступной нам памяти. Однако, поскольку фрагмент реально не исполняется в нашем потоке, то мы "как бы" и не читали этот байт, потому исключения по защите памяти может не случиться. Результатом будет кэширование строки нашего массива, соответствующей содержимому байту @A. Поэтому речь идёт о строке, равной размеру строки кэша. Мы не можем подтянуть один байт из массива В.

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

 

Аватар пользователя Lokki
Lokki(4 года 6 месяцев)(23:25:27 / 05-01-2018)

И  ещё надо молиться за то, что бы это добро отрпботало в одном кванте времени и ОС не перекинула в другое ядро.

Теже кеды очень ловко перекидывают по ядрам, что бы они грелись боле-менее равномерно.

Аватар пользователя Rashad_rus
Rashad_rus(7 лет 7 месяцев)(21:10:51 / 04-01-2018)

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

Аватар пользователя ОЛЕГ
ОЛЕГ(4 года 10 месяцев)(07:28:33 / 05-01-2018)

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

Аватар пользователя Rashad_rus
Rashad_rus(7 лет 7 месяцев)(08:54:53 / 05-01-2018)

Рекомендую проверить, достаточно повесить немаскируемое прерывание в ядро с контролем доступа к своей памяти и все попытки лезть куда не надо - можно пресекать так, как считаете нужным. Проверял. А вся беда в том, что программисты ПРИВЫКЛИ к железной защите и пользуют стандартные библиотеки, но не заботятся об основах...))))

Аватар пользователя ОЛЕГ
ОЛЕГ(4 года 10 месяцев)(09:10:17 / 05-01-2018)

if таблица__не_инициализирована :
    запросить заполнение таблицы
сделать переход по адресу из таблицы

Интеловский оптимизатор выполняет обе ветки ветвления. Понятно, что если таблица не инициализирована, переход по адресу из таблицы будет в куда_не_надо,

Защита, которая отрубает программу из-за того, что переход внутри одной из веток стоит не туда, такую программу убьёт. А программа - нормальная.

Аватар пользователя Mc_Aaron
Mc_Aaron(4 года 6 месяцев)(23:26:35 / 05-01-2018)

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

Аватар пользователя ОЛЕГ
ОЛЕГ(4 года 10 месяцев)(23:40:33 / 05-01-2018)

Вы ведь про ветвление, которое создание новой ветви (thread), потока выполнения команд? Да, согласен. Но я под ветвлением подразумевал ветвление внутри одного потока выполнения, код, который возникает в результате компиляции условного оператора "if".

Аватар пользователя Mc_Aaron
Mc_Aaron(4 года 6 месяцев)(17:22:32 / 06-01-2018)

Об этом не подумал. Тогда ждем возврат итаниума и взлет эльбруса. Во втором планирование потоков статическое на стадии кодогенерации, возможно в первом аналогично.

Аватар пользователя Rashad_rus
Rashad_rus(7 лет 7 месяцев)(21:11:46 / 04-01-2018)

Ха! А для таких целей и существуют серые сети, которые не побомбишь...)))))))))))

Аватар пользователя ata
ata(7 лет 8 месяцев)(13:32:14 / 04-01-2018)

Жесть.

Недаром фон Нейман и Doomsday machine придумал.

Аватар пользователя iUser
iUser(5 лет 1 месяц)(13:49:31 / 04-01-2018)

Не нагнетайте - это все для удобства и безопасности пользователя! )))
 

Аватар пользователя ata
ata(7 лет 8 месяцев)(14:39:32 / 04-01-2018)

Ну так и Машина Судного дня - тоже :)

Аватар пользователя Волшебник Вголубомвертолете

Похоже пора переходить на Qubes OS

Комментарий администрации:  
*** Отключен (лидер бан-рейтинга + нарушение договоренности под которые согласились оставить) ***

Страницы

Лидеры обсуждений

за 4 часаза суткиза неделю

Лидеры просмотров

за неделюза месяцза год

СМИ

Загрузка...