Немного туп(л,)

💥 Следом за Сасово прилетело по ДЦ Яндекса в Калуге. Минус два из трёх.

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

Оцените всю дьявольскую издевку ситуации 👹... ровно вчера, когда в Сасово догорал, техподдержка Яндекса советовала клиентам переносить нагрузку в другие зоны доступности. И тысячи невыспавшихся админов по всей стране, с красными глазами 🤙, раскатывали бэкапы, поднимали поды и переключали трафик… куда? В Калугу и Владимир. И вот, не успел в свежеподнятых базах остыть кэш, как резервная гавань сама ловит новый физический импакт.

С точки зрения архитектуры распределенных систем это почти фаталити... любой эникей знает, что для нормального кворума в etcd, распределенной YDB или консенсусах на базе Raft и Paxos требуется правило большинства (N/2 + 1). Для этого региональные облака и строят минимум на трех изолированных зонах доступности. Зона ru-central1-b физически аннигилировала вчера. Сегодня падает калужская зона. Два узла из трех выбыли.

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

З.Ы. В строю осталась последняя площадка во Владимире. Инженерам во Владимирской области сейчас хочется пожелать персонального бронированного купола толщиной с бетонную плиту. Потому что если моргнет и Владимир... ⚰️

Типичный 🥸 Сисадмин

Рунет: чем централизованнее, тем уязвимее.

Удар по дата‑центру Яндекса побудил многих «околовоенных» экспертов высказаться на темы, близкие к кибербезу.
Давайте мы, как профильный канал, тоже прокомментируем эту тему.

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

Проект централизации первично децентрализованной технологии «Интернет» выполнялся по различным причинам — их мы обсуждать в этом посте не будем. Но фактически успех этого проекта привёл к тому, что буквально на около десятка дата‑центров в европейской части России завязано функционирование примерно всего Рунета.

Поэтому, господа военные эксперты: может, суммарно дата‑центров у нас и сотни по всей стране, может, и очень крупных много. Но вывести из строя нужно гораздо меньше, и они вовсе не на Камчатке. Их нужно питать, обслуживать, обеспечивать логистикой. Они все в полётной доступности средств поражения по вполне прагматичным причинам.

Могут ли облачные провайдеры быстренько «переехать» в безопасные дружественные страны?

Конечно, нет. 152‑ФЗ («О персональных данных») жёстко ограничивает в этом, а 187‑ФЗ (регулирующий безопасность критической информационной инфраструктуры) вводит прямо запрет на зарубежные облака и SaaS‑сервисы.

Централизация тут однозначно стреляет нам в ногу: в плане физического поражения инфраструктуры мы стали уязвимее.

LPE эти массовые надоели, так что ажно Эрик Биггерс (Eric Biggers) патч сделал

crypto: af_alg - Remove zero-copy support from skcipher and aead
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=ffdd2bc378953b525aca61902534e753f1f8e734

The zero-copy support is one of the riskiest aspects of AF_ALG. It allows userspace to request cryptographic operations directly on pagecache pages of files like the 'su' binary. It also allows userspace to concurrently modify the memory which is being operated on, a recipe for TOCTOU vulnerabilities.

While zero-copy support is more valuable in other areas of the kernel like the frequently used networking and file I/O code, it has far less value in AF_ALG, which is a niche UAPI. AF_ALG primarily just exists for backwards compatibility with a small set of userspace programs such as 'iwd' that haven't yet been fixed to use userspace crypto code.

Originally AF_ALG was intended to be used to access hardware crypto accelerators. However, it isn't an efficient interface for that anyway, and it turned out to be rarely used in this way in practice.

Thus, the risks of the zero-copy support in AF_ALG vastly outweigh its benefits. Let's just remove it.

This commit removes it from the "skcipher" and "aead" algorithm types. "hash" will be handled separately.

This is a soft break, not a hard break. Even after this commit, it still works to use splice() or sendfile() to transfer data to an AF_ALG request socket from a pipe or any file, respectively. What changes is
just that the kernel now makes an internal, stable copy of the data before doing the crypto operation. So performance is slightly reduced, but the UAPI isn't broken. And, very importantly, it's much safer.

Tested with libkcapi/test.sh. All its test cases still pass. I also verified that this would have prevented the copy.fail exploit as well. I also used a custom test program to verify that sendfile() still works.

Патч, видимо, в 7.2 прилетит.

..............................
......./\............/\.......
....../  \__________/  \......
...../      (o)(o)      \.....
....(        =ww=        )....
.....\       /--\       /.....
......\________________/......
..............................

новый формат мемов. загружаются даже на парковке