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

"Уязвимость в процессорах Intel, приводящая к утечке данных по сторонним каналам"	+/–
Сообщение от opennews (??), 28-Апр-23, 15:53
Группа исследователей из китайских и американских университетов выявила новую уязвимость в процессорах Intel, приводящую к утечке по сторонним каналам информации о результате спекулятивного выполнения операций, которую можно использовать, например, для организации скрытого канала связи между  процессами или определения утечек при совершении атак класса Meltdown... Подробнее: https://www.opennet.me/opennews/art.shtml?num=59029
Ответить | Правка | Cообщить модератору

Сообщения

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

2. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
Сообщение от Аноним (2), 28-Апр-23, 15:54
Может просто надо эти дыркопроцессоры использовать в закрытом контуре? Как правильные организации.
Ответить | Правка | Наверх | Cообщить модератору

	4. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+9 +/–
	Сообщение от Аноним (4), 28-Апр-23, 16:00
	Пересадить всех на терминалы, а все железки пусть будут в облаках кого надо?
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Bob (??), 29-Апр-23, 02:18
	В self hosted, например) -- Проще 1 сервак проконтролировать и грейдить, чем десятки и сотни клиентов. Разве нет?
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от AlexN (??), 07-Май-23, 14:24
	Ни разу не слышал о беспроцессорных тонких клиентах. ))
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+9 +/–
	Сообщение от Аноним (5), 28-Апр-23, 16:01
	>эти Это какие ? Все что ли ? https://www.opennet.me/opennews/art.shtml?num=57629
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	12. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–2 +/–
	Сообщение от Аноним (12), 28-Апр-23, 16:18
	Кроме Cortex-A<In Order>
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Аноним (-), 30-Апр-23, 22:42
	RISCV in order ничем не хуже. Да даже вот Atom есть, он in order и ему эти OoO проблемы чужды. Правда, никто не понимает смысл существования Atom если есть ARM но это уже другой вопрос.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Michael Shigorin (ok), 03-Май-23, 22:53
	Вы эти риск-хайп вообще щупальцами щупали-то?  В сравнении хотя бы с in-order ARM?..
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 05-Май-23, 00:31
	> Вы эти риск-хайп вообще щупальцами щупали-то?  В сравнении хотя бы с > in-order ARM?.. Влобовую сравнивать тяжко: 100% идентичные чипы где разница только в Core, а параметры обвеса 1 в 1 - еще поискать. Кроме того с RISCV все только начинается и когда идет портирование и bring up, сравнивать с уже устаканившейся экосистемой - так у тех как бы фора есть. А выравнивание будет через несколько лет, когда от bring up и обезглючки смогут к оптимизациям перейти. А хотите фокус? Видите https://github.com/T-head-Semi/openc906/ ? Это то самое, от алибабы. А теперь смотрим процессорное ядро у Allwinner D1. Рррраз! https://linux-sunxi.org/D1 Знакомьтесь, опенсорс, XXI век. Да, так можно было. Что самое интересное, алибабе allwinner уж точно не конкурент, сильно другие задачи. И кто хотел по грабелькам попрыгать с RISCV могут это сделать за копейки. Да, пока там все сыренько и WIP, но, вообще, уже можно и с майнлайном потрепыхаться.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Genry007 (?), 29-Апр-23, 06:37
	Meltdown - это "счастье" Интела. У АМД его нет, поскольку кеши по другому.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	91. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 08:49
	У AMD его нет, поскольку проверка привилегий выполняется даже при спекулятивном исполнении. Что, естественно, слегка роняет общую производительность - но в интеле видимо решили читернуть, и вышло как вышло. Все эти спектры с ефлагсами работают только в лабораторных условиях, да и то не всегда - малейший шум от процессов, и всё, привет, ничего уже не померить. Из реальных уязвимостей две, обе интеловские, оба-двое братья-акробатья. Мылдаун - там устраивается реальная загрузка одной из 256 страниц в кеш в зависимости от конкретного байта по конкретному адресу, далее замер "загружено - не загружено" производится очень легко, и сторонние процессы на результат слишком сильно не влияют, загрузка страницы в кеш - операция тяжёлая. L1TF - механизм немножко отличается, но ситуация та же - загрузка страниц в кеш без проверки привилегий.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–4 +/–
	Сообщение от Аноним (2), 29-Апр-23, 09:45
	Какой шум от процессора? Ты гуманитарий? Все что есть скомпенсируется во время вычислений. Если у тебя такой шум что ты даже не можешь узнать когда приходит сигнал это бракованный процессор он не будет работать бай дизайн.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+6 +/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 10:09
	Ты даже не понял о каком шуме речь. ПТУшник?
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (2), 29-Апр-23, 10:20
	Ты даже сам не понял что за бред ты пишешь. Дорогой наш багов.нет.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+4 +/–
	Сообщение от Den4ick (?), 29-Апр-23, 17:35
	Ну, чувак, на шуме от процессора основан генератор случайных чисел, так то :)
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (172), 30-Апр-23, 18:41
	Затворы щелкают?
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	173. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 30-Апр-23, 19:19
	Хронографическая гравицапа плавает.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от edo (ok), 30-Апр-23, 11:24
	> У AMD его нет, поскольку проверка привилегий выполняется даже при спекулятивном исполнении. Для уязвимости из статьи оно разве играет роль?
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	170. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Tron is Whistling (?), 30-Апр-23, 11:59
	Уязвимость из статьи - очередная лабораторная мышь, которая в реальном мире дохнет. Я ж специально отметил: реальных - две.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 30-Апр-23, 11:59
	(а всё остальное больше похоже на потуги интела "у нас не хуже")
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 30-Апр-23, 19:21
	Меня реально сейчас порвёт во время переката под столом, поэтому невнимательным просьба слово "процессов" как "процессор" далее не читать :D
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	179. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 30-Апр-23, 22:47
	> то не всегда - малейший шум от процессов, и всё, привет, ничего уже не померить. В случае коммуникационного канала плохой SNR легко компенсируется снижением битрейта. А чтобы какой-нибудь ключ или пароль передать много и не надо.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	182. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 01-Май-23, 08:03
	Примерно до 0, да. Суток за трое-четверо 100% нагрузки утащите один бит из соседней вкладки браузера. Вот только проблема - её закроют за это время.
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 06-Май-23, 05:01
	> Примерно до 0, да. Суток за трое-четверо 100% нагрузки утащите один бит Это очень смелое утверждение, выдающее что вы совершенно не разбираетесь в вопросе. Думается там другой порядок величин будет. > из соседней вкладки браузера. Вот только проблема - её закроют за это время. Кроме вкладок браузера есть еще вооооооон те хостеры, у которых виртуалки месяцами вкалывают и какой-нибудь приватный ключ SSH "присоседившись на машину" получить было бы весьма козырно. Как программа минимум это может позволить мутным типам получить N машин по цене одной. Что уже довольно неплохо. Как программа максимум, можно прицельно атаковать нужный хост, покупая у нужного хостера виртуалочки пока не выпадет на нужном хосте. А потом ее уже прицельно распетрушить.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 06-Май-23, 07:59
	Думаю да, порядок будет 30-40 суток. Или 300-400. В реальных условиях естественно. Особенно там, где есть что тащить.
	Ответить | Правка | Наверх | Cообщить модератору

	220. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 06-Май-23, 08:00
	>> есть еще вооооооон те хостеры, у которых виртуалки месяцами вкалывают Именно. И там шума столько, что через эти страшные коронавирусные дыры вы вообще ничего не утащите.
	Ответить | Правка | К родителю #216 | Наверх | Cообщить модератору

	183. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 01-Май-23, 08:04
	RSA-ключ будете утаскивать лет 15, вот только проблема, опять же - его за это время сменят :D
	Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

	225. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (225), 06-Май-23, 19:08
	> RSA-ключ будете утаскивать лет 15, Это на 486 чтоли? А так, если тебе хочется подаунплеить что-нибудь иди квартальные отчеты интела почитай. И расскажи как они там кого увольнять не будут с такими отчетами и как у них все ок с процами.
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 01-Май-23, 08:19
	И да - очередная ошибка кукаретиков из ПТУ: дыры side channel - это НЕ коммуникационный канал. В коммуникационном канале ты управляешь отправляемым сигналом. Соответственно можешь "снижать битрейт" и делать прочие фокусы как тебе заблагорассудится. Здесь же на отправляемый сигнал ты не влияешь никак. Он идёт с "битрейтом", тебе не подвластным. Ты просто пытаешься его перехватить, сиречь померить. А чтобы померить - SNR у тебя должен быть приемлемым, иначе ты будешь мерить шум океанов Марса.
	Ответить | Правка | К родителю #179 | Наверх | Cообщить модератору

	217. Скрыто модератором	+/–
	Сообщение от Аноним (-), 06-Май-23, 05:33
	> И да - очередная ошибка кукаретиков из ПТУ: дыры side channel - > это НЕ коммуникационный канал. Да не пались ты так. Про скрытый коммуникационный канал прямо в новости написано. Представляешь, парочка виртуалок может так между собой коммуницировать не имея никаких легитимных полномочий на IO куда либо (например "compute-only" конфиг, который, вот, окажется не только compute-only). > В коммуникационном канале ты управляешь отправляемым сигналом. Соответственно можешь > "снижать битрейт" и делать прочие фокусы как тебе заблагорассудится. А кто сказал что у атакующего в принципе никогда нет совсем никакого контроля над атакуемым объектом? Не прямой так косвенный. Откуда следует что тот или иной процесс никогда не удастся спровоцировать на полезную (атакующему) активность? > Здесь же на отправляемый сигнал ты не влияешь никак. Он идёт с > "битрейтом", тебе не подвластным. Это очень храброе допущение. Зачастую некий уровень контроля все же есть. Вот смотри, есть машина, есть ssh. Я не могу напрямую команды выполнить но могу формировать разный траф, с разными времянками, прося разные алгоритмы, а вон тот probe будет мерять отклик, если удалось его на тот же железный хост присоседить. И тут большой вопрос что это не содержит никакой полезной информации, с учетом тех свойств проца. > Ты просто пытаешься его перехватить, сиречь померить. А может быть и спровоцировать вызов того или иного сегмента кода могу. Сам по себе это легшитимный код, ничего полезного для атакующего официально не делающий. Неофициально с учетом таких свойств проца он утекает информацию и в конечном итоге кто знает чем это может закончиться. > А чтобы померить - SNR у тебя должен быть приемлемым, иначе > ты будешь мерить шум океанов Марса. Спасибо капитан очевидность. Но на самом деле в крипто бывает достаточно и небольшого bias, RC4 многострадальный подтвердит.
	Ответить | Правка | Наверх | Cообщить модератору

	218. Скрыто модератором	+/–
	Сообщение от Tron is Whistling (?), 06-Май-23, 07:58
	На заборе тоже написано. Не вижу смысла продолжать, без базовых знаний понимание невозможно.
	Ответить | Правка | Наверх | Cообщить модератору

	221. Скрыто модератором	+/–
	Сообщение от Tron is Whistling (?), 06-Май-23, 08:03
	"парочка виртуалок может так между собой коммуницировать" Вот это как раз и будет коммуникационный канал. Где ты управляешь и приёмником и передатчиком. А "ойязвимости" с попытками применения только приёмника - это не коммуникационный канал. Это попытка перехвата сигнала.
	Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

3. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
Сообщение от anonomus (?), 28-Апр-23, 15:58
мда... я надеялся что уже все ошибки спекулятивного выполнения закрыли патчами, а тут новая в решете :( и ради +пару% скорости получаешь дырень в железе напоминает адептов одного известного дырявого языка пограмирования, они тоже ради быстродействия готовы CVEшки писать
Ответить | Правка | Наверх | Cообщить модератору

	8. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+4 +/–
	Сообщение от bircoph (ok), 28-Апр-23, 16:11
	Это ты про Rust что ли? Да, они умеют, упиваясь своей иллюзией безопасности забывать о базовых вещах, ну CVE-2021-28032, например.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+6 +/–
	Сообщение от anonomus (?), 28-Апр-23, 16:22
	уязвимость в крейте (насколько я понимаю что-то типа либы, которую поддерживает какой-то чувак) в языке на котором почти ничего не написано? оно вообще в "std"? как-то мелковато я про например CVE-2022-2602 - бац и получаешь up привилегий в системе. или CVE-2022-1966, CVE-2022-32250 - то же самоее или еще лучше CVE-2023-1998 - позволяет обойти защиту от атак Spectre v2 (а зачем если есть еще куча дыр?) еще можно вспомнить heartbleed... да тысячи их каждую неделю на пеньке обсуждаются
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–2 +/–
	Сообщение от Аноним (26), 28-Апр-23, 16:51
	Так heartbleed и не заявлял что он серебряная пуля безопасности в отличии от сомнительных ребят из мозиллы. Ну а спектр, мелтдовн это скорее аппаратная особенность, которую очень хотят закрыть программными патчам, что иначе чем костылями и не назовешь, ну и результат соответствующий. Ну а колосс раста опять разваливается - теперь вот и "крейт это не раст, а поделие какого-то чувака". На тот факт что и раст делали студенты (и пара сомнительных парней постарше) старательно не обращают внимание.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (75), 29-Апр-23, 01:46
	> я про например CVE-2022-2602 - бац и получаешь up привилегий в системе кому это мешает кроме корпораций, зачем этот io_uring на пека и мобилах обычных пользователей ?
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	169. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от edo (ok), 30-Апр-23, 11:25
	Затем, что это лучше, что придумали в event-driven со времён select.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (70), 29-Апр-23, 00:14
	Судя по тому что ты говоришь, у тебя нет вышки даже (или она была высижена задницей). Иначе невозможно объяснить, как ты баг во внешнем крейте записал в недостатки языка. Основы логики ж проходят на первых курсах!!
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	102. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+6 +/–
	Сообщение от Аноним (102), 29-Апр-23, 11:23
	Интересно получается. Как преимущества, так "легко и безопасно писать", "есть пакетный менеджер" и "куча безопасных библиотек есть и вот-вот еще больше наклепаем". А как уязвимости так "это не раст", "это виноват разработчик", "не чуешь разницу между пакетным менеджером я языком?". Ну так и в си уязвимости в либах и в руках разработчика, о чем вам еще в 2015 говорили. Гребанные смузихлебы.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от n00by (ok), 29-Апр-23, 15:49
	Может потому у Раста и нет стандарта? В Си библиотека получается частью языка.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от fidoman (ok), 28-Апр-23, 16:14
	в какой-то момент косякнули, решив совместить проверку привилегий вместе с актуализацией спекулятивного вычисления (по логике "в лоб" проверку надо было делать перед вычислением, возможно это усложняло схему), а теперь переделывать поздно.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	19. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от аНОНИМ (?), 28-Апр-23, 16:35
	Если 'проверять привилегии' до исполнения, само исполнение вместе с этой проверкой займёт раз 10 дольше времени.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от anonomus (?), 28-Апр-23, 16:37
	...поэтому давайте отдадим свои данные рандомному скрипту запущенному в браузере
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Аноним (26), 28-Апр-23, 16:58
	А Столлман предупреждал не запускать рандомные скрипты
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от anonomus (?), 28-Апр-23, 17:05
	а кто тебя будет спрашивать)? с noscript половина интернета просто не откроется просто надо делать чтобы браузер жил в "контейнере" с ограниченными привилегиями не делать дырявые процессоры ну и не писать дырявый код все просто)
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (12), 28-Апр-23, 17:43
	Так это... чтобы изоляция помогла, надо _каждую_ вкладку в отдельном контейнере, а не просто браузер. И то не факт, что помогут контейнеры, а не придётся каждую вкладку в отдельную виртуальную машину.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Neon (??), 29-Апр-23, 22:08
	> с noscript половина интернета просто не откроется А на хрена так делать ?!
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	37. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (37), 28-Апр-23, 17:22
	Кто это?
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	43. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (12), 28-Апр-23, 17:45
	Тот, кто не призывал хлебать смузи по каждому поводу и без повода.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Неуклюжий танцор (?), 28-Апр-23, 22:15
	А я всегда так делаю
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
	Сообщение от Аноним (12), 28-Апр-23, 16:40
	Проверка нескольких бит увеличит время исполнения в 10 раз? По-моему, вы фантазируете.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	28. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–3 +/–
	Сообщение от Аноним (26), 28-Апр-23, 16:56
	Представь что в магазин не будут пускать нового покупателя, пока предыдущий не выберет, не оплатит, не сложит свои покупки и не выйдет из магазина. Вот нечто похожее и будет с процессором.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+3 +/–
	Сообщение от anonomus (?), 28-Апр-23, 17:11
	неудачная метафора подобна котенку с дверцей... ну ладно, чего от гуманитариев еще ожидать, так вот в твоем случае оба покупателя скидывают все покупки в одну тележку и потом один начинает тырить чужие купленные и оплаченные товары: макарошки, пельмени, бутылку джек-дениелса.... ты бы сильно обрадовался, что так быстро закончил поход в магазин если бы недосчитался вышеперчисленного?
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
	Сообщение от fidoman (ok), 28-Апр-23, 18:11
	10 там не будет никаким боком, но скорей всего пришлось бы делать копию TLB для каждой спекулятивной ветки, чтобы её исполнение не тормозило основное вычисление (фактически это ещё один недо-поток). Но в то же время была бы экономия за счёт того, что эти ветки обрывались на ошибке доступа, а не продолжали бы обсчитывать заведомо ненужное.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	49. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
	Сообщение от Ivan_83 (ok), 28-Апр-23, 18:29
	Чтобы вы понимали, на С писали ещё тогда когда производительности компа не хватало чтобы mp3 проиграть, а авторы раста ходили в садик. При тех выч мощностях их бы послали даже не на 3 буквы на пинками, потому что их поделие тормозило бы дико, настолько что смысла его даже рассматривать нет. Выбор был: пишем на С (может с асмовыми вставками) чтобы тяжёлые вычисления не тормозили или пишем на вижалбейсике или чем то подобном когда надо быстро накидать прототип или гуй. То что сейчас кресты расжирели невероятно и появилась гниль (раст) - это следствие прогресса, который вы пытаетесь помножить на ноль.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	51. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Анонимусс (?), 28-Апр-23, 20:52
	> С писали ещё тогда когда производительности компа не хватало чтобы mp3 проиграть Ты абсолютно, на все 146% прав. Но те времена канули в Лету. Программы стали на десятки порядков сложнее, кодовая база выросла даже не знаю... на 1к%, на 10к%? Можно сравнить ядро v1.0 и последнее v6.3. Можно даже выкинуть из него коды драйверов. И старые инструменты оказались неприспособленными для этого. Они постоянно приводят к однотипным проблемам, раз за разом одно и тоже. Поэтому и инструменты должны меняться. Сейчас поле обрабатывает навороченный трактор с gps, лидаром и кондишкой, а не раскидывают навоз палкой-копалкой. Хотя... кому-то палка роднее.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+3 +/–
	Сообщение от Ivan_83 (ok), 28-Апр-23, 21:31
	Так и С не стоит на месте, обновился и стандарт и компиляторы стали сильно умнее, появились анализаторы кода, появился ASAN и valgrind. А программы - они просто наросли поверх того что было. В ядро понапихали всякого нового, далеко не всегда нужного кому либо вообще.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Анонимусс (?), 28-Апр-23, 22:25
	Угу, а ошибки все те же. > обновился и стандарт и компиляторы стали сильно умнее Какой там стандарт в ядре? В ядре 5.18 (May 2022) они перешли на с11. В 22м году на с11. Но это конечно же прорыв)) Потому что до этого там было gnu89. Всего 30+ лет отставания.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Ivan_83 (ok), 28-Апр-23, 22:34
	Если бы вы знали разницу то не ёрничали бы, в данном случае это скорее про требования к компилятору по фичам.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–3 +/–
	Сообщение от Аноним (81), 29-Апр-23, 04:25
	Ты не понял. Проблемы как раз из-за того что тянут совместимость с Си в процессоре. Код пишется для виртуальной Си машины. Все твои умствования упираются в реальность что проблема в том что тащат везде Си. Для Эльбрусов это хорошо потому как там нет замороченной внутренней архитектуры процессора, а вот в х86 чокнутых заморочек вагоны и отсюда все дыры. Код языка можешь как угодно себе в голове вырисовывать, но я сомневаюсь что ты изучал тот же раст или другие языки. Если для безопасной работы с памятью нужно переписать драйвера на раст это хорошее решение.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от ivan_erohin (?), 29-Апр-23, 08:32
	> Код пишется для виртуальной Си машины долго смеялся над этим растоманом в голос. > Если для безопасной работы с памятью нужно переписать драйвера на раст это хорошее решение. А я люблю переписывать все на расте и хвастаться. Каждый день я хожу по gitlab и github с git clone  и собераю всю C legacy какую вижу. На два полных гигабайта целый день уходит. Зато, когда после тяжёлого дня я прихожу домой [... продолжайте сами ...]
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Ivan_83 (ok), 29-Апр-23, 14:29
	Шедеврально! Вы настоящий растоман, поздравляю вас! Нет, я ничего не изучал, с детства разговариваю на С, в садике меня никто не понимал, в школе тоже :)))) Начинал я с бесика на z80, там же дошёл до асма. Потом был квик бейсик под дос, не долго, потом вижал бейсик, а потом его стало мало (где то за 2 года я стал гуру) и наконец то приобщился к элите и познал С, язык на котором в 2003 году можно было сделать всё что угодно в венде. И до сих пор на любой платформе и любой ОС я могу делать что угодно на С. Перл, пхп, питон, вала, шелскрипт, луа, джава, джаваскрипт и хз что ещё - что то писал/правил по мелочи, мне не особо интересно что там у языков и как, нужный мне результат я получил не вникая.
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	105. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
	Сообщение от Аноним (102), 29-Апр-23, 11:44
	>Угу, а ошибки все те же. Так и в расте те же ошибки будут. Только вы сначала будете говорить "это unsafe", "это особенность реализации в линуксовом ядре", "это разработчик либы ошибся", "это код старый на новой архитектуре". Поотбиваетесь так несколько лет, может накормите обещаниями, а в итоге убежите на какой-нибудь новый хайповый язык с маркетингом лекарства от рака ("программирование через нейросети, пишешь промт и язык сам создает и обновляет безопасное и быстрое приложение, со временем будет все больше обучаться и становиться безопаснее"). И уже в нем будете наступать на те же грабли.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	139. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Аноним (139), 29-Апр-23, 16:42
	>Программы стали на десятки порядков сложнее Чево? Один порядок - это в 10 раз. Два порядка - 100 раз. В десятичной системе, разумеется. Гумо-не-тарий?
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	180. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 30-Апр-23, 22:52
	> Сейчас поле обрабатывает навороченный трактор с gps, лидаром и кондишкой, а не > раскидывают навоз палкой-копалкой. Хотя... кому-то палка роднее. А вон там, в Сан Франциско, народ хренеет с пробок. Сообщения о пробках в очередном крупном городе были бы, конечно, ничем не примечательны, если бы пробки не устраивали БЕСПИЛОТНЫЕ такси. Так что таксисты уже могут начинать понемногу сушить весла, это уже масспрод и его проблемы.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	52. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от anonimus (?), 28-Апр-23, 20:58
	>  появилась гниль (раст) давай больше пафоса) можешь рассказать про грибы порабощающие людей и прочие байки с РенТВ а если серьезно то ты прав на С писали в те времена когда: 1. разработкой занимались крутые перцы на зарплатах от универов, которые бесплатно делились програмками на дискетках всем было плевать на то что язык состоит на половину из UB 2. ни о какой безопасности никто не думал, банков и онлайн покупок не было, облаков с фотками и  соц.сетей тоже 3. интернет был на начальном этапе развития (в виде университетских сетей), а потом просто медленный это сейчас могут взломать сайт и выкачать 100500 гигов, а тогда надо было ехать к тебе домой, бить физиономию и отбирать комп целиком 4. программы были проще; кодовая база с тех времен увеличилась на порядки, просто посмотри размер ядра линука по годам и сейчас требования к программам были меньше; обычный текстовый квест вызывал неподельный восторг, а сейчас попробуй объяснить, что мышка это излишество 5. никто не думал о том что будет многопоточность, виртуализация, контейнеры и  гипервизоры что на одном компе будут крутиться одновременно куча сервисов эти времена прошли, но до сих пор многие СИшники совершают одни и те же ошибки как и 15-20 лет назад: выходят за границы массивов, портят память соседям, очищают ее дважды и тд Это как убеждать деда алкаша, что туалет вида "дырка в полу" это уже устаревшее, он тебе расскажет о том какой он крутой был в молодости и как из дырки удобно какахи вычерпывать. Ну и еще что-то про молодеж и смузихлебов. Но есть и другие люди знакомы с проблемой и то что она не решается десятилетиями. Например Линус Торвальдс. Именно поэтому раст добавляется в ядро (а не отвратительные плюсы)
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	56. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
	Сообщение от Ivan_83 (ok), 28-Апр-23, 21:45
	Проблема не в инструментах а в тех кто ими пользуется. У современного поколения уже просто фобия перед С, замечу что это из области психи а не техники. Если кто то совершает одни и теже ошибки - это опять же проблема его необучаемости. 1. И раньше писали разные люди и сильно по разному, и делились и нет, в этом плане мало что поменялось, разве что делится нынче стало на порядки проще. 2. Думали в первую очередь о скорости, потом чтобы не падало. Эти приоритеты и сейсач никуда не делись, я лично не готов терпеть лаги только ради мнимой безопасности. Банки онлайн были где то с 2005 года, по крайней мере я тогда уже точно видел их. У меня один клиент жаловался что SSL не работает и он туда попасть не может, оказалось зря я FIPS включил в групповой политике :) 5. Виртуализация, контейнеры, гипервизоры - это костыли. Есть уже давно высокоуровневые языки, кому не нравится С - уходят туда, но это не останавливает их от таких же банальных ошибок. Торвальдс не сам притащил гниль в ядро, он не стал сильно мешать этому, это сильно разные действия. И чтобы вы знали, у венды есть кресты в ядре, и там дрова на крестах можно писать, кажется даже по дефолту подразумевается что ты на крестах пишешь, по крайней мере мне так запомнилось.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–2 +/–
	Сообщение от Аноним (81), 29-Апр-23, 04:28
	Опять пердежь в лужу. Знающие люди говорят что люди просто не разберутся в современном коде почему он так написан. За примером ходить далеко ненужно - взять те же иксы. Вот иди сначала потрать время выясни хоть что-то прежде чем вещать с офигеть важной миной.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (102), 29-Апр-23, 11:50
	И как раст предлагает решать возрастающую сложность кода? А никак. Но си который старается не делать лишних абстракций это плохо, а раст который делает DSL для макросов и смешивает разные модули (вроде линтера и компилятора) это почему-то хорошо.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Анонимусс (?), 29-Апр-23, 13:37
	> А никак. А вот и нет. У раста есть куча вещей - мелких и не очень для этого. Модули, крейты, пакеты позволяют легко дробить код на логические составляющие и изолировать друг от друга. Писать тесты - юнит тесты, модульные, интеграционные. Причем юнит-тесты пишутся в самом же коде, что очень удобно, т.к. можно без костылей тестировать приватные апи. DSL для макросов как раз прекрасное решение, намного лучше тупого #define, потому что будет если у тебя в двух файлах два одинаковых #define? А в расте при коллизии имен ты просто указываешь "путь" к нужному. Или напр. enum. Ну, в си они убогие by design, но еще добавляют проблем - значения должны быть уникальны во всех енамах. И опять привет коллизии. Или уродливые уникальные имена. В плюсах это решили через enum class, а в си, на момент когда о нее пришлось последний раз мараться, нет. Нормальные "протоколы" в виде трейтов. Мощнейший инструмент, позволяет отделить "намерение" от "реализации", писать нормальные моки для тестов, заодно и избавляющий от кучи ошибок типизации. И необходимости передавать void* в качестве параметра)) > смешивает разные модули (вроде линтера и компилятора) Конечно это хорошо - оно позволяет получить такой мощный анализ на этапе компиляции. Даже не понятно, почему думаете что это плохо? Потому что раньше так не делали? > Но си который старается не делать лишних абстракций это плохо Плохо не то, что си "старается не делать лишних абстракций", а плохо то, что они не делают их когда это нужно. Вместо написания простых оберток над примитивами и работы с ними, используются чистые примитивы в десятках мест и в одном из них допускается косяк.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Ivan_83 (ok), 29-Апр-23, 13:52
	Вы обмазываетесь синтаксическим сахаром вместо решения реальных проблем. Всё что вы описали это фап на сам процесс.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от anonymous (??), 29-Апр-23, 16:08
	В случае раста это даже не сахар, это какие-то синтаксические экскременты.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Ivan_83 (ok), 29-Апр-23, 13:53
	Не удивительно что ваши "знающие" гнилеманы ни в чём кроме гнили разобратся не могут, у них мозги думают только про гнилостный сахар а не про технологии.
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	125. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Анонимусс (?), 29-Апр-23, 15:20
	Ванюша, ну что ж ты все время к оскорблениям скатываешься - гниль, гниль, гниль - может что-то новое можешь сказать? Спасибо, мы уже поняли что ты, отбитый, застрял где-то в 2000х и фапаешь на те времена. Ну так и оставайся там вместе со своих Z80, вижуалбейсиком и божественной сишечкой без синтаксического сахара. Печалька конечно, что ничего большего ты осилить не в состоянии, да и желания у тебя нет - все и так устраивает, как это у дидов было. И никакого сахара - чем больше строк кода, тем лучше. Но что поделаешь, что за столько лет сишники так и не придумали как не допускать детских ошибок. Приходится думать за них.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Ivan_83 (ok), 29-Апр-23, 16:17
	Так это же перевод, локализация названия, чего оно вам так режет уши? Сишечка позволяет насыпать любое количество сахара, просто со времинем понимаешь что много сахара - зло, и стремишься его минимизировать дабы не писать "сектансткий код" который будет понятен только тебе. (сектанты заменяют термины и вводят свой новояз как средство для изоляции адептов от общества) Сообщаю вам что у дедов всё хорошо и вы почему то до сих пор на всём дедовском живёте, так ничего своего и не сделав. А детские ошибки вы как раз и совершаете, как и большая часть индустрии вы не в силах осознать что простой синтаксис - гарантия распространённости как среди носителей так и реализаций. Высокоуровневым языкам это простительно, там задачи немного другие, а тому что претендует на роль системного языка нет. В итоге будут очередные с++, д и прочая фигня которая имеет свою узкую нишу, из которой гниль никогда не вылезет.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (175), 30-Апр-23, 20:04
	Вообще-то "гниль" - это "rot", "putridness". "Гниение" - это те же "rot", "putrescence", "decay", иносказательно "corruption". Чтобы перевести "rust" как-то по-другому чем "ржавчина" или "коррозия", нужно быть представителем самой читающей нации и получить лучше в мире образование. Впрочем, остальные утверждения только показывают, что с программирование дела обстоят аналогично.
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 06-Май-23, 22:11
	> Но что поделаешь, что за столько лет сишники так и не придумали > как не допускать детских ошибок. Вот те раз, MISRA даже бизнес на этом делает - и все "не придумали". Но вообще, статический анализатор можно и нашару запустить, так то. > Приходится думать за них. Такие думатели обычно решив 1 проблему создают 5 новых, значительно более сложных. Ну вот например что типовой хрустик будет делать если майкрософт его забанит в каргокульте? По причине ссанций или там какая сегодня левая пятка майкрософту что подсказала. Ты же не думаешь что их карманный директор в борде возбухать против этого станет?
	Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

	90. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от ivan_erohin (?), 29-Апр-23, 08:40
	> Банки онлайн были где то с 2005 года банки онлайн (по диалапу или интернету) были с 2002 года. помню как сейчас - клиент-банк местного сбербанка, ppp через диалап, я отследил взаимодействие клиента и сервера и запретил все остальное фаерволлом (NT4, WinRoute). потом очень злорадствовал, когда кое-кто подцепил оттуда самоходную программу, предположительно от соседей по модемному пулу.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	181. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 30-Апр-23, 23:05
	> У современного поколения уже просто фобия перед С, замечу что это из > области психи а не техники. У них скоорее проблема в hype driven. Стадный эффект. Маркетинг. Нет хайпа - все, это не круто. В результате, правда, заканчивается тем что проекты фэйлятся оптом и в розницу т.к. даже если нахватать супертулов решающих все проблемы человечества это никак не улучшает уровень кодера и чуда не случается. Зато вон гора кода с периодом полураспада в год. См. как из демьяна удалили кучу поддержки матрикса, потому что мутный питонокод выкинули, он был такой что кроме автора никто ЭТО поддерживать не захотел. Ну а потом начинаются массовые увольнения когда все эти прожЕкты сыпятся там и тут. Фэйсбук, майкрософт, твиттер, редхат... тактактак, кто следующий клиент thelayoff-ком, или как там его? Ща всех бесполезных и легко заменимых хайпонашек и побустают. > Если кто то совершает одни и теже ошибки - это опять же > проблема его необучаемости. Абсолютно. И верования в серебряные пули способствуют факапам кодеров и фэйлам проектов. Почему-то. > Эти приоритеты и сейсач никуда не делись, я лично не готов терпеть > лаги только ради мнимой безопасности. Ну вот лично я не использую по этому код на питоне и электроне. В принципе. > SSL не работает и он туда попасть не может, оказалось зря > я FIPS включил в групповой политике :) FIPS очень специфичная штука регламентирующая криптоалгоритмы и включать ЭТО в любой настройке где оно есть надо ТОЛЬКО если от вас требуют комплайнс и требователи готовы к тому что за этим следует. В остальных случаях это грабли. > 5. Виртуализация, контейнеры, гипервизоры - это костыли. Можно конечно сказать что разделение корабля на герметичные отчеки это костыль, дескать, нормальный корабль не должен пробоины получать. Но на практике почему-то все пришли к герметичным отсекам, что улучшает шансы корабля не пойти на дно если какая-то хрень все же случилась. А в sci-fi это и космических кораблей касается. > но это не останавливает их от таких же банальных ошибок. Верования в то что тул подумает за кодера напротив ведут к появлению напыщенных и некомпетентных типажей, чей код раздалбывать одно удовольствие. Его достаточно тронуть немного и все разваливается. > Торвальдс не сам притащил гниль в ядро, он не стал сильно мешать > этому, это сильно разные действия. Торвальдс видимо хочет посмотреть что у них получится. А почему бы и нет? У сей есть свои назойливые антифичи, и любой кто кодил что-то крупнее хелловорлда знает об этом. И а частности например работа с integer, pointer и UB. Первое в сях просто определено абы как и кодить на этом без багов рокетсайнс. Скажите вашему крупному проекту -Wconversion и расскажите как вам оно. Второе сделано так что не подлежит полноценному статическому анализу. Третьего слишком много в стандартах. Так быть не должно. > дрова на крестах можно писать, кажется даже по дефолту подразумевается что > ты на крестах пишешь, по крайней мере мне так запомнилось. У винды так то и не осталось почти системных кодеров. Майкрософт всех разогнал.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	79. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Аноньимъ (ok), 29-Апр-23, 03:37
	Вы так пишите как-будто до поганой сишки и риск процессоров ничего не было. А оно было. >многопоточность, виртуализация, контейнеры и  гипервизоры Костыли си процессоров.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	86. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от аНОНИМ (?), 29-Апр-23, 06:15
	>>многопоточность, виртуализация, контейнеры и  гипервизоры > Костыли си процессоров. Проблемы фанбоев в том, что они даже не удосужились ознакомиться с историей вычислительной техники. Все вышеотквоченное появилось задолго до сей.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноньимъ (ok), 29-Апр-23, 15:21
	Да, появились до сей, но в других формах наверное.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от n00by (ok), 29-Апр-23, 16:07
	Раньше оно было в форме шкафа, а теперь в форме телефона.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 06-Май-23, 22:13
	> Раньше оно было в форме шкафа, а теперь в форме телефона. Да уже и в форме SD-карточки есть. Да что там, вон та штука, меньше рисового зерна, умещает в себе больше чем тот шкаф.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (133), 29-Апр-23, 16:11
	Я так думаю, что человек неуклюже указал на "сходимость" в точку направлений развития языка и железа, их "тянет друг к другу". Смотри, проги для типичного компа в последние десятилетия в большинстве своем написаны на Си/Си++. При проектировании очередного, нового процессора, инженеры ориентируются в немалой степени и на существующий прикладной софт, который будет на новом изделии крутиться и который в основном на си/плюсах. И синтетические тесты потом крутят и из реальных программ попугаев выдавливают. Смотрят по существующим программам что там как типично ветвится, как данные гоняются, чтобы кэши оптимальнее загрузить, что можно распараллелить по конвеерам и до какой степени и т.д. и т.п. В свою очередь создатели компиляторов этих самых распространенных языков (и изредка создатели простых программ, где это нужно), опираясь на меняющуюся архитектуру процессора, выжимают из него оптимизациями всё что могут, подгоняют под ЦПУ - выравнивают данные в памяти, раскручивают циклы и т.д. и т.п. Такой вот постоянный непрерывный процесс сходимости двух сторон, программной и железячной, к синергии, подстройки друг к другу. А программная ширпотребная часть, повторюсь, в основном написана на си/плюсах.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	135. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Ivan_83 (ok), 29-Апр-23, 16:21
	Вы просто гениальный растоман! Вам надо на конференциях доклады делать, гарантирую их будут смотреть все, только ради вас.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (102), 29-Апр-23, 11:55
	Как это принято у растоманов смешались в кучу кони, люди, языки, процессоры, архитектура, вирутуализация, времена, нравы и над всем этим конечно же царит адский си. Вот уж фантазия у людей бывает.
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	55. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (55), 28-Апр-23, 21:38
	> При тех выч мощностях их бы послали даже не на 3 буквы на пинками, потому что их поделие тормозило бы дико, настолько что смысла его даже рассматривать нет. Нет, дело не в том, что поделие бы тормозило, дело в том, что у тех процессоров не было современных техник оптимизации, а если бы они были, никаких суперкомпьютеров не хватило бы эти оптимизации проводить при компиляции. > следствие прогресса, который вы пытаетесь помножить на ноль. Глупости. Если современная техника лучше допотопной и позволяет писать и выполнять безопасный код, то какой смысл возиться с небезопасным? Ты ещё порекомендуй отказаться от языков высокого уровня, потому что когда-то компьютеры не могли компилировать и всё надо было писать на ассемблере и ещё нанимать девочек, которые будут мнемоники переводить в машинные коды.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	57. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Ivan_83 (ok), 28-Апр-23, 21:52
	Зачем мне ваша безопасность если оно жрёт и память и проц как не в себя а пользу я не вижу? Поясню. Мне не нужна безопасность какая то там, у меня для этого замок на двери, и если будет мало я куплю ствол и подключю сигнализацию. Мне от компьютера нужно то что я заказывал - обработать нужную мне информацию и показать результат. Вы же сами не понимаете нифига в безопасности, только как попугаи повторяете друг за другом, у вас просто религиозный культ.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Анонимусс (?), 28-Апр-23, 22:18
	Так проблема в том что "а пользу я не вижу". > Мне от компьютера нужно то что я заказывал - обработать нужную мне информацию и показать результат. Прям как в 80х! Не хватает только девочек с прикладной, которые будут забивать код в эвм)) Ну не самому же это делать в самом деле)
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Ivan_83 (ok), 28-Апр-23, 22:41
	Объясняю на простом и доступном языке. Я покупаю перфоратор потому что мне нужны дырки в стене которые он делает. Мне не нужен перфоратор, не нужны буры, не нужен чемоданчик с запасными щётками, смазкой и тп, мне нужны ДЫРКИ в стене. Точно так же с компьютером. Я его купил чтобы лазать по инету, играть в игры, общатся. Иногда мне приходится самому что то там дописывать, править баги, писать вообще новые проги с нуля - но только потому что мне нужен результат работы этих программ, не сами программы/патчи. Вы со своей гнилью предлагаете мне вместо обычного перфоратора бош купить херош который стоит в 10х, жрёт электричества 10х, шумит 10х, при этом делает точно такие же дырки с стене, но в 10х раз медленнее. Зато у него двойная изоляция на проводе, дифф автомат в вилке, и защита от дурака так чтобы я буром себе бошку не продырявил. Нет, мне не интересно, пользуйтесь такми сами раз у вас столько фобий, я не боюсь ударов током и лишних дырок в организме настолько чтобы так страдать.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Анонимусс (?), 28-Апр-23, 22:55
	Объясняю на простом и доступном языке. Ты считаешь что если тебе что-то не нужно, то это не нужно и всем остальным. Это первая и самая важная ошибка. Тебе нужен комп чтобы он тебе что-то считал, на мобиле у тебя только пароль от wifi, а безопасность сводится к сигналке и стволу. И больше тебе ничего не нужно. Но это ТВОИ ЛИЧНЫЕ проблемы. Зато можешь поныть в интернетиках, смотря на прогресс. > cтоит в 10х, жрёт электричества 10х, шумит 10х Какая же бездарная брехня... Даже джава редко настолько медленнее чем дыряшка. Основная идея раста как раз сделать все возможные проверки в compile-time. И минимальное кол-во проверок во время выполнения. И дело не в фобиях. Можно ездить на машине с коробкой без синхронизаторов. Можно взять старое двигло и каждые пару тысяч настраивать зазоры клапанов. Или менять прохудившиеся прокладки головки двигателя. Но зачем? Не, ну хочется - вперед, но большинству это нафиг не сдалось. > я не боюсь ударов током и лишних дырок в организме Ну если действительно так, то осчастливь мир и сделай пару новых дырок)) PS. в перфах бош как раз двойная изоляция, плавный пуск и муфта от заклинивания. Они заботятся о безопасности своих пользователей.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Ivan_83 (ok), 28-Апр-23, 23:19
	Меня устраивает то как оно есть сейчас, это вы с гнилью во все щели лезите. С вам тоже разрешает включить массу compile time проверок, я вот включаю у себя в проектах, а то что другие не включают - это не проблема С. Ходите с петицией к компиляторщикам чтобы включали всё по дефолту и -Werror заодно, получится не хуже вашей гнили, ругани будет точно больше. Ещё раз, мне пофик что у боша, я купил дырки. )
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (139), 29-Апр-23, 17:06
	> Даже джава редко настолько медленнее Ну если копнуть историю, то java разрабатывалась для SPARC. И там она была вполне себе. С учётом всей сановской архитектуры. Даже на телефонах работала. Но Интел - это же другое, да. То, что её начали туда пихать, на железки которые до сих пор не имеют шин типа SBUS, NBUS - это "веяние рынка". Sun проcpали патамушта дорого. > большинству это нафиг не сдалось Большинству вообще ничего нафиг не сдалось, три основных функции организма - ихнее всё. >PS. в перфах бош как раз двойная изоляция, плавный пуск и муфта от заклинивания. И чо? Сдохнет скоро твой бош, как и вся европейская промышленность.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	203. Скрыто модератором	+/–
	Сообщение от Аноним (-), 02-Май-23, 04:04
	> И чо? Сдохнет скоро твой бош, как и вся европейская промышленность. Очень интересно как какой-нибудь сименс с их промышленными контроллерами сдохнет. Может у них еще и конкуренты есть? :)
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Аноним (139), 29-Апр-23, 17:08
	>мне нужны ДЫРКИ в стене. Стеночный дырофил?
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	193. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 01-Май-23, 17:46
	> Так проблема в том что "а пользу я не вижу". Представляешь, для начала компьютер должен работать. И желательно - хорошо. А постоянные тупнями, лаги и дергание программ с ломовым жрачем ресурсов вызывают у пользователей только ненависть. Хоть трижды безопасно оно там будет, это не сильно ценно если остальные параметры трэш. А ультрабезопасность дорогой ценой пользователям не особо надо, такая вот печаль. Они лучше Win95 без системой прав будут пользоваться если UX лучше. И пользовались, т.к. это позволяло более дешевому компу шустро работать, а NT4 да и винтукей не очень хорошо продавались и даже такой кадавр как MS смог на более безопасную архитектуру ос перейти лишь с 3 серьезной попытки (у них и иные причины были, и много).
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	65. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 28-Апр-23, 22:59
	> а пользу я не вижу? Глаза продери, может увидишь.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	66. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 28-Апр-23, 23:03
	Ой, а чего это ты вдруг тему решил сменить? Я ему про Фому, он мне про Ерёму. Ты заявил, что раст был невозможен в 70-е из-за тормознутости программ. Я говорю тебе, что нет. Он был невозможен из-за тормознутости компилятора: компилятор выполняет очень много работы, столько, сколько в 70-х было невозможно выполнить. А вот результат, в плане производительности и потребления памяти, как правило в пределах статистической погрешности от результата на C. Иногда быстрее, иногда медленнее, но там речь идёт о единицах процентов или меньше.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	69. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Ivan_83 (ok), 28-Апр-23, 23:57
	Да какие там 70-е, до CORE арихитектуры растоманов бы то 100% выгоняли везде понятнокакими тряпками. У меня почти топовый п3 не мог обычный 720p h.264 проиграть программно, а тут ещё вы со своей поделкой. Проверки там не все компиле тайм, и абстракции и прочий сахар тоже не бесплатный, поэтому на примитивном коде может быть около нулевая разница, а на практических реализациях разница может улететь в разы, как с крестами я неоднократно видел. Потом у С компилетайм проверки почему то не тормозят, а у современного С их там очень не мало. И последнее. Если вы посмотрите на самые частые и проблемные события в бизапаснасте то обычно это социнжиниринг и ошибки в конфигурациях, ошибки логические тоже часто встречаются и они от языка не зависят. Собственно ошибки связанные с особеностями С занимают весьма скромное место, и на мой взгляд не стоят решения через гниль.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Анонин (?), 29-Апр-23, 00:37
	> а на практических реализациях разница может улететь в разы но пруфцов мы как всегда от тебя не дождемся? > как с крестами я неоднократно видел. гениально! берем один язык и говорим что совсем другой ведет себя аналогично > Собственно ошибки связанные с особеностями С занимают весьма скромное место, и на мой взгляд не стоят решения через гниль. просто вранье на вранье)) Давай откроем cvedetails для кернела, напр за 2022год, потому что 23 еще в процессе, и отсортируем по score от 7 и выше CVE-2022-0435 - Overflow CVE-2022-34918 - Buffer Overflow CVE-2022-32250 - Use After Free CVE-2022-29581 - Use After Free CVE-2022-29156 - Double Free CVE-2022-28893 - Use After Free CVE-2022-23222 - NULL Pointer Dereference CVE-2022-1998 - Use After Free CVE-2022-1943 - Out-of-bounds Write CVE-2022-1882 - Use After Free CVE-2022-1786 - Use After Free CVE-2022-1679 - Use After Free CVE-2022-1652 - Use After Free CVE-2022-1116 - Integer Overflow or Wraparound (юху! что-то новенькое!) CVE-2022-0998 - Integer Overflow or Wraparound (ладно, не такое уж новенькое) CVE-2022-0995 - Out-of-bounds Write CVE-2022-0847 - Improper Initialization (ура! первая логическая... ну, как логическая, этот хлам просто позволяет так делать) CVE-2022-0742 - Failure to Release Memory Before Removing Last Reference ('Memory Leak') CVE-2022-0646 - Incomplete Cleanup (вторая логическая! но если бы был бы нормальный RAII, хотя стоп, мы же про си говорим, какой RAII...) CVE-2022-0500 - Failure to Constrain Operations within the Bounds of a Memory Buffer CVE-2022-0185 - Integer Overflow or Wraparound CVE-2021-34866 - Access of Resource Using Incompatible Type ('Type Confusion') - логическая, исправляется нормальной системой типов CVE-2021-22600 - Double Free СVE-2021-4197 - Improper Authentication - логическая CVE-2021-4157 - Failure to Constrain Operations within the Bounds of a Memory Buffer CVE-2021-4154 - Use After Free CVE-2021-4093 - Out-of-bounds Read CVE-2021-3847 - Improper Preservation of Permissions - логическая CVE-2021-3773 - хз, пусть будет логическая CVE-2021-3760 - Use After Free CVE-2021-3752 - Use After Free CVE-2021-3715 - Use After Free CVE-2021-3656 - Missing Authorization - логическая Итого - у нас 33 ошибки, из которых максимум 7 логических, а остальные 26 (или 79%) - традиционное сишное д***мо с памятью. И даже если раст смог бы избавить не от всех этих ошибок, а только от половины - то все равно бы "недопущенных" было бы больше чем логических. И сколько дыряшного кода не приводит к CVE - можно только гадать. А ты можешь думать что хочешь)))
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Ivan_83 (ok), 29-Апр-23, 01:24
	Не дождётесь, я ж на гниле не пишу. Всего 33 типа ошибки на такую огромную кодовую базу, давай покажи сколько с помощью них нахакали. Вот тебе новость: http://www.opennet.me/opennews/art.shtml?num=59036 и такого полно, и всякое прямо без паролей в инет выставляют - даже ломать не надо. Я это к тому, что в денежном эквиваленте ущерб от этих ошибок вообще не виден на общем фоне. Потом сходи посмотри на вордпресс какойнить, который на пхп где С ошибок и близко нет, и оцени сколько ошибок там и насколько они эксплатируемые, и учти что кодовая база там по меньше.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Анонин (?), 29-Апр-23, 10:28
	> Всего 33 типа ошибки на такую огромную кодовую базу Мда... ты опять недогоняешь. Это 33 cve за 2022 год с скором больше 7. А самих cve на порядок больше - 300 с чем-то за тот же год. Плюс не каждый баг является CVE. Думаю обычных багов порядка на два-три больше. Поэтому еще раз - из группы ошибок, которые представляют наибольшую угрозу для безопасности пользователя - 79% сишного рукодупство с памятью. Что 10 лет назад, что 20 лет назад, что сейчас - сплошные out-of-bounds, use-after-free, double-free и тд. Сишники... сишники никогда не меняются > Я это к тому, что в денежном эквиваленте ущерб от этих ошибок вообще не виден на общем фоне. И пруфцов как обычно не будет?) > Потом сходи посмотри на вордпресс Ахаха, вот мы и скатились до сравнения ядра линукса с поделками на пыхе! Шикарно. Может еще сравним с лабами школьников из спецшкол? На их фоне ядро будет выглядеть прост прекрасно.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Ivan_83 (ok), 29-Апр-23, 14:11
	Чувак, жизнь полна ошибок, ошибатся, признавать ошибки, исправлять ошибки - таков путь. Я не знаю как вас воспитывали и обучали (надеюсь не сильно били током) что вы так боитесь любых ошибок. Пых такой же как раст, или вы думаете что расте будут писать какие то особенные эльфы, совсем не похожие на гоблинов с пхп? Любой высокоуровневый язык привлекает как раз низко квалифицированных разрабов, которые ничего не понимают и не хотят понимать. А поскольку гниль пеарят как "язык для илиты где нет ошибак" то он быстро наберёт как раз разрабов уровня пхп пограмист, которые будут везде с умным видом говорить: "раз собралось значит ашибак нет, капелятыр гарантырует!" и будет плести кучу умных слов про трейты, тесты и прочее. Не нравится пхп, возми какую нить джангу на петоне, или любой другой достаточно крупный проект на любом относительно выкоуровневом языке. Те я веду к том, что среднее колличество ошибок относительно кодовой базы примерно постоянная величина если специально не проводить отбора пограмистов и специально не вводить в процесс разработки методики для уменьшения ошибок и их раннего обнаружения. Условно через 10 лет на гниле будет быдлокодеров даже больше, потому что они придут с улицы и не будут нифига понимать в происходящем. Это сейчас под действием пропаганды на гнль свитчатся всякие Сишники и крестовики которые что то видели и им надоело думать о том откуда берутся ошибки.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Анонин (?), 29-Апр-23, 15:34
	Мы не боимся ошибок. Просто на ошибках надо учиться. А не повторять их из года в года с жалкими оправданиями. Ну а если ты не учишься... то у меня для тебя плохие новости)) А на си сейчас пишут великие умы? Или какие-то особенные эльфы? Нет, такие же быдлокодеры что на пыхе, только с непомерным ЧСВ. > и будет плести кучу умных слов про трейты, тесты и прочее. Ахаха, ну да, тесты не нужны)) Мне пофиг на логически ошибки в проекте - они всегда были и будут. Но вот не нравится, что условный чат клиент получит доступ куда не положено потому, что его разраб использует дырявый ImageMagick, быдлокодер которого не удосужился проверить входные данные. Или получит рут, прислав как любят говорить, "специально оформленный пакет". > Это сейчас под действием пропаганды на гнль свитчатся всякие Сишники и крестовики Так это ж прекрасно! Если слабый разраб умудриться допустить ошибку с памятью в расте, только представь что он может натворить в проекте на с++ или си)))
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Ivan_83 (ok), 29-Апр-23, 16:00
	Раз вы их не боитесь - чего постоянно о них говорите? Ошибки повторяют и ли не обучаемые или по забывчивости, не внимательности либо их совершают в первый раз. Это проблема людей, не языка. На С пишут те кто может себе это позволить. Все неосиляторы уходят на языки высокого уровня и какакодят там. Какакодеры с пыха и петона и прочих не идут на С почти никогда потому что у них ничего не собирается, потом ничего не работает и падает непонятно почему. Чтобы вас не беспокоило что у вас кто то там рут получит или ещё что то случится - нужно принимать меры чтобы это не имело серьёзных последствий, потому что это всё равно когданибудь случится, происто исходя из теории вероятности. Прекрасно, только держите свою гниль по дальше от существующих проектов.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Анонимусс (?), 29-Апр-23, 22:38
	> чего постоянно о них говорите? Потому что они наносят ущерб, в том числе экономический, это же очевидно! Утечки перс. данных, украденные коммерческие секреты, вымогатели, шифровальщики. Это мало? > или по забывчивости, не внимательности либо их совершают в первый раз. Именно потому что мясные мешки забывчивые и невнимательные by design, то нужно переложить рутинные проверки на машину. Все неосиляторы остались на сишечке. Потому что там и синтаксис примитивнейший, и стандартная либа убогая по самое немогу, поэтому сидишь целый день байтики из буфера в буфер перекладываешь. Годиков десять или двадцать. А потом, с настолько окостеневшими мозгами, ничему новому научиться не можешь. Помню как один такой сишник-ембедевщик пытался хаскель освоить. Ржака продолжалась месяца два наверное, а потом он таки сдался. > потому что это всё равно когданибудь случится поэтому лучше чтобы шанс этого события был минимальным, "происто исходя из теории вероятности" > Прекрасно, только держите свою гниль по дальше от существующих проектов. Прекрасно, мы услышали твое крайне важное для нас мнение и продолжим улучшать существующие проекты))
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Ivan_83 (ok), 30-Апр-23, 01:37
	И сколько утечек и взломов было по вине С дырок против общего числа? Эмбед пограмисты - это ближе к электроникам, там несколько другой склад ума и несколько другая культура разработки. Смешной у вас подход к теории вероятности. Вам говорят что это не избежно а вы вместо рекавери и минимизации ущерба бегаете с надеждой что это не произойдёт.
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	145. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (133), 29-Апр-23, 21:20
	> Чувак, жизнь полна ошибок, ошибатся, признавать ошибки, исправлять ошибки - таков путь. Есть другой путь. Значительно бОльшую часть ошибок исключить. Вон разработчики андроида частично это смогли, выбрав другой путь - в новой нативщине вытеснять си/плюсы в пользу раста. Вот что они сказали в декабре 2022 насчет типичных сишных ошибок памяти: "To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code." и в новом нативном коде (это си/плюсы/раст) раста там уже 21% и планируют это дело увеличивать. Там же, в конце резюме, итог: "What’s next? Migrating away from C/C++ is challenging, but we’re making progress. Rust use is growing in the Android platform, but that’s not the end of the story. To meet the goals of improving security, stability, and quality Android-wide, we need to be able to use Rust anywhere in the codebase that native code is required. We’re implementing userspace HALs in Rust. We’re adding support for Rust in Trusted Applications. We’ve migrated VM firmware in the Android Virtualization Framework to Rust. With support for Rust landing in Linux 6.1 we’re excited to bring memory-safety to the kernel, starting with kernel drivers. As Android migrates away from C/C++ to Java/Kotlin/Rust, we expect the number of memory safety vulnerabilities to continue to fall. Here’s to a future where memory corruption bugs on Android are rare!"
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	162. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Ivan_83 (ok), 30-Апр-23, 01:42
	А ты не думал что это не про раст а про сохранение бюджета и рабочих мест? Ну вот что там в андройде ещё писать? Основное написано, можно выгонять 80% народа, оставшиеся будут поддерживать то чот есть и допиливать редкие новые фичи. И тут они нашли фатальный недостаток и теперь надо в поте лица всё переписать с нуля, давайте ещё рабов на галеру!!! И пайку увеличивайте!!! Срочно, тонем!!!! > "To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code." > раста там уже 21% Ну да, а если просто переписать на С с нуля оно бы отличалось?)
	Ответить | Правка | Наверх | Cообщить модератору

	227. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 06-Май-23, 19:25
	> А ты не думал что это не про раст а про сохранение > бюджета и рабочих мест? С этим сейчас будет душновато. И тут коса вполне может найти на камень. Если кто не заметил, айти сейчас не очень. А самые хайпованые почему-то трансформируются в записи на layoffs.com или как там его правильно. Чем хайповее и сиюминутнее нечто - тем быстрее оказывается что без вот этих, дескать, можно и обойтись если прижало.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Ivan_83 (ok), 29-Апр-23, 14:30
	Вон там выше уже новый растоман: https://www.opennet.me/openforum/vsluhforumID3/130337.html#81 просто илита, ваш будущий коллега.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	103. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 11:42
	И даже если бы, да кабы, грибы, бабушка, дедушка, вот это всё. Хеллоуворлдщики ядро не перепишут. Максимум пару драйверов на 500 строк, и то тех, где сложной логики нет.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	142. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (139), 29-Апр-23, 17:19
	>Мне не нужна безопасность какая то там, у меня для этого замок на двери, и если будет мало я куплю ствол и подключю сигнализацию. Очень плохие новости для тебя. Лет тебе маловато, это пройдет, со временем... А тем временем новое поколение напилит другой треш. Молодёжь сегодня разная бывает, да :)
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	78. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Аноньимъ (ok), 29-Апр-23, 03:27
	Когда-то компьютеры отлично исполняли лисп и не только. И только потом вдруг решили что это не круто и нужно писать на СИ под примитивные вычислители (си процессоры они же риск)
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	87. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от аНОНИМ (?), 29-Апр-23, 06:23
	> Когда-то компьютеры отлично исполняли лисп и не только. > И только потом вдруг решили что это не круто и нужно писать > на СИ под примитивные вычислители (си процессоры они же риск) Платные пропихиватели гнили готовы на всё, даже на искажение истории ВТ. За похлёбку в день.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от n00by (ok), 29-Апр-23, 16:25
	Ричард Столлман считал, что он нашел злую силу, которая уничтожила лабораторию. Он считал, что это Symbolics. Он дал себе клятву: «Я никогда не буду использовать LISP'машину Symbolics сам, и никому не буду помогать в этом… Я не буду говорить ни с кем, кто работает в Symbolics или с людьми, которые с ними поддерживают отношения”. ... Ричард Столлман ушел из МТИ, но в его голове созрел план: написать свою версию популярной закрытой компьютерной операционной системы UNIX и раздать ее всем желающим. Стивен Леви Хакеры: Герои компьютерной революции
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	154. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Neon (??), 29-Апр-23, 23:13
	И в итоге никакой ОС Ричард Столлман так и не написал. Маниловщина обыкновенная. А написали совсем другие люди.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от soarin (ok), 29-Апр-23, 02:11
	> Выбор был: пишем на С (может с асмовыми вставками) чтобы тяжёлые вычисления не тормозили или пишем на вижалбейсике или чем то подобном когда надо быстро накидать прототип или гуй. То что сейчас кресты расжирели невероятно Типичный бред от диванного аналитика. Расжирели они разве что на машине разработчика, когда при компиляции можно день гулять. Но пользователя это не волнует. А ассемблер не является волшебной лампой Аладина. В среднем ты с ассемблерной вставкой тоже самое и сделаешь.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	80. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Ivan_83 (ok), 29-Апр-23, 03:58
	Насчёт результата не знаю а время компиляции крестов просто запредельное, как и у ржавчины. Да, вставки на асме сейчас не часто имеют смысл когда речь об С проекте, но SIMD всё ещё может легко дать х2+ при удачном стечении обстоятельств и в правильных руках.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от soarin (ok), 29-Апр-23, 05:41
	> но SIMD всё ещё может ну да... хотя к чему это, какие-то бредовые заключения постоянно.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 29-Апр-23, 15:13
	> время компиляции крестов просто запредельное, как и у ржавчины. Ага. И ты не знаешь почему так, и никогда не трудился хотя бы погуглить этот вопрос, и считаешь всех вокруг тупыми, что они не умеют писать компиляторы или готовы мириться с таким временем компиляции. Так кто тупой-то в этой ситуации на самом деле?
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	129. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Ivan_83 (ok), 29-Апр-23, 15:54
	Нафигачили там синтаксического сахара вот оно часами и компилирует, как гниль.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Срыватель покровов (?), 29-Апр-23, 09:15
	При этом Си всё ещё хуже  Фортрана в вычислениях. Причины использовать Си не вижу.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	155. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Neon (??), 29-Апр-23, 23:20
	Фортран для мазохистов, родом из 60х). Не осиливших Си.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от pda (ok), 28-Апр-23, 23:15
	Это не возможно. Дефективен сам подход независимой реализации кеша и спекулятивного выполнения. Т.е. надо буквально добавлять дополнительную память для спекулятивных веток, организовывать COW копирование из основного и получать спекулятивный кеш для спекулятивной ветки, переключая его вместе с спекулятивным результатом, если спекулятивно выполненная инструкция оказалась по факту верной. Теоретически это возможно. Но это может потребовать значительной переработки дизайна процессоров и не известно насколько сложной окажется исправленная реализация. Возможно непрактично сложной. Ну или идти по другому пути. Пытаться всеми правдами и не правдами уменьшить время доступа к памяти до времени доступа к L1. Тогда от кеша можно будет отказаться. Только это может оказаться ещё более сложной задачей.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	85. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от аНОНИМ (?), 29-Апр-23, 06:10
	>[оверквотинг удален] > COW копирование из основного и получать спекулятивный кеш для спекулятивной ветки, > переключая его вместе с спекулятивным результатом, если спекулятивно выполненная инструкция > оказалась по факту верной. > Теоретически это возможно. Но это может потребовать значительной переработки дизайна процессоров > и не известно насколько сложной окажется исправленная реализация. Возможно непрактично > сложной. > Ну или идти по другому пути. Пытаться всеми правдами и не правдами > уменьшить время доступа к памяти до времени доступа к L1. Тогда > от кеша можно будет отказаться. Только это может оказаться ещё более > сложной задачей. Вы прочитали отрывок 'как программисты на пыхопэ представляют себе процессор'
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 11:46
	Бугагэ нет, прогромисты на пыхе разные бывают. Я например. Который с ассемблера начинал. Скорее отрывок "процессоры в мире рoзовых поней и смyзи".
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от аНОНИМ (?), 29-Апр-23, 21:39
	Умение погромировать на асме не даёт автоматического понимания, как устроены процессоры.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 22:34
	Бгг. Без понимания, как устроены процессоры, в асм лучше не соваться.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 23:27
	> Т.е. спекулятивно надо спекулятивно буквально спекулятивно добавлять спекулятивно дополнительную спекулятивную память спекулятивно для спекулятивных веток, спекулятивно организовывать спекулятивное COW копирование из основного спекулятива и спекулятивно получать спекулятивный кеш для спекулятивной ветки, спекулятивно переключая его вместе с спекулятивным результатом, если спекулятивно выполненная спекулятивная инструкция спекулятивно оказалась по спекулятивному факту спекулятивно верной. Fixed.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	153. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Neon (??), 29-Апр-23, 23:07
	Спекулятивное выполнение и есть принципиальное р.е.ш.е.т.о. Как его не штопай и не патчь. Ошибка в самой идее..
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	157. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 23:28
	У вас есть идея лучше?
	Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–2 +/–
Сообщение от Вован (??), 28-Апр-23, 16:07
> можно использовать А точно можно, простите? Хоть одна демка есть, ну делаться никто не просит сурсамм, но хотя бы сами бы реализовали и показали что "можно". Иначе это просто пук.
Ответить | Правка | Наверх | Cообщить модератору

7. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
Сообщение от InuYasha (??), 28-Апр-23, 16:08
Админы Архива снова вздыхают над графиком трафика... Пока есть потребность в производительности, будут атаки на замеры времён. Если проц заставить выполнять все инструкции монотонно (и, соответственно, медленно), то <s>жабокодеры вымрут</s> мир погрузится в двухтысячные. )
Ответить | Правка | Наверх | Cообщить модератору

	18. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от аНОНИМ (?), 28-Апр-23, 16:34
	Абсолютно верно. Вышенаписавшему про 'дырени' нетоварищу-троллю могу посоветовать борду с процом allwinner D1 -- в нём нет никаких спекуляций и OoO, чисто 1 классический конвеер, как Патерсон и Хеннеси (для алкашей: не коньяк, а человек) завещали. Даже кеша Л2 нет, а Л1 быстро вымывается, атаки труднее делать. Ну и ядро ровно одно -- никаких там мультитрединговостей. Линукс там работает, так что всё ок. Но всё ТОРМОЗИТ...
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (75), 28-Апр-23, 16:52
	> Но всё ТОРМОЗИТ на arm cortex-a53 жабоандроид летает, известным уязвимостям не подвержен https://developer.arm.com/Arm%20Security%20Center/...
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от аНОНИМ (?), 29-Апр-23, 06:08
	Ещё бы был подвержен, 2-wide decode, dual-issuing SOME instructions. Это уровень примерно пеньтиума-одын, in-order. Ну а что андроид летает - это конечно же враки, он нигде не летает.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 23:29
	Летает, но низенько и недолго. Вместе с очередным китайфоном до ближайшей стены.
	Ответить | Правка | Наверх | Cообщить модератору

	228. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 06-Май-23, 19:27
	> Летает, но низенько и недолго. Вместе с очередным китайфоном до ближайшей стены. Ну а ты можешь ксеон поставить в китайфон. И тележку с генератором бонусом к нему давать.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 23:28
	Собери мне уже хромиум на cortex-a53, потом расскажешь, сколько недель заняло.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	176. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (176), 30-Апр-23, 22:11
	> Собери мне уже хромиум на cortex-a53 таакие задачи отлично параллелятся так что ядер 100 уделают твой настольный дырявый пека на раз
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 30-Апр-23, 22:31
	Ну так давай 100 на 100 :D
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (185), 01-Май-23, 09:54
	С одним одинаковым БП на 100 Вт
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 01-Май-23, 10:53
	БП мне абсолютно фиолетов, мне важно время сборки. Электричество дешевле времени.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Аноним (185), 01-Май-23, 11:24
	> БП мне абсолютно фиолетов потому что не понимаешь суть - с ооо процессор потребляет намного больше потому что исполняет бесполезный код а результаты выбрасывает > Электричество дешевле времени давно пора налог на глупость вводить
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 01-Май-23, 11:34
	Это точно. Тратить время на попытки сделать из буханки троллейбус - как раз поцыент для сего налога.
	Ответить | Правка | Наверх | Cообщить модератору

	229. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 06-Май-23, 19:30
	> потому что не понимаешь суть - с ооо процессор потребляет намного больше > потому что исполняет бесполезный код а результаты выбрасывает Ты так радостно спалил почему ARM придумал такую странную штуку как big.LITTLE, где они пытабтся и на елку влезть и зад не подрать. Но ты распинаешься перед интелфаном, которого вообще не хватит на осознание такого хайтека :)). А так то идея весьма даже: пока нагрузка небольшая, пашут энергоэффективные in-order ядра. А если надо быстро и много посчитать, подымают "big" OoO ядра уже. Интелу конечно же до такого уровня технологий как раком до китая.
	Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

	195. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 01-Май-23, 17:53
	> БП мне абсолютно фиолетов, мне важно время сборки. Электричество дешевле времени. Время у машин дешевое, вот не надо тут. Врядли вы разработчик хромиума чтобы вас время его сборки еще и реально волновало к тому же. А кого реально волновало - понаставили билдферм, которых можно и из A53 понаделать, вопрос в количестве. И тут еще вопрос что будет дороже, прожорливее и дольше билдить.
	Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

	206. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 02-Май-23, 10:46
	Понимаешь в чём дело, я могу в 1U (с кастомным охлаждением правда) зафигачить 192 ядра x86. Куда ты при этом свои A53 девать будешь - я хз.
	Ответить | Правка | Наверх | Cообщить модератору

	230. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 06-Май-23, 19:39
	> Понимаешь в чём дело, я могу в 1U (с кастомным охлаждением правда) > зафигачить 192 ядра x86. Вы удумали с ARM в копипасте ядер зарубиться? Удачи на этом направлении :). Так то армовские ядра сильно мельче и если цель именно ядер накопипастить... > Куда ты при этом свои A53 девать будешь - я хз. Да блин, вон там у Ampere есть процы с дохреналионом ядер и вполне серверным обвесом и даже несколькими сокетами, если было надо вот именно это. А еще некоторые хостинги продают малины свинченые в тот же 1U, так что вместо виртуалки можно купить себе выделенный "микродедик", имеющий определенные плюсы относительно виртуалок (стабильный перфоманс который ни с кем не делится). Сколько у них там ядер лезет в 1U считать ессно надо. И это... какойнить гигабитный свич на дофига портов стоит копейки, как и одноплатники. Можно дешево и сердито расширять понемногу даже и не будучи транснациональной корпой с мешком денег. Срубил эн денег на удачном проекте, добавил несколько одноплатничков в ферму, пустячок а бонус к компилу - вот он. И так в цикле. А твой 192 ядерный 1U стоит чемодан денег, и его только атомарно одним шматом. В крупной корпе такое еще попробуй себе выбей, они ж жадные что капец, особенно сейчас, когда прижимать стало. А "из своих" оно в таком виде и вовсе накладно получается.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 01-Май-23, 10:57
	Ну и да, давай с одним одинаковым БП. На 500W. Я в таковой впихну ОДИН EPYC 9654P, у него правда не 100, а 96 ядер, но ничего, пойдёт. А тебе удачи раскидать всё это на пачку A53.
	Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

	188. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 01-Май-23, 11:05
	Да, давай ещё в 1U форм-факторе, раз уж такая пьянка.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от anonomus (?), 28-Апр-23, 17:01
	как тот самый нетоварищ-тролль могу только кинуть тебе ссылку на тесты фороникса за 19 год https://www.phoronix.com/review/spec-melt-8way/2 потеря производительности от 9% до 44% спустя джва года худший результат 77% от варианта без патчей https://www.phoronix.com/review/spectre-meltdown-2/11 разница даже не на порядок! неужели ты готов ради даже 44% просто сделать себе дырень в системе? уязвимость которую может использовать вкладка в броузере? аНОНИМ, ты серьезно?
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	34. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Аноним (34), 28-Апр-23, 17:14
	Пруфы насчёт успешного и  работающего на реальной системе использования уязвимости вкладкой в браузере будут? Или как обычно?
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от anonomus (?), 28-Апр-23, 17:23
	Аноним нынче или ленивый пошел, или настолько глупый что поиск в интернете не осилил... Вот proof-of-concept который написан на жабаскрипте https://security.googleblog.com/2021/03/a-spectre-proof-of-c...
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 23:30
	Нэ работает этот пох в реальных условиях, его под чистой системой ещё потюнить надо, чтобы хоть какой-то результат за конское время получить.
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 01-Май-23, 17:55
	> Нэ работает этот пох в реальных условиях, его под чистой системой ещё > потюнить надо, чтобы хоть какой-то результат за конское время получить. Первый самолет тоже больше этажерку с колесами напоминал. Ничего не говорит о том до чего можно доразвить направление.
	Ответить | Правка | Наверх | Cообщить модератору

	201. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 01-Май-23, 19:07
	Для meltdown и l1tf рабочие похи есть буквально с момента появления - потому что оно реально работает. Всё остальное - это попытка подслушать разговор в квартире за 500 метров через изменение оттенка светофора на перекрёстке, вызываемое вибрацией. В теории можно, но в реальном мире не работает.
	Ответить | Правка | Наверх | Cообщить модератору

	231. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Аноним (-), 06-Май-23, 19:46
	> Всё остальное - это попытка подслушать разговор в квартире за 500 метров > через изменение оттенка светофора на перекрёстке, вызываемое вибрацией. Ты как мне кажется сильно недооцениваешь мощь цифровых технологий обработки сигналов. > В теории можно, но в реальном мире не работает. В реальном мире человечество совершенно рутинно работает с сигналами слабее шума по величине и это прекрасно работает.
	Ответить | Правка | Наверх | Cообщить модератору

	237. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 07-Май-23, 07:57
	Ну, давай, расскажи нам сказочек про уверенный приём одиночных сигналов слабее шума :D
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Ivan_83 (ok), 28-Апр-23, 18:14
	Скажу так: защита в мобиле не нужна. Но не потому что там ничего ценного не бывает, а потому что там обычно браузер тормозится на время когда он в фоне, ровно как и наоборот, так что вычитать чувствительную инфу из других приложений скорее всего никак не выйдет при всём желании. Что до паролей из самого андйройда - у меня лично там только пароль от вифи, никаких аккаунтов я не добавляю в систему, шифрование данных мне тоже не интересно.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	112. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (102), 29-Апр-23, 12:09
	Понимаю. Скрывать тебе нечего, но пароли к своим аккуантам ты не дашь. Вот и вернулись в 2005 год.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Ivan_83 (ok), 29-Апр-23, 14:36
	Не дам, но и украсть через такие дырки их вряд ли выйдет.
	Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
Сообщение от AKTEON (?), 28-Апр-23, 16:28
<s>Грузите апельсины бочками </s> Запускайте open-source applications на dedicated сервере (с)
Ответить | Правка | Наверх | Cообщить модератору

	24. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (12), 28-Апр-23, 16:42
	Если у вас есть достаточно денег, то да.
	Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
Сообщение от nagual (ok), 28-Апр-23, 16:30
Все эти Spectre и Meltdown носят чисто теоретический характер и якобы что то там позволяют определить, ни одного рабочего экспа так и не всплыло ... Данный тип атак следует назвать - атака для анонистов.
Ответить | Правка | Наверх | Cообщить модератору

	20. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
	Сообщение от Аноним (12), 28-Апр-23, 16:36
	Тебе s/ничего_не_угрожает/нечего_скрывать
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Аноним (34), 28-Апр-23, 17:19
	Молодец, лабораторные условия от реальной жизни не отличаешь, но лозунги зазубрил на "отлично"! Вот такие люди и нужны.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от anonymous (??), 29-Апр-23, 00:33
	Как говорил Остап Бендер - нет ладьи значит и не было! Что, подгорает что любимка то дырявая даже через много лет после Спектра?
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	98. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Аноним (2), 29-Апр-23, 10:22
	Да чем чаще это повторять тем будет более безопасно. Это как с растом. Главное верить в свою полную безопасность.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

17. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
Сообщение от Аноним (12), 28-Апр-23, 16:33
Всё-таки хорошо в архитектуре RISC-V, что там нет регистра флагов - меньше векторов атак на оседающие данные.
Ответить | Правка | Наверх | Cообщить модератору

	23. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+3 +/–
	Сообщение от Аноним (5), 28-Апр-23, 16:41
	Ещё есть Power https://www.opennet.me/opennews/art.shtml?num=51327 https://en.wikipedia.org/wiki/Power10
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+6 +/–
	Сообщение от Фанатик (?), 28-Апр-23, 18:08
	Там вообще ничего нет
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	92. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+4 +/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 08:52
	Там вообще всё хорошо. Кроме производительности. Которой нет, не было, и в силу архитектуры - не будет.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	111. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	–1 +/–
	Сообщение от Аноним (102), 29-Апр-23, 12:03
	Будет но позже.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+3 +/–
	Сообщение от Аноним (115), 29-Апр-23, 13:20
	... жаль только, жить в эту пору прекрасную ...
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 14:30
	Сильно позже. От слова "никогда".
	Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

	210. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Michael Shigorin (ok), 03-Май-23, 22:57
	Итак, на что спорим?
	Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

	95. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Аноним (2), 29-Апр-23, 09:46
	В RISC-V можно вставить свой левый проц память там будет работать своя параллельная ос и об этом никто не узнает, пока ты не выйдешь на миллиардные обороты.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	110. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (102), 29-Апр-23, 12:01
	Ну с x64 до сих пор прокатывает и после миллиардных оборотов. И ничего, даже комментаторы на опеннете о параллельной оси во всех современных интеловских(кроме некоторых госконтрактов) и амдшных матерях. Да и на 99% ARM смартфонов тоже.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 01-Май-23, 17:56
	> В RISC-V можно вставить свой левый проц Но пока вставили в x86, в виде ME и PSP. А с RISCV - особенно опенсорсным - всегда есть риск что кто-то выкатит респин без "фичи" и еще нагло попиарится на этом.
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	211. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Michael Shigorin (ok), 03-Май-23, 22:58
	> А с RISCV - особенно опенсорсным И как, много примеров?  Чтоб ещё и хоть калькулятор тянули -- особо не прошу.
	Ответить | Правка | Наверх | Cообщить модератору

	232. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 06-Май-23, 19:49
	> И как, много примеров?  Чтоб ещё и хоть калькулятор тянули -- > особо не прошу. Я кажется другой анон, но вот лично вам в другом месте накинул пример как 906-й XuanTie накопипастили уже за копейки. При том этот хуан теперь начинается от 12 баксов за весь одноплатник. И если кто хотел с технологией познакомиться - "налетай, подешевело!" Ну а сколько 12-баксовых хуанов можно накупить за стоимость 192-ядерного x86 пусть фаны интела и прочих переростков посчитают. Мне их столько не надо а вот десяток под более скромные задачи - пуркуа б да не па?!
	Ответить | Правка | Наверх | Cообщить модератору

	209. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Michael Shigorin (ok), 03-Май-23, 22:57
	Всё нужное там бережно сохранили, не переживайте за риск-хайп -- думаете, зря там айбиэмерку поставили главой фундейшена?.. http://vk.com/@erthink-risc-v
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

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

35. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
Сообщение от Аноним (35), 28-Апр-23, 17:15
CVE нет, протестировали три дырявых SkyLake'а, как-то всё неубедительно. После SkyLake вышли Ice/Tiger/Rocket/Alder/Raptor.
Ответить | Правка | Наверх | Cообщить модератору

	192. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (2), 01-Май-23, 11:48
	Ну всё значит мы в полной безопасности.
	Ответить | Правка | Наверх | Cообщить модератору

	223. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Прыгающий Ленивец (?), 06-Май-23, 12:23
	В описании сказано, что для эксплуатации нужно уметь точно замерять время выполнения инструкции jcc. На практике непонятно как это сделать кроме как из под отладчика. Если мы можем отлаживать атакуемый процесс, то непонятно для чего все эти сложности, ведь можно просто прочитать из памяти строку, с которой идет сравнение. Если же речь о замере времени отклика, какой-то более сложной системы, например, у нас есть программа, которая проверяет пароль и мы начнем скармливать ей разные пароли и очень точно мерять время отклика, то полученные данные будут сильно зашумлены
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

99. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
Сообщение от Аноним (99), 29-Апр-23, 10:25
> приводящая к утечке данных по сторонним каналам запретить сторонние каналы и дело с концом!
Ответить | Правка | Наверх | Cообщить модератору

	101. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+3 +/–
	Сообщение от Аноним (175), 29-Апр-23, 10:48
	Гениальное решение! Народ, тут к нам кажется целый депутат заглянул на огонек!
	Ответить | Правка | Наверх | Cообщить модератору

	198. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Аноним (-), 01-Май-23, 17:57
	> запретить сторонние каналы и дело с концом! Для этого сначала надо запретить законы физики. И математику тоже неплохо бы, на всякий случай.
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	212. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Michael Shigorin (ok), 03-Май-23, 22:59
	Полагаете, AMD и МЦСТ удалось именно это?
	Ответить | Правка | Наверх | Cообщить модератору

	224. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Прыгающий Ленивец (?), 06-Май-23, 12:28
	Мцст удалось закрыть документацию и ограничить доступ к железу. У них есть баг баунти программа? Думаю при должном уровне заинтересованности дырок там будет найдено в товарном количестве.
	Ответить | Правка | Наверх | Cообщить модератору

	233. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (233), 06-Май-23, 19:56
	> Полагаете, AMD и МЦСТ удалось именно это? Полагаю что чуда не произошло и у больших процов неизбежно будут большие грабли, что бы маркетинг там не вещал. А вон то это вообще пример галантерейщика и кардинала 2.0. АМД сейчас в верхней строчке топ500, за номером 1, если что. Вот это - демо технологических возможностей которое понятно любому технарю.
	Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

147. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
Сообщение от Neon (??), 29-Апр-23, 21:50
Никогда такого не было и вот опять.) Плата за спекулятивное выполнение операций. Принципиальная архитектурная дыра.
Ответить | Правка | Наверх | Cообщить модератору

	150. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 29-Апр-23, 22:36
	Там больше хайпа чем дыры ныне.
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
	Сообщение от Аноним (-), 01-Май-23, 18:00
	> Там больше хайпа чем дыры ныне. Не, вот извините, еще начиная с времен 386 предполагалось что процессы будут изолированы друг от друга, и вообще. И тут вдруг оказывается что реальный уровень безопасности этого недоразумения мало ушел от Win95 и прочих DOS где всем можно все, система проходной двор, потому что интел видите ли решил срезать пару углов в оптимизациях перфоманса в надежде что никто не заметит развал абстракции в этом месте. А всякие хлипкие отговорки - вам интел что, доплачивает за даунплей? Или вы их акционер? Судя по длинному списку вулнов там халтура на халтуре и халтурой погоняет. Особенно у интеля, но и амд отметился. Да даже ARM слегка досталось.
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 01-Май-23, 19:05
	Они и изолированы. Кроме как у штеуда, который привилегии на спекулятивке проверять читернул, и стали возможным meltdown с l1tf. Остальные вторичные каналы позволяют что-то там в лабе померить, но в реальных условиях, когда замеры смешиваются с шумом от кучи процессов, оно просто не работает - ни одного рабочего PoC разнокалиберных спектров, который бы не требовал чистой системы и тонкой настройки - так и не появилось.
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Аноним (-), 06-Май-23, 20:04
	> Они и изолированы. Да вот как оказалось - довольно паршивая изоляция то. Крыша протекает. И при том у вот именно интеля больше и сильнее чем у всех остальных, которые не срезали углы в пользу перфоманса так по наглому. > Кроме как у штеуда, который привилегии на спекулятивке проверять > читернул, и стали возможным meltdown с l1tf. Остальные вторичные каналы позволяют > что-то там в лабе померить, но в реальных условиях, когда замеры > смешиваются с шумом от кучи процессов, оно просто не работает - Вы явно недооцениваете мощь цифровой обработки сигналов. А исследователи лишь первые ласточки. Это я так, реимплементнув пару лабораторных странных технологий говорю. Представляешь, я вот тоже теперь могу _свето_ диодом померять свет, и даже неожиданный коммуникационный канал устроить. Просто заимплементив идеи из вон той статьи. Значит это работает а статьи не пустой звук. В отличие от сказочников опеннета. > ни одного рабочего PoC разнокалиберных спектров, который бы не требовал чистой > системы и тонкой настройки - так и не появилось. Технологии не стоят на месте. Если есть минимальное отличие от рандома - усе, этого достаточно. Я даже немного умею в эту магию уже, поэтому рассказывать как это не работает ты будешь кому-то другому, кто эту магию чисел не пробовал на вкус.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 07-Май-23, 07:58
	От какого именно рандома? :) Ещё раз: в случае перехвата именно вот этого вот сигнала (в отличие от радио например) - у тебя даже характеристик среды заранее нет.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
	Сообщение от Tron is Whistling (?), 07-Май-23, 08:00
	Когда ты знаешь, что должно прийти - ты можешь магически попробовать это повыделять из шума. Но нужны знания либо о шуме, либо о целевом сигнале, которые становятся частью собственно SNR в конечном расчёте. В случае попытки увести то, не знаю, что, через неизвестную среду (неизвестное зашумление) - шансов нет. Что собственно отсутствием сколь-либо рабочих даже PoC за 3 года и подтверждается.
	Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

163. Скрыто модератором	+/–
Сообщение от антилошадь (?), 30-Апр-23, 03:52
всегда отключаю mitigations, всё это хрень полная, если ты не нефтяной магнат
Ответить | Правка | Наверх | Cообщить модератору

202. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
Сообщение от nc (ok), 01-Май-23, 21:37
Интересно, вот реальные хакеры и вирмейкеры пользуются этой экзотикой с временами выполнения инструкций, или все-же эксплуатируют банальные дыры в софте вроде переполнения буфера?
Ответить | Правка | Наверх | Cообщить модератору

	204. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от n00by (ok), 02-Май-23, 09:23
	Шифровальщики распространяют через "партнёрки". Эксплуатируют человеческий фактор и любовь админов к сладкому шекелю.
	Ответить | Правка | Наверх | Cообщить модератору

205. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
Сообщение от Аноним (205), 02-Май-23, 10:03
В техпроцессик упёрлись, трудно перепродавать каждый год одно и тоже... Тащите большую чёрную книгу с бекдорами! Начинаем замедлять :3
Ответить | Правка | Наверх | Cообщить модератору

	207. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+2 +/–
	Сообщение от Tron is Whistling (?), 02-Май-23, 11:25
	Ну кстати да, похоже на то. mitigations=off стало необходимостью, но и оно не 100% возврат, даже пересборка ныне уже не спасает. Но 99% - норм.
	Ответить | Правка | Наверх | Cообщить модератору

213. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+/–
Сообщение от Michael Shigorin (ok), 03-Май-23, 23:01
...когда читаешь очередные новости с того берега речки на своём "Эльбрус-16С"... :)
Ответить | Правка | Наверх | Cообщить модератору

	214. "Уязвимость в процессорах Intel, приводящая к утечке данных п..."	+1 +/–
	Сообщение от Аноним (214), 04-Май-23, 23:19
	Но Ленинград 48к всё равно круче! :-)
	Ответить | Правка | Наверх | Cообщить модератору

240. "Уязвимость в процессорах Intel, приводящая к утечке данных по сторонним каналам"	+1 +/–
Сообщение от Tron is Whistling (?), 07-Май-23, 08:08
Я наверн подытожу, задолбало реплаить на каждый спор. Все эти расхайпанные гипотетические дыры, для которых за годы даже рабочего PoC не появилось - интересны разве каким-либо DoD, где даже малейший риск утечки не допускается. Ради условного ООО Васян и Ко с парой миллионов евров на счетах никто даже заморачиваться с этим дерьмом не будет - проще директору этого ООО подослать спама с тёлочками, и он сам сольёт все пароли, где далее будут накопаны собственно аккаунты и банк-клиенты, что обычно и происходит. Не говоря уже о неизвестном Васяне Неко, который вообще мало кому интересен, разве что в спамбот машину превратить - чтобы вот тому ООО спам подсылать. Понятно, что продаваны от железячников этот хайп подхватили и распузыривают, ведь можно напихать ещё больше затычек, и продать ещё больше вот этих вкусных процов постарше несведущему обывателю, перепуганному страшными утечками его паролей от соцсетей с фоточками котиков. Но в целом ситуация немножко очевидна.
Ответить | Правка | Наверх | Cообщить модератору

	241. "Уязвимость в процессорах Intel, приводящая к утечке данных по сторонним каналам"	+/–
	Сообщение от Tron is Whistling (?), 07-Май-23, 08:12
	Вон в соседней новости ключи у мсявных утекли - и эта дыра куда поболее дыра, чем вот это всё. К тому же очень весело эксплуатабельная при необходимости.
	Ответить | Правка | Наверх | Cообщить модератору

	243. "Уязвимость в процессорах Intel, приводящая к утечке данных по сторонним каналам"	+/–
	Сообщение от n00by (ok), 08-Май-23, 07:04
	> задолбало реплаить на каждый спор. Может в качестве подтверждения эффективности спрашивать экспертов по эксплуатации Спектрумов и Мельдония о размерах их бот-нетов? С активистами СПО вроде работает просьба показать свой гитхап.
	Ответить | Правка | К родителю #240 | Наверх | Cообщить модератору

	244. "Уязвимость в процессорах Intel, приводящая к утечке данных по сторонним каналам"	+/–
	Сообщение от nagual (ok), 30-Май-23, 20:55
	>> задолбало реплаить на каждый спор. > Может в качестве подтверждения эффективности спрашивать экспертов по эксплуатации Спектрумов > и Мельдония о размерах их бот-нетов? > С активистами СПО вроде работает просьба показать свой гитхап. Времена частных ботнетов в прошлом, теперь всё у спецслужб ... Просто потому что взламывать шифры могут себе позволить только те кто может позволить создание квантового вычислителя.
	Ответить | Правка | Наверх | Cообщить модератору

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

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