The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Уязвимость, позволяющая обойти механизм защиты Intel TDX"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от opennews (??), 11-Фев-26, 12:41 
Компании Google и Intel раскрыли результаты (PDF) совместной работы по аудиту безопасности  механизма  Intel TDX 1.5 (Trusted Domain Extensions). Технология Intel TDX реализует возможность шифрования памяти виртуальных машин для их защиты от вмешательства и анализа со стороны администратора хост-системы и физических атак на оборудование. В результате аудита выявлено 6 уязвимостей и 35 не влияющих на безопасность ошибок...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=64774

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


3. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +4 +/
Сообщение от Sorlag (?), 11-Фев-26, 12:47 
>Проблема вызвана возможностью подмены атрибутов окружения в момент после прохождения их проверки

Как будто что-то новое)
Заказчик никогда не узнает, кто получил его данные и как, ведь у него всё «изолировано».
Причем внесли поддержку TDX в Linux в 2022 году ещё, а мелкомягкие в азуру в 2023 ещё и похвастались ;)

Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +6 +/
Сообщение от 1 (??), 11-Фев-26, 13:48 
Согласен, постоянно виртуализацию и контейнеры приравнивают к безопасности.  Какое-то массовое помешательство.
Эльбрус наше всё.)
Ответить | Правка | Наверх | Cообщить модератору

88. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Пень (?), 11-Фев-26, 21:40 
А как эльбрус с виртуализацией и безопасностью, или ты думаешь что там нет уязвимостей
Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +2 +/
Сообщение от Pahanivo (ok), 11-Фев-26, 21:46 
А как может быть там с безопасностью, если нет самих процессоров )))
Ответить | Правка | Наверх | Cообщить модератору

95. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Tron is Whistling (?), 11-Фев-26, 22:58 
Самый безопасный процессор в мире: нет процессора - нет уязвимостей.
Ответить | Правка | Наверх | Cообщить модератору

106. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (106), 12-Фев-26, 05:00 
А ты докажи что есть!
Ответить | Правка | Наверх | Cообщить модератору

125. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Tron is Whistling (?), 12-Фев-26, 12:29 
Что есть-то? Процессоры?
Ответить | Правка | Наверх | Cообщить модератору

101. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (101), 12-Фев-26, 01:48 
Мне кажется ты не разобрался. Было исследование, которое показало, что использование контейнеров позволяет существенно повысить безопасность в некоторых сценариях.
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

118. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (118), 12-Фев-26, 09:20 
Не разобрался ты. Использование chroot, контейнеров, виртуалок позволяет ДЕШЕВО и удобно ликвидировать некоторые сценарии распространения заражения. Но ГАРАНТИЙ безопасности не даёт.
Ответить | Правка | Наверх | Cообщить модератору

117. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (118), 12-Фев-26, 09:17 
Виртуализация и контейнеры разрабатывались как удобное инструменты администрирования и продажи хостерами ресурсов многоядерных систем, а не как системы безопасности.

Изоляция в контейнере есть, а в виртуалке изоляции ещё больше. Есть уже виртуализация сфокусированная именно на безопасность и максимальную изоляцию.

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

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

4. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +3 +/
Сообщение от Аноним (4), 11-Фев-26, 12:51 
С каких пор оно защищает от физических атак? Студенты с осцилографом за тысячу баксов ломают (https://tee.fail). Только от злого админа на хост машине есть хоть какая то защита.
Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +2 +/
Сообщение от Аноним (6), 11-Фев-26, 12:53 
> С каких пор оно защищает от физических атак?

А где там написано про физические атаки?

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

Ответить | Правка | Наверх | Cообщить модератору

11. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +2 +/
Сообщение от Аноним (4), 11-Фев-26, 13:14 
Поискал бы хоть по странице. Технология Intel TDX реализует возможность шифрования памяти виртуальных машин для их защиты от вмешательства и анализа со стороны администратора хост-системы <b>и физических атак на оборудование.</b>
Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  –2 +/
Сообщение от Аноним (25), 11-Фев-26, 13:54 
Почитал бы внимательнее. Технология Intel TDX реализует возможность шифрования памяти виртуальных машин для их защиты от <b>вмешательства и анализа со стороны администратора хост-системы</b> и физических атак на оборудование.
Ответить | Правка | Наверх | Cообщить модератору

96. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Tron is Whistling (?), 11-Фев-26, 22:59 
Что мешает проэмулировать этот TDX на уровне гипервизора?
Ответить | Правка | Наверх | Cообщить модератору

104. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (104), 12-Фев-26, 04:09 
следующие факты:
1. эти инструкции kvm не умеет эмулировать - требует аппаратную поддержку;
2. перед стартом защитный софт запросит подтверждение полной цепочки sec.boot/uboot;
3. сертификаты тоже проверит - должен быть исключительно исключительно твоей корпы. Хотя ленивым и црушный норм (только не надо потом удивляться тусовке *китайских эй-пи-ти* в твоём ME);
4. но если и этого мало, гость может подписаться на подтверждение валидности регистров с цепочки доверия через внешний онлайн-сервер - а вот как этот этап обойти на практике я пока хз
Ответить | Правка | Наверх | Cообщить модератору

111. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Пуп (?), 12-Фев-26, 06:15 
Ключи в секур бут майкрософта надеюсь?
Ответить | Правка | Наверх | Cообщить модератору

124. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Tron is Whistling (?), 12-Фев-26, 12:28 
> 1. эти инструкции kvm не умеет эмулировать - требует аппаратную поддержку;

Не умеет - научим.

> 2. перед стартом защитный софт запросит подтверждение полной цепочки sec.boot/uboot;

У кого потребует-то? У гипервизора?

> 3. сертификаты тоже проверит - должен быть исключительно исключительно твоей корпы. Хотя
> ленивым и црушный норм (только не надо потом удивляться тусовке *китайских
> эй-пи-ти* в твоём ME);

Понимаешь, сертификаты кто-то должен загрузить в TSX сначала.

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

См. (3)

Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

105. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (101), 12-Фев-26, 04:09 
Попробуй перечитать то что написано. Там всё понятно.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

103. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (103), 12-Фев-26, 02:25 
То не осцилограф. И стоит он далеко не 1000 баксов. За 1000 баксов даже кабель для подключения к DDR5 тебе не продадут.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

5. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +4 +/
Сообщение от Аноним (-), 11-Фев-26, 12:51 
Мде....

Ладно "целочисленное переполнение" и "чтение из области памяти вне выделенного буфера" это просто наследие используемых недоязыков из прошлого тысячелетия. Как "состояние гонки" в общем-то тоже.

Но 6лuн - "использование не инициализированных переменных" - неужели настолько сложно запретить их создание?
Хотя бы флагами компилятора.

Ответить | Правка | Наверх | Cообщить модератору

10. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  –1 +/
Сообщение от Круз (?), 11-Фев-26, 13:11 
> Но 6лuн - "использование не инициализированных переменных" - неужели настолько сложно запретить их создание?

Ещё скажи что си должен явно такое запрещать, а не делать из этого UB, ведь количество потенциальных оптимизаций на базе этого можно слепить огромное

Ответить | Правка | Наверх | Cообщить модератору

14. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (14), 11-Фев-26, 13:19 
> Ещё скажи что си должен явно такое запрещать,

Нет конечно! Убогий язык должен быть убогим во всем!
С другой стороны - флаг компилятора зачем-то придумали?

> а не делать из этого UB,

Ага. Можно же сделать хотя бы implementation defined

> ведь количество потенциальных оптимизаций на базе этого можно слепить огромное

А еще можно слепить целую кучу овнокода, про что мы собственно в новости и читаем.


Ответить | Правка | Наверх | Cообщить модератору

35. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  –1 +/
Сообщение от Аноним (35), 11-Фев-26, 15:27 
>Можно же сделать хотя бы implementation defined

Есть ровно нуль разницы между undefined и implementation defined.

Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (44), 11-Фев-26, 16:31 
> Есть ровно нуль разницы между undefined и implementation defined.

Брехня. Разница огромная.

implementation defined просто выполняется компилятором так, как в нем написано.

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

Ответить | Правка | Наверх | Cообщить модератору

54. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (54), 11-Фев-26, 18:16 
Мде... и эти объяснятели что-то еще про недо- и овно- языки говорят.
Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (57), 11-Фев-26, 18:24 
> Мде... и эти объяснятели что-то еще про недо- и овно- языки говорят.

Что не понял? Ну это не очень удивительно.
Пошлю как я тебя читать так называемый стандарт 9899:1999

Начнем с раздела 3. Terms, definitions, and symbols
3.4.1
1 implementation-defined behavior
unspecified behavior where each implementation documents how the choice is made
Вот что тебе не ясно в "each implementation documents how the choice is made" ?

А вот что по поводу UB:
3.4.3
1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
for which this International Standard imposes no requirements

C отличным уточнением
2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

В общем unpredictable results гроб-гроб-кладбище.
Компилятор может сделать всё что угодно.
Выдать рут хакеру, сдлелать rm -rf весь твой прон, или пошутить про твою мамку.

Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +1 +/
Сообщение от Аноним (57), 11-Фев-26, 18:33 
А если ты сможешь включить межушный ганглий и прочитать определения, то джобро пожаловать в подвал - в аппендикс J.2 Undefined behavior.

Там всего лишь на 13 страницах расписываются способы "как отстрелить себе ногу по самую ж0пу".
Шикарный ʼтипа стандартʼ: "Мы не знаем как сложить два инта, пусть будет UB".

Что забавно - J.3 Implementation-defined behavior - всего 7 страничек.

Но мякотка (и судя по коду не фруктовая) в другом.
А что происходит если в программе есть UB?

А на это вопрос отвечает раздел 4. Conformance
5 A strictly conforming program shall use only those features of the language and library
specified in this International Standard. 2) It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior, and shall not exceed any
minimum implementation limit.

В общем если у тебя есть UB (например сложение 2 интов) то твоя программа прератилась в  ̶к̶у̶с̶о̶к̶ ̶к̶а̶л̶а̶ не strictly conforming program.

Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

46. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (46), 11-Фев-26, 17:20 
Implementation defined = реализация (компилятор и стандартная библиотека) должны определить и задокументировать поведение. Разные реализации могут по-разному определять поведение, но для каждой конкретной реализации поведение фиксировано, и код может на него полагаться.

Undefined behavior = неопределённое поведение. Реализации вправе рассчитывать, что корректная программа не содержит неопределенного поведения и не обязаны давать какие-либо гарантии для такого кода.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

112. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Пуп (?), 12-Фев-26, 06:18 
То-есть реализации в праве рассчитывать что корректная си программа не содержит сложения двух чисел?
Ответить | Правка | Наверх | Cообщить модератору

120. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Cooler (??), 12-Фев-26, 09:37 
UB возникает только при переполнении. Перед сложением двух интов, ты должен убедиться, что не возникнет переполнение. Ну или, как вариант, для GCC используй __builtin_add_overflow(...)
Ответить | Правка | Наверх | Cообщить модератору

127. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (127), 12-Фев-26, 12:41 
> Перед сложением двух интов, ты должен убедиться, что не возникнет переполнение.

Т.е. перед каждым суммирование нужно делать такую проверку.
Что-то не вижу их в сишных программах.

А если проверки нет, то гроб-гроб-кладбище.

> для GCC используй __builtin_add_overflow

Использовать ЕЕЕшные расширения для конкретного компилятора?
Классная идея! Что же может потом пойти не так...
И вообще странно что в такой классном язычке с таким офигенным стандартом нет такой функции элементарной функции.

Ответить | Правка | Наверх | Cообщить модератору

128. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (128), 12-Фев-26, 13:32 
> И вообще странно что в такой классном язычке с таким офигенным стандартом нет такой функции элементарной функции.

Справедливости ради, в C23 таки добавили <stdckdint.h>. Более полувека прошло, лол. Пользоваться им, конечно же, никто не будет...

Ответить | Правка | Наверх | Cообщить модератору

129. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Cooler (??), 12-Фев-26, 15:11 
Обычно складывают на абстрактные инты, взятые неизвестно откуда. А инты из предметной области. Ты же изначально должен в любом случае выбрать размер инта, в котором собираешься хранить некоторую величину. Также ты должен понимать, в какие пределы укладывается сумма твоих интов, или их произведение. Если ты хочешь гарантированно иметь Defined Behaviour, то используй арифметику бесконечной точности (GMP). Но это дополнительная потеря производительности. Не всегда она нужна, когда ты можешь гарантировать отсутствие переполнения. А как иначе вы предлагаете обрабатывать ситуации, когда сумма двух инт не помещается в разрядную сетку инт?
Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

64. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +2 +/
Сообщение от Аноним (64), 11-Фев-26, 18:58 
> Есть ровно нуль разницы между undefined и implementation defined.

Ахаха, абсолютно не удивлен, что сишники не знают разницу между undefined и implementation defined, описанными в стандарте))
А потом они садятся писать код и на выходе вот то самое получается.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

80. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +1 +/
Сообщение от Аноним (80), 11-Фев-26, 20:41 
> Ахаха, абсолютно не удивлен, что сишники не знают разницу между undefined и implementation defined, описанными в стандарте))

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

Ответить | Правка | Наверх | Cообщить модератору

113. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Пуп (?), 12-Фев-26, 06:19 
Если имплементации больше одной, то imp defined становится undefined.
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

55. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  –3 +/
Сообщение от Аноним (54), 11-Фев-26, 18:20 
А вот скажи - нафига ты пользуешься софтом и операционками, написанными на этих убогих языках?
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

62. Скрыто модератором  +/
Сообщение от Аноним (-), 11-Фев-26, 18:43 
Ответить | Правка | Наверх | Cообщить модератору

73. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +1 +/
Сообщение от Аноним (80), 11-Фев-26, 19:52 
> А вот скажи - нафига ты пользуешься софтом и операционками, написанными на этих убогих языках?

Ну, например, потому что этот "софт и операционки" решают какие-то мои задачи. Хочешь намекнуть, что этот факт делает С менее убогим языком, или что?

PS: Ты сильно расстроишься, узнав, что вот именно на С у меня нет практически никакого прикладного софта. Есть ядро Линукса, DE, да набор библиотек разной степени дырявости - а вот именно конечный софт на C++ и более адекватных языках.

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

107. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (106), 12-Фев-26, 05:05 
За пятьдесят лет других не придумали. Сейчас начали пытаться придумывать, но все почему-то недовольны. А пользоваться чем-то надо, деньги сами себя не заработают.
Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

70. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +2 +/
Сообщение от Аноним (80), 11-Фев-26, 19:30 
> Ладно "целочисленное переполнение" и "чтение из области памяти вне выделенного буфера" это просто наследие используемых недоязыков из прошлого тысячелетия.

Нет, не ладно. Когда софт, БУКВАЛЬНО ориентированный на обеспечение безопасности пишут на недоязыке, в котором все спроектировано (и стандартизировано) для компроментации этой самой безопасности - это какая-то дурка, ей богу.

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

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

74. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (74), 11-Фев-26, 19:57 
-Werror=uninitialized
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

83. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от НеИмя (?), 11-Фев-26, 20:57 
>"использование не инициализированных переменных" - неужели настолько сложно запретить их создание?

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

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

89. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (89), 11-Фев-26, 21:41 
> "использование не инициализированных переменных" - неужели настолько сложно запретить их создание?

То есть, разрешить создание переменных, которые уже инициализированны. Гениально.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

100. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  –2 +/
Сообщение от Аноним83 (?), 12-Фев-26, 00:48 
А вы хотя бы понимаете какое фрик шоу представляет из себя вся индустрия ИТ безопасности, и особенно те ультра фрики что носятся с безопасными ЯП?

Уже много раз писал: продаются в первую очередь сервисы. Не важно дырявые они и на каком языке написаны, главное что они делают то для чего созданы.
Бизнес платит за фичи, потому что пользователь за них платит.
С точки зрения пользователя не интересно что там внутри, ему всё равно на С или на расте или пхп это написано.

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


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

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

102. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (102), 12-Фев-26, 01:51 
> какое фрик шоу представляет из себя вся индустрия ИТ безопасности,

Да вот прям в этой новости читаем.

> и особенно те ультра фрики что носятся с безопасными ЯП?

Это кто? Гугл с амазоном? Нвидия с Мелкомягкими?

> Уже много раз писал: продаются в первую очередь сервисы. Не важно дырявые они и на каком языке написаны, главное что они делают то для чего созданы.

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

> Бизнес платит за фичи, потому что пользователь за них платит.

Пока в опенсорсе этого не понимают)

> С точки зрения пользователя не интересно что там внутри, ему всё равно на С или на расте или пхп это написано.

Ага.
Именно поэтому новые подходы в привносят не пользователи, а программисты.

> Вы тут обсуждаете малозначительные деффекты в реализации очень специализированного ПО,
> всё это мало кому интересно, даже тем кто этим пользуется.

До момента как его девайсом начинают пользоваться кто попало.

> И отдельно за раст, я уже говорил:

А кто ты такой, что твои "я же говорил" имели значение?

> оно слишком дорогое в разработке и поддержке,

Пруфы будут?
Пока у тех, кто таки делает, получается лучше чем на дырявых ЯП.
И по кол-ву CVE на CLOC, и по кол-ву возвратов недофикшенных багов.

> когда индустрия с ним наиграется то ИИ или даже просто какой то примитивный транслятор оттранслирует весь написанный код на С или С++.

Ну так будет классно.
Все равно потом придется поддерживать этот код.

> Тратить кучу человеко часов и тонны электричества на возню с растом - этот праздник когда то кончится.

Угу, я уже слышал "никто его в ядро не примет"))

> Да в общем то, если честно, на расте мало оригинального кода, в основном это переписывание существующего.

Дежурно напомню что СИ изобрели для ПЕРЕПИСЫВАНИЯ юникса.


Ответить | Правка | Наверх | Cообщить модератору

114. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  –2 +/
Сообщение от Аноним83 (?), 12-Фев-26, 07:36 
> Пока у тех, кто таки делает, получается лучше чем на дырявых ЯП.

Пока на расте ничего толком не получается, в мире даже на кобол софта поди больше.

> И по кол-ву CVE на CLOC, и по кол-ву возвратов недофикшенных багов.

Как вы собрались это продавать?
У меня в хэлло ворлде тоже 0 CVE, за сколько готовы купить?)


> Дежурно напомню что СИ изобрели для ПЕРЕПИСЫВАНИЯ юникса.

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

Ответить | Правка | Наверх | Cообщить модератору

122. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (122), 12-Фев-26, 12:20 
> Пока на расте ничего толком не получается, в мире даже на кобол софта поди больше.

У тебя сматрфон какой?
Скорее всего как положено 321м - яблочный.
Но если бы у тебя был андроид, то там уже 5+ миллионов строк раст кода.

Про клоудфларю слышал?
У них тоже раст код используется.

> Как вы собрались это продавать?

Я собрался на этом экономить зарплату на цепочке "саппорт получил баг - qa его исследовал - программист починил - qa проверил".

> С это скорее такой человекочитаемый и переносимый асм,

"переносимый" при помощи ifdefʼов)
Но как это противоречит тому, что его изобрели спецом для переписывания?

> отсюда то чего тут многие никак не могут понять: куча железо/имплементо специфичного поведения.

Да-да, настолько специфичного что как оно себя поведет не знают даже создатели стандарта.


Ответить | Правка | Наверх | Cообщить модератору

130. Скрыто модератором  +/
Сообщение от Аноним83 (?), 12-Фев-26, 15:13 
Ответить | Правка | Наверх | Cообщить модератору

116. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним83 (?), 12-Фев-26, 07:46 
> А потом через дыры утекают данные пользователей и ты попадаешь на штраф в % от оборота.
> Или просто теряешь репутацию надежной платформы.

Это мнение розового пони.
В реале в прошлом году вендор безопасности выкатил кривой апдейт который раскатился на вендовые тачки и убил наверное миллионы инсталляций по всему миру, чем нанёс кучу убытков и неудобств.
И чо? Вылетели они с рынка?

Кроме того можно и % с оборота платить, если у тебя пользователия и этот самый оборот есть.

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

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

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

Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

126. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (126), 12-Фев-26, 12:31 
> В реале в прошлом году вендор безопасности выкатил кривой апдейт который раскатился на вендовые тачки и убил наверное миллионы инсталляций по всему миру, чем нанёс кучу убытков и неудобств.

Из того что всплыло в публичный доступ - они получили предложения "решить по хорошему"

> И чо? Вылетели они с рынка?

Для первого раза запаса прочности может хватить.

> Кроме того можно и % с оборота платить, если у тебя пользователия и этот самый оборот есть.

До момента как пользователи начнут разбегаться)

> А уж про то как вин9х был не надёжной платформой но им всё равно пользовались

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

> я и вспоминать не хочу, сплошная боль на фоне современных реалий.

На фоне современных реалий.
Это ключевое.

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

Было лет 5 назад.
Сейчас пользователи вполне сваливают на менее дырявые варианты.
Плюс давление со стороны законодательства.


Ответить | Правка | Наверх | Cообщить модератору

108. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (106), 12-Фев-26, 05:14 
> И отдельно за раст, я уже говорил: оно слишком дорогое в разработке и поддержке, когда индустрия с ним наиграется то ИИ или даже просто какой то примитивный транслятор оттранслирует весь написанный код на С или С++.

Крайне сомнительно. С и С++ (и ещё буквально все фреймворки и библиотеки) спроектированы для использования человеком, и допускают какие-то хитрые ходы, позволяющие обойти ограничения системы. И это вообще самый, наверное, важный фактор. Человек может (ну как может, ну вот видим прямо в новости как именно он может, но не суть) понять когда можно битами пошевелить для скорости, а когда лучше не умничать и писать тупо в лоб. Для LLM это слишком сложно, слишком много вариантов. Чтобы LLM эффективно что-то делала, ей наоборот нужен язык типа Раста или даже какой-то ещё более строгий, чтобы невозможно было случайно выйти за границу массива или обратиться к неинициализированной переменной потому что важные инструкции вылетели за границу окна контекста. Поэтому ты прав только отчасти, действительно "тратить кучу человеко часов и тонны электричества на возню с растом" не нужно. Человеко-часы надо тратить на проектирование софта и обвеса для LLM, который не даст ей пороть опасную чушь.

Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

115. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним83 (?), 12-Фев-26, 07:38 
Ещё одна попытка свалить всё отвественность на что угодно с себя любимого.
Растишки валят всё на компелятор, вы на ИИ.
Ответить | Правка | Наверх | Cообщить модератору

123. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (123), 12-Фев-26, 12:22 
> Ещё одна попытка свалить всё отвественность на что угодно с себя любимого.

А надо валить на скудоумных бездарей, которые за 50 лет не научились писать код без типиКал ошибок.
Ну и пользуются кривым инструментом.

Ответить | Правка | Наверх | Cообщить модератору

119. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (119), 12-Фев-26, 09:33 
> Не важно дырявые они и на каком языке написаны, главное что они делают то для чего созданы.

Так ты глаза-то разуй: сабж как раз не делает то, для чего предназначен (обеспечение безопасности), в частности из-за сишочного численного переполнения (а для CVE-2025-32007 даже вон готовый эксплоит на блюдечке дали)

> С точки зрения пользователя не интересно что там внутри, ему всё равно на С или на расте или пхп это написано.

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

> отдельно за раст, я уже говорил: оно слишком дорогое в разработке и поддержке

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

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

Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

8. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +5 +/
Сообщение от Аноним (8), 11-Фев-26, 13:04 
Хочешь быть в безопасности - не используй чужие процессоры, чужие компиляторы, чужие компы, чужие сети и даже чужое елестричество. Самый простой вариант - улететь на Марс и спрятатся там в самой глубокой пещере. Тогда точно не взломают.
Ответить | Правка | Наверх | Cообщить модератору

9. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +2 +/
Сообщение от Аноним (14), 11-Фев-26, 13:09 
А может просто писать максимально качественный код? Да не, бред какой-то! (с)

Чуваки в коде даже не удаляют переменные объявленные без инициализации.
Хотя это закрывается настройками флагов компилятора.

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

Ответить | Правка | Наверх | Cообщить модератору

31. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Васян Санитайзер с микроскопомemail (?), 11-Фев-26, 14:57 
-- - - -  Чуваки в коде ...

Именно все эти чуваки и в коде... :)

Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (53), 11-Фев-26, 18:13 
По колено в коде.
Ответить | Правка | Наверх | Cообщить модератору

33. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от BeLord (ok), 11-Фев-26, 15:09 
Можно подсократить сказочку - хочешь быть в безопасности - не используй.
Что не использовать, а ничего не использовать-)))
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

43. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от ford1813 (ok), 11-Фев-26, 16:16 
> Хочешь быть в безопасности - не используй чужие процессоры, чужие компиляторы, чужие
> компы, чужие сети и даже чужое елестричество. Самый простой вариант -
> улететь на Марс и спрятатся там в самой глубокой пещере. Тогда
> точно не взломают.

Лучше по старинке, выдерни шнур и выдави стекло!

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

12. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +3 +/
Сообщение от Пишу с C2D (-), 11-Фев-26, 13:18 
Именно поэтому умные и дальновидные люди не торопятся расставаться со своими Core 2 Duo, ведь безопасность и приватность важнее показателей на бумаге. К тому же для большинства повседневных задач C2D будет с запасом хватать даже в 2026 году, если верить load average.
Ответить | Правка | Наверх | Cообщить модератору

18. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (18), 11-Фев-26, 13:39 
А если не будут брать - отключат память. И интернет. И поддержку во всём софте. Кому не нравится - тот сам всю свою софтовую экосистему делает за свой счёт.
Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (23), 11-Фев-26, 13:48 
Зачем сам делать? Перекомпилировать под свой C2D, Generic, не включая поддержки этих всяких новомодных AVX.
Ответить | Правка | Наверх | Cообщить модератору

109. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (106), 12-Фев-26, 05:17 
Ты не понял. Без AVX этот код не работает. У кого нет -- пишут сами себе чтобы работало.
Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (22), 11-Фев-26, 13:46 
> Core 2 Duo, ведь безопасность и приватность важнее показателей на бумаге.

Это тот самый который вышел настолько забагованный и дырявый, что ругались даже БСДшники?

Отличный план!
Сколько ошибок в errata там осталось не пофикшеными, ты все равно не узнаешь.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

68. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +1 +/
Сообщение от Аноним (68), 11-Фев-26, 19:18 
нет.
последний безопасный - это Пень3
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

71. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +2 +/
Сообщение от Аноним (71), 11-Фев-26, 19:30 
Расскажите, как в нынешнее время жить с 8 ГБ оперативки? Тот чипсет вроде больше не умеет.
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

72. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +1 +/
Сообщение от Аноним (72), 11-Фев-26, 19:48 
Как раз в нынешнее время 8ГБ топчик, рынок решает!
Ответить | Правка | Наверх | Cообщить модератору

79. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +1 +/
Сообщение от Аноним (80), 11-Фев-26, 20:38 
> Расскажите, как в нынешнее время жить с 8 ГБ оперативки?

Да нормально. Бонусом - есть повод побухтеть на Опернете про "Уъуъуъ, разучились оптимизировать! Вот в мое время софт летал и ел 16 MB оперативы! А теперь что? Ыыыы, запланированное устаевание!"

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

92. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Пишу с C2D (-), 11-Фев-26, 21:52 
Зачем вам больше? Я серьезно спрашиваю. Для вычислений облака давно более выгодны, чем покупать железо, для серверных нужд тоже. Разве что в игры играть.
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

97. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +1 +/
Сообщение от Аноним (80), 11-Фев-26, 23:13 
> Для вычислений облака давно более выгодны

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

> Я серьезно спрашиваю. Для вычислений облака давно более выгодны

Серьезно отвечаю: для вычислений не в облаках. Какая еще кора дуба с 8 GB и тем более "облака", если я вот рабочий проект на более 160000 строк C++ собираю?

Ответить | Правка | Наверх | Cообщить модератору

98. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (98), 11-Фев-26, 23:55 
> Зачем вам больше? Я серьезно спрашиваю.

Программирование? Чтобы собрать нечто не-игрушечное.
Дизайн? Особенно в 3д?
Инжинерия? КАДы, расчеты прочности.

> Для вычислений облака давно более выгодны, чем покупать железо,

Только если ты можешь отправить данные кому-то)

> для серверных нужд тоже.

Смотря для каких.

Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

99. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним83 (?), 12-Фев-26, 00:40 
Да не хватает его, если только опеннет почитать.
Какойнить хромиум компилится по 5 часов на 5950х, а на коредуо даже памяти столько не поставить чтобы компилировать его полностью в tmpfs.
Да и обычные задачи уровня посмотреть ютуб - ну можно, но очень сильно желательно иметь видяху с аппаратной поддержкой кодеков и чтобы это всё работало в ОС и браузере, иначе можно застрять на качестве 720p и облагать всю систему.

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

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

13. Скрыто модератором  +2 +/
Сообщение от ford1813 (ok), 11-Фев-26, 13:19 
Ответить | Правка | Наверх | Cообщить модератору

27. Скрыто модератором  –4 +/
Сообщение от Rev (ok), 11-Фев-26, 14:35 
Ответить | Правка | Наверх | Cообщить модератору

29. Скрыто модератором  +1 +/
Сообщение от Васян Умышленыйemail (?), 11-Фев-26, 14:50 
Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (15), 11-Фев-26, 13:25 
DDR7 уже или нет еще? D
Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (23), 11-Фев-26, 13:38 
Если DDR4 нужно брать тяжёлой RawHammer, то DDR7 поддастся небольшой кияночке.
Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (45), 11-Фев-26, 16:38 
В ddr6 обещали исправить. Но 7 лет бракованную ddr5 штампуют.
Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +1 +/
Сообщение от Аноним (23), 11-Фев-26, 13:41 
>Trusted Domain Extensions
>В результате аудита выявлено 6 уязвимостей

Секреты хранятся в сарае из трёх стен.

Ответить | Правка | Наверх | Cообщить модератору

36. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +1 +/
Сообщение от randomize (?), 11-Фев-26, 15:27 
> не заслуживающему доверия администратору

Это мощно!

Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (23), 11-Фев-26, 16:01 
А самый заслуживающий доверия администратор это, конечно же, товарищ майор.
Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноня (?), 11-Фев-26, 15:31 
Одни на доверии, вторые доверие ломают. А я не доверяю обоим ;)
Ответить | Правка | Наверх | Cообщить модератору

40. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (40), 11-Фев-26, 15:56 
Поэтому ты такой бедный.
Ответить | Правка | Наверх | Cообщить модератору

65. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Шарп (ok), 11-Фев-26, 19:07 
Постоянно находят уязвимости в этих безопасных анклавах. Это какой-то цирк. Если ты делаешь штуку для безопасности, то должен нанять туда работать самых крутых спецов. А тут похоже раз за разом реализацию поручают хлебушкам.
Ответить | Правка | Наверх | Cообщить модератору

66. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  –1 +/
Сообщение от Аноним (66), 11-Фев-26, 19:10 
> то должен нанять туда работать самых крутых спецов

Отличная идея! А... где их взять, не подскажите?
За забором что-то даже очереди из обычных спецов нет, а вы аж крутых предлагаете найти.

Ответить | Правка | Наверх | Cообщить модератору

75. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноня (?), 11-Фев-26, 20:02 
Дык, сделай. Без тебя то весь мир развалится.
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

110. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +1 +/
Сообщение от Аноним (106), 12-Фев-26, 05:23 
Ты, вижу, не спец ни в чём вообще, и уж тем более не крутой, а как раз из этих, хлебобулочных. Разработать безопасный анклав настолько сложно, что лучшие из имеющихся в наличии живых программистов не могут сделать без ошибок уже с которой попытки. Это тебе не моторола 6800, там всё экспоненциально сложнее.
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

121. "Уязвимость, позволяющая обойти механизм защиты Intel TDX"  +/
Сообщение от Аноним (122), 12-Фев-26, 12:14 
> Ты, вижу, не спец ни в чём вообще, и уж тем более не крутой, а как раз из этих, хлебобулочных.

Пф, а ты у нас спец?

> Разработать безопасный анклав настолько сложно, что лучшие из имеющихся в наличии живых программистов не могут

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

> сделать без ошибок уже с которой попытки.

Ага.
Может стоит перестать овнокодить?

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2026 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру