Любых. Рабочие станции отказывают реже, но они распределены по офису. Ноутбуки могут залить или стукнуть. В серверах под нагрузкой изнашиваются диски, память, система охлаждения. Не обязательно каждый сбой выражается в полной неработоспособности машины — если вылетел один диск из RAID, ECC исправила один бит в слове памяти, заклинил один кулер из восьми, система продолжит функционировать и дальше; но почти всегда они требуют вмешательства человека.
Если у каждого из 3600 сотрудников есть по одному ноутбуку, сотрудники нанимались равномерно по времени, а срок жизни машины — 3 года, то это около 10 замен в день. На разборку ноутбуков, замену диска, манипуляции с криптосистемой уйдёт половина рабочего дня. Остальное время уйдёт на то, чтобы исследовать и описать проблемы, подготовить технику для отправки производителю, восстановить ОС в случае замены накопителя. И это мы ещё не рассматривали программные проблемы.
Если помер сервер, то куда быстрее заменить тот конкретный компонент, который вышел из строя, чем демонтировать его, отправлять производителю и покупать новый. Чтобы сервера отказывали каждый день, достаточно всего 2500-3000 серверов. Это не так много, учитывая потребности антивирусных исследователей — им нужны виртуальные окружения, в которых можно отслеживать поведения malware.
Даже если оборудование не выходит из строя, его требуется модернизировать, устанавливать новые сервера, апгрейдить сеть, инженерные системы (охлаждение, электропитание).
Согласен. Я просто предположил, что раз ifap спросил про Bitlocker, то его в первую очередь интересуют обычные десктопы. Про удалённую аттестацию Windows-машин я никогда ничего не слышал, и если такая бывает, то было бы интересно об этом узнать.
Но владельцу машины не нужно ломать свой TPM физически, ведь он сам его себе поставил для Bitlocker. А если у атакующего есть физический доступ, то никакой TPM не спасёт, и дело тут будет уже не в скорость шины — он сможет просто захватить секрет непосредственно с устройства ввода, а затем с него же введёт в запущенную систему полезную нагрузку.
На такой вопрос сложно дать чёткий объективный ответ. Большинство патчей ломают различные механизмы, ускоряющие выполнение программ на CPU в момент переключения (context switch) между прикладным приложением и ядром ОС. Наиболее популярные причины таких переключений — прерывание от внешнего устройства, прерывание от таймера, системный вызов. Таким образом, всё зависит от того, как вы свою систему нагружаете — сколько одновременно запущено потоков/процессов, какую минимальную частоту таймера они запрашивают, как часто делают системные вызовы.
Объективно можно лишь измерить изменение производительности очень конкретной нагрузки.
Чтобы решить эти проблемы, достаточно законодательно разрешить пользователям (легально приобретённого продукта) взламывать любые защиты в своём софте и распространять свои патчи.
Довольно странное сравнение. Существенная часть пунктов сводится к «фича X в *BSD есть уже давно, а в GNU/Linux только что появилась». Часть пунктов рассматривают Linux, как ядро с kernel.org, часть — дистрибутивы, остальные — весь существующий юзерспейс. Кажется, будет правильнее взять какой-нибудь один дистрибутив, и сравнивать FreeBSD (а не все существующие *BSD-системы) с ним.
Если хочется получить целостную систему, с централизованным управлением всем подряд, стоит попробовать NixOS. Там практически всё можно настроить в /etc/nixos/configuration.nix (какой-то пример с GitHub), прямо как в rc.conf. И бинарные пакеты (cache.nixos.org) прозрачно сосуществуют со сборкой из исходников, если где-то нужна кастомизация. А как сейчас обстоят дела во FreeBSD с одновременным использованием портов и пакетов?
Аргумент с ipfw мне не очень понятен — в GNU/Linux давно есть iproute2, в который входят все необходимые утилиты для настройки адресов, маршрутов, очередей. Фаервол можно настроить с помощью nftables (пример).
Аналогом GEOM действительно является device-mapper. Там есть и RAID (dm-raid), и более сложные топологии.
Аналога netgraph в таком же виде действительно нет. Но для простых задач можно обойтись и специфичными инструментами (тот же nftables, bridge/vlan filtering, netns, pppd/l2tpd/bluetoothd/...), а для сложных есть Open vSwitch.
Про трассировку много рассказать не смогу, но из быстрых работающих механизмов есть ftrace через debugfs и возможность навешывать bpf-программы в самые разные места. Для решения многих вопросов хватает tools/perf из ядра.
Кстати, а как так получается, что можно собрать систему без IPv4? Я сходу не могу придумать, как красиво отвязать реализацию TCP от IP (проблемы должны возникнуть, например, при вычислении pseudoheader checksum).
А как же xmonad? Больше 10 лет назад это был единственный WM, который я смог настроить на своём ноуте с Intel GPU, чтобы окна правильно располагались на двух мониторах разного разрешения, которые не объединяются в прямоугольную область (1366x768+1280x800).
CVE-2019-3462: злоумышленник может воспользоваться уязвимостью в apt-transport, и выполнить произвольный код на машине под рутом. Так что не избыточен.
способностей старых компьютеров обрабатывать прерывания от сетевой карты
ограничений на длину кабеля и излучаемую мощность
доля служебной информации
пропускной способности
Из (2) мы получаем минимальное время фрейма для коллизионного домена. Теперь представим коллизионный домен, в котором нас интересуют два компьютера — один очень активно передаёт много фреймов максимального размера, а второй хочет вклиниться в поток и передавать фреймы минимального размера. Чем меньше MTU, тем меньше в худшем случае ему придётся ждать.
Но при этом слишком маленькие значения MTU будут делать обработку данных слишком дорогой из-за (1), а также увеличивать (3), снижая долю полезной информации.
Если мы потребуем от узлов в 10Мбит/с-сети интерактивности в 1мс, то получим MTU=1212. Однако, в сетевых адаптерах тех времён присутствует специальный предохранитель между MAC и PHY, не позволяющий захватить коллизионный домен на слишком долгое время в случае залипания MAC в состоянии бесконечной отправки. Возможно, использование максимального времени фрейма в 1.2304мс вместо 1мс можно объяснить несовершенством настройки этого предохранителя.
Чем проблема романтических отношений отличается от любых других особенностей, мешающих человеку выполнять свою работу? Скажем, от неспособности человека сосредоточиться на задаче («эффективно работать»), если рядом есть кто-то в красной футболке.
А какие гарантии может предложить (например) RUVDS для защиты кода, данных и потоков исполнения (control flow) от любопытных сотрудников хостинговой компании? Сколько эти гарантии могут стоить?
Ведь, фактически, размещая сайт у хостера, вебмастер передаёт контроль чужому серверу.
А если разделить контент так, чтобы A отдавал его через два узла, B1 и B2, но так, чтобы было невозможно было:
1) доказать сговор A, B1 и B2;
2) из информации, полученной только от B1 или только от B2, невозможно было бы восстановить контент?
То есть создать ситуацию, когда контент появляется только на узле C в результате обработки данных, полученных от B1 и B2.
Если я правильно понимаю, с выходными узлами TOR ситуация несколько отличается, так как для их функционирования они вынуждены собрать весь контент у себя. А вот были ли случаи преследования именно транзитных узлов? Ведь очень уж привлекательная цель для тов. Майора получается — включаем на локалхосте запись трафика, получаем от hidden service'а запрещённый контент, а все, кто попали в запись — распространители.
А что если обеспечить plausible deniability следующим образом — в машину ставится три диска, a, b и c. Диск a шифруется традиционным образом, а блоки дисков b и c вычисляются таким образом, чтобы a XOR b XOR c давало какой-то осмысленный результат, например ОС с законным содержимым.
Такую «криптосистему» можно сделать настолько компактной и простой, что с целью необнаружения пользователь будет вводить её в память машины по памяти каждый раз при запуске. А в случае вопросов будет говорить, что использует экзотический вариант RAID0 для ускорения записи, где все диски зашифрованы, (для определённости) диск b является ключём, который он конечно же передаст законному представителю и покажет, как вычислить XOR для расшифровки ОС.
Практически в любой файлообменной схеме человек так или иначе платит за хранение данных. Где-то используются обычные деньги, где-то реклама, где-то — ресурсы компьютера.
Если не хочется думать про деньги и проверяющих, то можно скрыть все эти сущности от конечного пользователя, сделав удобную программу, которая тратит на диске, например, 1.2 * n * X места, позволяя сохранить «в облаке» X данных в n экземплярах. 5% случайных пользователей после накопления средств на кошельке превращать в проверяющих, а кошельки остальных передавать автору такой программы. Тогда будет почти как с BitTorrent — вот кнопка «скачать», но по возможности не закрывайте клиент как можно дольше, чтобы всё было хорошо.
А как он (пусть контролирующий узел C) отличит транзитный трафик от целевого? Скажем, если узел A содержит копию контента, но отдаёт его через B, шифруя так, чтобы у B не было возможности определить его легальный статус, а C расшифровывает, не зная, где находится узел A.
Такую схему можно реализовать даже с эффективным кешированием, если распространять симметричные ключи блоков отдельно от самих блоков данных.
Если у каждого из 3600 сотрудников есть по одному ноутбуку, сотрудники нанимались равномерно по времени, а срок жизни машины — 3 года, то это около 10 замен в день. На разборку ноутбуков, замену диска, манипуляции с криптосистемой уйдёт половина рабочего дня. Остальное время уйдёт на то, чтобы исследовать и описать проблемы, подготовить технику для отправки производителю, восстановить ОС в случае замены накопителя. И это мы ещё не рассматривали программные проблемы.
Если помер сервер, то куда быстрее заменить тот конкретный компонент, который вышел из строя, чем демонтировать его, отправлять производителю и покупать новый. Чтобы сервера отказывали каждый день, достаточно всего 2500-3000 серверов. Это не так много, учитывая потребности антивирусных исследователей — им нужны виртуальные окружения, в которых можно отслеживать поведения malware.
Даже если оборудование не выходит из строя, его требуется модернизировать, устанавливать новые сервера, апгрейдить сеть, инженерные системы (охлаждение, электропитание).
При достаточно большом парке машин вероятность того, что абсолютно все в какой-то конкретный момент времени полностью исправны будет очень маленькой.
Объективно можно лишь измерить изменение производительности очень конкретной нагрузки.
Нет, потому что можно написать свою альтернативную реализацию battle.net или хотя бы прокси к существующей.
Если хочется получить целостную систему, с централизованным управлением всем подряд, стоит попробовать NixOS. Там практически всё можно настроить в /etc/nixos/configuration.nix (какой-то пример с GitHub), прямо как в rc.conf. И бинарные пакеты (cache.nixos.org) прозрачно сосуществуют со сборкой из исходников, если где-то нужна кастомизация. А как сейчас обстоят дела во FreeBSD с одновременным использованием портов и пакетов?
Аргумент с ipfw мне не очень понятен — в GNU/Linux давно есть iproute2, в который входят все необходимые утилиты для настройки адресов, маршрутов, очередей. Фаервол можно настроить с помощью nftables (пример).
Аналогом GEOM действительно является device-mapper. Там есть и RAID (dm-raid), и более сложные топологии.
Аналога netgraph в таком же виде действительно нет. Но для простых задач можно обойтись и специфичными инструментами (тот же nftables, bridge/vlan filtering, netns, pppd/l2tpd/bluetoothd/...), а для сложных есть Open vSwitch.
Про трассировку много рассказать не смогу, но из быстрых работающих механизмов есть ftrace через debugfs и возможность навешывать bpf-программы в самые разные места. Для решения многих вопросов хватает tools/perf из ядра.
Кстати, а как так получается, что можно собрать систему без IPv4? Я сходу не могу придумать, как красиво отвязать реализацию TCP от IP (проблемы должны возникнуть, например, при вычислении pseudoheader checksum).
Из (2) мы получаем минимальное время фрейма для коллизионного домена. Теперь представим коллизионный домен, в котором нас интересуют два компьютера — один очень активно передаёт много фреймов максимального размера, а второй хочет вклиниться в поток и передавать фреймы минимального размера. Чем меньше MTU, тем меньше в худшем случае ему придётся ждать.
Но при этом слишком маленькие значения MTU будут делать обработку данных слишком дорогой из-за (1), а также увеличивать (3), снижая долю полезной информации.
Если мы потребуем от узлов в 10Мбит/с-сети интерактивности в 1мс, то получим MTU=1212. Однако, в сетевых адаптерах тех времён присутствует специальный предохранитель между MAC и PHY, не позволяющий захватить коллизионный домен на слишком долгое время в случае залипания MAC в состоянии бесконечной отправки. Возможно, использование максимального времени фрейма в 1.2304мс вместо 1мс можно объяснить несовершенством настройки этого предохранителя.
Ведь, фактически, размещая сайт у хостера, вебмастер передаёт контроль чужому серверу.
1) доказать сговор A, B1 и B2;
2) из информации, полученной только от B1 или только от B2, невозможно было бы восстановить контент?
То есть создать ситуацию, когда контент появляется только на узле C в результате обработки данных, полученных от B1 и B2.
Если я правильно понимаю, с выходными узлами TOR ситуация несколько отличается, так как для их функционирования они вынуждены собрать весь контент у себя. А вот были ли случаи преследования именно транзитных узлов? Ведь очень уж привлекательная цель для тов. Майора получается — включаем на локалхосте запись трафика, получаем от hidden service'а запрещённый контент, а все, кто попали в запись — распространители.
Такую «криптосистему» можно сделать настолько компактной и простой, что с целью необнаружения пользователь будет вводить её в память машины по памяти каждый раз при запуске. А в случае вопросов будет говорить, что использует экзотический вариант RAID0 для ускорения записи, где все диски зашифрованы, (для определённости) диск b является ключём, который он конечно же передаст законному представителю и покажет, как вычислить XOR для расшифровки ОС.
Если не хочется думать про деньги и проверяющих, то можно скрыть все эти сущности от конечного пользователя, сделав удобную программу, которая тратит на диске, например, 1.2 * n * X места, позволяя сохранить «в облаке» X данных в n экземплярах. 5% случайных пользователей после накопления средств на кошельке превращать в проверяющих, а кошельки остальных передавать автору такой программы. Тогда будет почти как с BitTorrent — вот кнопка «скачать», но по возможности не закрывайте клиент как можно дольше, чтобы всё было хорошо.
Такую схему можно реализовать даже с эффективным кешированием, если распространять симметричные ключи блоков отдельно от самих блоков данных.