@sysutil / 0x023DF34A0B878D69 🍷
5.06K subscribers
7 photos
1 file
6 links
Контакт для связи: sysutil@posteo.sg (актуально всегда)
GnuPG Key ID: ed25519/0x023DF34A0B878D69

PGP-ключ доступен в закрепленном посте.
Download Telegram
P.S. Даже базовые технические процессы в Exodus реализованы с вопиющей некомпетентностью: экспорт Monero-кошелька предоставляет только seed-фразу без указания блока создания, что приводит к проблемам с синхронизацией и балансом. Мне пришлось вручную искать свою первую транзакцию для корректного восстановления. Потрясающая забота о пользователе.

#криптовалюты #Monero #XMR #Exodus #децентрализация #приватность #безопасность #холодныекошельки

https://t.me/hiload/10
🍌226
🌫 Иллюзия безопасности: Почему большинство VPS/VDS систем компрометированы по умолчанию

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

Фундаментальные проблемы x86-архитектуры

Начнём с неприятной правды: 99% коммерческих VPS/VDS построены на фундаментально скомпрометированной архитектуре x86. Проблема не только в отдельных уязвимостях типа Spectre/Meltdown (хотя они прекрасно иллюстрируют глубину проблемы) — вся архитектура спроектирована без учета требований реальной изоляции.

При использовании стандартных x86-серверов гипервизор имеет полный доступ к памяти виртуальных машин. Это архитектурное решение, а не баг. В отличие от IBM POWER или IBM Z, где существует настоящая криптографическая изоляция VM, в x86 мире доступ к памяти — лишь вопрос привилегий.

😊 Интересный факт: В архитектуре IBM Z (начиная с z11) изоляция виртуальных машин реализована с использованием криптографических ключей, которые управляются не обычным BIOS, а нижележащим уровнем IBM Internal Code. Это даёт гарантии, которые в принципе невозможны на стандартных архитектурах.


Шифрование памяти: маркетинговые обещания vs. реальность

AMD и Intel активно рекламируют технологии "защиты памяти", но давайте посмотрим на них объективно:

AMD SME/TSME — технология прозрачного шифрования системной памяти. Звучит великолепно, работает... весьма условно. Главные проблемы:

1. Шифрование запускается только после инициализации оборудования и загрузки микрокода — критический временной промежуток остаётся незащищённым.

2. Реализация допускает DMA-атаки: устройства PCIe могут напрямую получать доступ к памяти в обход шифрования. Это не баг, а "фича" для совместимости с устройствами, которым нужен DMA-доступ.

3. Ключи шифрования генерируются процессором и потенциально могут быть извлечены через различные побочные каналы.


// Пример уязвимости: PCIe устройство с DMA-доступом может просто прочитать память
// Путь атаки примерно такой:
1. Хостер вставляет FPGA-карту в PCIe слот
2. Карта инициирует DMA-транзакцию, получая доступ к физической памяти
3. SME/TSME не блокирует эту транзакцию для "совместимости"
4. Игра окончена, данные извлечены


Intel TME/MKTME — аналогичная технология с аналогичными проблемами. Шифрование происходит после инициализации, ключи управляются недоверенным ПО, и DMA-устройства имеют прямой доступ.

😊 Отдельный "привет" всем, кто считает, что если у него "VPS с включенным AMD SME", то его данные в безопасности. Провайдер с физическим доступом к серверу будет читать вашу память так же легко, как страницу из книги.


Jintide: как китайцы решают проблему по-настоящему

В отличие от полумер американских гигантов, китайский подход гораздо интереснее. Intel Jintide — это специализированные процессоры, созданные по заказу правительства КНР. Я изучал эту архитектуру достаточно подробно и могу сказать: это совсем другой уровень безопасности.

Ключевые отличия Jintide от стандартных процессоров:

1. Физическое разделение: помимо основного процессора, на подложке размещены два дополнительных чипа-аудитора, которые физически контролируют доступ к памяти.

2. Криптографическая защита с нулевого такта: шифрование памяти включается до инициализации основной системы — нет окна для атаки.

3. Контроль DMA: чипы-аудиторы контролируют все DMA-транзакции, блокируя несанкционированные доступы. PCIe DMA-dumper просто не получит доступа.

4. Кастомные модули памяти: в системах Jintide используются специальные RDIMM-модули с аппаратной поддержкой шифрования.

5. Встроенная поддержка китайских криптографических алгоритмов: SM2/SM3/SM4 вместо потенциально скомпрометированных западных аналогов.
Please open Telegram to view this post
VIEW IN TELEGRAM
🍌247
@sysutil / 0x023DF34A0B878D69 🍷
🌫 Иллюзия безопасности: Почему большинство VPS/VDS систем компрометированы по умолчанию На днях попалась интересная дискуссия о безопасности виртуальных серверов. Как обычно - океан поверхностных рассуждений и минимум понимания архитектурных проблем. Давайте…
Результат? Даже имея физический доступ к серверу, извлечь данные из памяти практически невозможно. Конечно, достать такое железо крайне сложно — оно в 3 раза дороже обычного и поставляется только после серьезного KYC, преимущественно для правительственных структур.

BMC: скрытая точка входа

Отдельная проблема, о которой редко говорят — это Baseboard Management Controller (BMC). Этот маленький независимый компьютер, встроенный в ваш сервер, имеет привилегированный доступ ко всему железу, включая память, даже когда основная система выключена.

Объем памяти BMC сильно ограничен (обычно это слабенький ARM Cortex-A5), но в теории он может служить точкой для закрепления в системе. Более того, в большинстве дата-центров BMC подключены к отдельной управляющей сети, что создает дополнительный вектор атаки.

OpenBMC немного улучшает ситуацию с прозрачностью, но не решает фундаментальную проблему: привилегированный контроллер с доступом ко всему железу, работающий независимо от основной ОС.

Что делать, если нужна реальная безопасность?

Если вам действительно нужна изоляция данных:

1. Забудьте про x86. IBM POWER9+ или IBM Z — единственные массовые архитектуры с настоящей криптографической изоляцией между VM.

2. Операционная система имеет значение. OpenBSD на IBM POWER — комбинация, для которой найти эксплойт практически невозможно из-за непопулярности и высокого качества кода OpenBSD.

3. Если застряли на x86: отключите все порты PCIe с hot-plug, Thunderbolt и другие DMA-интерфейсы; используйте физически контролируемое оборудование вместо VPS.

😊 Интересный факт: Существуют процессоры Intel Itanium, которые из-за своей архитектурных особенностей не подвержены Spectre/Meltdown и подобным атакам на спекулятивное исполнение. Они не решают проблему шифрования памяти, но демонстрируют, как архитектурные решения могут принципиально влиять на безопасность. Правда, найти современные серверы на Itanium сейчас практически невозможно — Intel прекратила их производство в 2021 году.


🍿 Заключение

Стандартный VPS/VDS на x86 архитектуре — это удобно и дешево, но с точки зрения безопасности это примерно как хранить ценные вещи в картонной коробке с надписью "Не открывать".

Провайдеры, рекламирующие "защищенные" VPS с TSME или другими технологиями шифрования памяти, продают иллюзию безопасности. Реальная изоляция возможна только с архитектурными решениями уровня IBM POWER/Z или специализированными системами вроде Jintide.

В конечном счете, как всегда, вы получаете то, за что платите. Хотите настоящую безопасность — готовьтесь к настоящим затратам. Остальное — маркетинговый туман.

#Безопасность #VPS #Виртуализация #IBMPower #Jintide #КитайскиеТехнологии #ШифрованиеПамяти #DMA_уязвимости #x86_проблемы

https://t.me/hiload/12
Please open Telegram to view this post
VIEW IN TELEGRAM
🍌252
$BTC = 110K USD. Всем спасибо, всех поздравляю 🍷

P.S. В ближайшее время будет очередной большой пост, ожидаю положительной отдачи от вас на него.
Please open Telegram to view this post
VIEW IN TELEGRAM
🍌149
Христос Воскресе 🥚
🍌162
Как же круто, что из-за отдельных нытиков, которые админят серверы через дисплей домофона, htop по стандарту прячет поядерную нагрузку, стоит числу потоков перевалить за 128.

Пик2 – текущий дефолт

Пик3 – как мне пришлось перенастроить в никс конфиге, чтобы данная чудо-утилита реально была полезной, лол.

Мне интересно кому и зачем реально нужно в htop видеть ТОЛЬКО Avg нагрузку? Это же буквально неудобно для отладки.

Пик1 – комментарий человека, который видимо никогда не сталкивался с проблемами, возникающими из-за того, что ПО загоняет одно ядро в сотку, пока остальные простаивают. По его версии, поядерная разбивка нужна только «ricers'ам для красивых скриншотов» – то есть реальный сценарий отладки он на серьёзных щах записал в понты.
🍌206
https://github.com/J-jaeyoung/bad-epoll
https://nvd.nist.gov/vuln/detail/CVE-2026-46242

Линух стабильно доказывает, что если вам важна безопасность, то это не к нему.

И если про предыдущие находки хотя бы можно было сказать, что они касаются только идиотов, которые не занимаются харденингом, то тут уже такое не сработает. Потому что проблема касается буквально всех: epoll – это не act_pedit, загрузку которого можно отключить на 99.9% машин и забыть, потому что он нахуй никому не нужен. epoll – базовый механизм ядра, без которого не работает (почти) вся асинхронная сеть Linux.

Это вам знак, что давно пора переходить на OpenBSD или z/OS.
🍌247
@sysutil / 0x023DF34A0B878D69 🍷
https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731
Это уже мы протестировали и результаты потрясающие. У нас получилось выжать 400-500 TPS под вполне продакшн нагрузками. Самое приятное – kv cache. DeepSeek настоящие инноватары, делают по истине новые архитектуры, где максимально задрачивают оптимизацию. В итоге 1 млн контекста в DeepSeek V4 Flash требует 10-15гб ОЗУ (если верно помню), тогда как на той же GLM-5.2 1 млн контекста требует аж 180гб ОЗУ. Разница в 18 РАЗ.
🍌366
@sysutil / 0x023DF34A0B878D69 🍷
https://huggingface.co/unsloth/GLM-5.3-Flash
https://huggingface.co/Qwen/Qwen3.8-Flash-Next
Сейчас будем заниматься тестированием этих моделей ✌️

По GLM-5.3-Flash уже немного есть что сказать:

1. Это микс архитектуры DSV4F + Kimi K3.
2. По KV Cache за счет понятно чьих заслуг все прекрасно.
3. Главный вопрос в данный момент – наличие prefix caching, именно это будет решающим моментом. От этого зависит возможность оффлоада кв кэша в ОЗУ. У Kimi K3, например, на релизе с этим были проблемы.

Что касательно Qwen3.8-Flash-Next:

Выглядит ОЧЕНЬ многообещающе. По бенчмаркам это уровень DeepSeek-V4-Flash-0731, который на уровне GLM-5.2 (а GLM-5.2 > Opus 4.8, если кто забыл) в кодинге, но Qwen3.8-Flash-Next ЗНАЧИТЕЛЬНО компактнее и ключевое тут не в тотал параметрах, а активных – всего 6 миллиардов, тогда как у DSV4F их 13 миллиардов. За счет этого Qwen3.8-Flash-Next будет в РАЗЫ быстрее, но при этом качество должно быть такое же. Это предстоит проверить. Иметь модель для кодинга со скоростью 1000 TPS – давняя моя цель.
🍌386
@sysutil / 0x023DF34A0B878D69 🍷
3. Главный вопрос в данный момент – наличие prefix caching, именно это будет решающим моментом. От этого зависит возможность оффлоада кв кэша в ОЗУ. У Kimi K3, например, на релизе с этим были проблемы.
Работает, но из-за HiCache скорости упали ☕️

Попробуем исправить, потестим разные стратегии кэша, скорее всего проблема в довольно неэффективном для большинства железа дефолте, он рассчитан под GB300, а я GB300 доставку пока только жду 🥲
Please open Telegram to view this post
VIEW IN TELEGRAM
🍌243