Закрытие уязвимости требует обновления ОС, патчи для Linux уже вышли, Microsoft планирует закрыть её в рамках традиционного ежемесячного «вторника патчей». На данный момент детали уязвимости не разглашаются, но некоторые подробности всё-таки выплыли наружу благодаря Python Sweetness и The Register.
Уязвимость позволяет программам получать несанкционированный доступ к определённым данным в защищённой области памяти ядра. Предотвратить это можно, внедрив изоляцию памяти ядра (Kernel Page Table Isolation), которая сделает ядро «невидимым» для текущих процессов. Это не идеальное решение проблемы, но грядущие патчи для Windows, Linux и macOS будут использовать именно этот подход.
Однако подобное решение может очень серьёзно ударить по производительности. Падение производительности из-за изоляции может достигать 30 процентов. К счастью, последние модели процессоров Intel с технологией PCID (идентификаторы контекста процесса), возможно, позволяют уменьшить падение производительности, хоть и не избежав его совсем.
Уязвимость может эксплуатироваться в реальных условиях; под удар, в первую очередь, могут попасть компании, использующие виртуализацию.
«Разработка программного решения проблемы ведётся в срочном порядке, и уже недавно оно было внедрено в ядро Linux; в ядрах NT схожее решение начало появляться в ноябре,» — сообщает блок Python Sweetness. — «В худшем случае это повлечёт за собой серьёзное замедление в повседневных задачах.
»Есть повод подозревать, что уязвимы популярные окружения для виртуализации, включая Amazon EC2 и Google Compute Engine."
Microsoft Azure и Amazon Web Services уже запланировали временное отключение серверов на следующей неделе, хоть и не дают комментариев по поводу причины работ. Однако, вероятно, именно необходимость защититься от возможных атак с использованием найденной уязвимости является его причиной.
Заметьте, что AMD пока не упоминалась ни разу. Всё просто: процессоры AMD не подвержены данной уязвимости — а, следовательно, и не нуждаются в ресурсоёмкой защите от неё.
Томас Лендаки, участник работающей с Linux группы в AMD, сообщает:
«Процессоры AMD не подвержены атакам, от которых защищает изоляция памяти ядра. Архитектура AMD не позволяет получить доступ к данным при отсутствии соответствующих привилегий.»
К тому же, новые серверные чипы EPYC от AMD, а также их десктопные процессоры Ryzen Pro имеют технологию шифрования защищённой памяти, дающую дополнительную защиту от атак подобного рода.
Так или иначе, пока детали патчей не раскрываются, и Intel по понятным причинам предпочитает молчать, нам остаётся только ждать, когда можно будет полностью оценить серьёзность проблемы и угрозу, которую она несёт существующим компьютерным платформам. Но на данный момент всё это выглядит очень серьёзно. Патч с решением (kpti) для Linux добавил в ядро лично Линус Торвальдс.
Phoronix уже протестировали производительность при включённом kpti и пришли к выводу, что возможны просадки до 17-18 процентов.
Также сообщается, что патч для Linux будет по умолчанию включать kpti и на компьютерах с процессорами AMD, вызывая соответствующее падение производительности. AMD не рекомендует использовать kpti на компьютерах с процессорами AMD. Детали решения для Windows пока неизвестны.
Комментарии (479)
lpwaterhouse
03.01.2018 13:32«Это кривое и плохое со всех точек зрения решение, но вы жрите.»
Интел кажется совсем поехал без конкуренции.
23derevo
03.01.2018 16:45Обновления безопасности — это всегда слодные трейдоффы. Intel в данном случае решает сложную задачу, пытаясь балансировать между безопасностью и производительностью. Простых решений на таких масштабах не бывает.
Barma2012
03.01.2018 13:40Эх, вот не зря процы AMD мне всегда были более симпатичны, чем Intel )))))
yurisv3
03.01.2018 13:42+2Зашел увидеть этот коммент.
samodum
03.01.2018 14:30-1Зачем это писать?
evil_random
03.01.2018 16:19А зачем это писать? Тут вся ветка бессмысленная начиная с первого комментария.
Tertium
03.01.2018 14:08Да не, это от бедности нашей :)
Barma2012
03.01.2018 14:30Не обязательно. )))
Скорее всего потому, что AMD — это не Intel. Поддерживать не флагмана, а его ближайшего конкурента — мне кажется, это правильно.
vconst
03.01.2018 15:36Если решение продиктовано не технологией, а идеологией — нет, не правильно.
Areso
03.01.2018 16:08+2С точки зрения потребителя, имеющего долгосрочную стратегию, с позиции маркетинга — это правильное решение.
Ведь поддерживая флагмана можно получить монополию (поскольку конкурент умер, потому что его не покупали из-за того, что он не добрал каких-то N% в каком-нибудь бенче).
А относительно технологии: припой под крышкой (не все любят риск и пойдут на скальпирование), разблокированные множители из коробки без доплаты производителю процессора, долгая поддержка сокетов (а не почти каждый год по новому, не совместимому сокету), отсутствие IME… Уверен, фанаты AMD смогут привести еще что-то полезное, сам пользуюсь Intel, но за каждый успех AMD я искренне радуюсь.
sumanai
03.01.2018 17:17отсутствие IME
Не актуально.Areso
03.01.2018 17:20Да, с Ryzen AMD вроде как внедрили аналог. Но сколько лет они сопротивлялись такому искушению)
V1tol
03.01.2018 21:38Кстати, на некоторых материнках под Ryzen его можно отключить )
navion
04.01.2018 07:53Для Интела это тоже начинают вводить.
YuriM1983
04.01.2018 08:44Пофиг. Достаточно использовать другую сетевую карту и уязвимости нет.
Tyrauriel
04.01.2018 10:20Почему МЕ не может выйти в сеть через другую сетевую карту?
YuriM1983
04.01.2018 17:49Потому что у него драйверов нет для других сетевых карт.
icCE
04.01.2018 21:50Драйвера в другой ОС или ThreadX в Minix 3 который уже на ARC.
YuriM1983
04.01.2018 23:47Спор ради спора.
Народ пробовал, не работает. Ни AMT/ME, ни уязвимость.
Официальный ответ интела такой же:
communities.intel.com/thread/114211icCE
05.01.2018 01:09а теперь набираем полной грудью воздух и скажите мне, в каком месте используются драйвера в intel AMT, когда на ПК нет ОС и я ее удаленно устанавливаю?
Tyrauriel
06.01.2018 16:12В UEFI. Скорее всего там не будет драйвера на стороннюю сетевую карту.
Но Intel ME это не толькоценный мех, это еще и драйвер в операционной системе, которой является доверенным для любого антивируса.
Чистая спекуляция.
Что мешает получить нужные данные аппаратно, передать их драйверу intel me, тот вызовет драйвер сторонней сетевой карты и передаст по сети.
grozaman
04.01.2018 13:23На большинстве, что обновляют. Возможность отключать добавили с последним обновлением AGESA.
kharkevich
04.01.2018 16:24Судя по всему (http://blog.programster.org/stabilizing-ubuntu-16-04-on-ryzen) отключать нужно и многое другое
Hardcoin
03.01.2018 17:33С точки зрения потребителя 10 лет поддерживал AMD (правда речь про видеокарты, а не процветания) и не имел возможности пользоваться всеми достижениями библиотек машинного обучения. Не знаю, что у меня было в голове, но сейчас-то явно видно, насколько плохое это было решение.
сам пользуюсь Intel
Об этом и речь. Хорошо, когда кто-то поддерживает конкурента, что б выбор оставался. Но самому-то разумно выбирать лучшее.
evocatus
03.01.2018 17:54То, что делает NVidia — это типичный захват рынка, который приведёт к монокультуре и монополии, а это плохо. Intel имела такое же положение на рынке процессоров — и вот результат.
Areso
03.01.2018 18:37+1Интересный ник. Глядя на него, мне вспомнилось…
как мы с товарищем купили одновременно видеокарты в 2011 году. Он — AMD, я — nVidia. Он пошел майнить (благо у него совершенно случайно торчали провода от подъездного освещения в квартире), а я пошел ставить Linux и первые Linux игры, потому что майнинг на 560 Ti уже тогда смысла не имел (в отличие от AMD, что он купил за те же деньги). Сегодня у него квартира, машина и дача под Киевом, а у меня — как часы работающий Linux на nVidia и 230 Linux-совместимых игр в библиотеке.Barma2012
03.01.2018 21:14+1Сегодня у него квартира, машина и дача под Киевом
Это всё он намайнил за 6 лет на одной видеокарте?tangro
03.01.2018 21:54+1В 2011 году на обычной видюхе можно было майнить 1 биткоин в день. В теории, если кто-то этим тогда занялся основательно и не повёлся на несколько волн паники в разные времена — то да, можно было и намайнить на одной видюхе.
Dmitry_Dor
04.01.2018 02:23+1В 2011 году за цену 560 Ti можно было купить четверть тысячи биткойнов, и если не повестись на несколько волн паники в разные времена, то безо всякого майнинга (и вообще без видюхи) сейчас можно было бы купить квартиру (в Лондоне), (автопарк) машин, и дачу (на Лазурном берегу).
Tsimur_S
04.01.2018 13:01Можно, но это несравнимые вещи. То что вы описываете — это целенаправленная инвестиция и мало кто на такое отважился в 2011. А купить карту которая в любом случае нужна и майнить по ночам биткоины это другое. Потом достаточно было забыть о кошельке с десятком биткоином лет на 6 и однажды найти приятным бонусом $100 000.
Areso
04.01.2018 06:15Ну, разве вы не в курсе, как это делалось? Покупалась видеокарта, отбивалась ее стоимость, продавалась. Покупалась предтоповая. Потом еще 1. Потом еще 1. Потом выходило новое поколение, они менялись. Потом у него был ASIC, вложения в который он также отбил. И все это на фоне условно-бесплатного электричества.
Понятно, что и у меня сегодня стоит не та же видеокарта, что и 6,5 лет назад.
Я просто к чему эту историю привел — вот, у нвидии есть PhysX, CUDA-вычисления и ML, а у AMD Radeon было и есть преимущество в фарме различных монеток.
asoukhoruchko
03.01.2018 23:36Вы понимаете, что оценка «лучше/хуже» вообще не применима без уточняющих вопросов? К примеру, под ваши цели видеокарты nVidia действительно подходили гораздо лучше.
А то, что получилось у вашего приятели подпадает под выражение «знал бы прикуп — жил бы в Сочи». И никакого отношения к качествам железа не имеет, если быть объективным.
equand
04.01.2018 02:33Чушь какая-то, еще в 2013 можно было майнить на 9600 радеоне по 0.3 битка в месяц, в 2011 без проблем можно было майнить даже соло хоть на кофейной машинке. Биткоин только зарелизился в паблик.
maaGames
04.01.2018 07:39Допустим, вы бы тоже купили AMD. У вас в квартире были провода, чтобы ВОРОВАТЬ электричество? Как-то часто разговоры о гигантских заработках на майнинге сводятся к «бесплатной» розетке, а по сути к воровству электроэнергии и/или оплате этой электроэнергии всеми жильцами дома. С тем же успехом можно гоп-стопить в подъезде, у каждого проходящего требуя по 100 рублей в день.)
Areso
04.01.2018 07:48+1Понимаете, это лишь влияет на окупаемость. Т.е. капитальные затраты (железо), операционные затраты на майнинг (электричество), операционный доход (продажа монеток). С ценой электричества, отличной от нуля, срок окупаемости растет, но с учетом невысоких цен на электричество (в сравнении с Германией/США, где тоже майнили монетки), это все равно было выгодно.
Ну и мой товарищ потом в качестве компенсации проспонсировал
работы по благоустройству, подарив приличную сумму денег их УК.
P.S.: сравнивать воровство, которое имело место быть в примере, и грабеж/разбой, ну даже не знаю...maaGames
04.01.2018 07:52Лишь? Хотя, в те года сложность майнига была ниже, это сейчас на большинстве карт майнинг будет в минус…
Если товарищ «компенсировал», то хотя бы не такой он падла, как выглядело из первого комментария. Хорошо, что вы уточнили, что он не совсем «сволочь со сволочной начинкой, облитый сволочизмом»(с). С другой стороны, мог бы просто из своей розетки питаться. Но это всякие глупости про облико морале.
alexs0ff
04.01.2018 08:22качестве компенсации проспонсировал
работы по благоустройству, подарив приличную сумму денег их УК.
А чем он тогда отличается от типичного депутата? Сначала обваровывает всех (используя привилегерованные условия) — наживается на этом. А потом в качестве «доброй воли» делает спортивную площадку детям.Areso
04.01.2018 08:25Тем, что вернул больше, чем украл.
alexs0ff
04.01.2018 08:57Не пойдет. Ключевое слово «украл». Если бы заработал честно и потом еще сделал добрые дела — тогда честь и хвала. А так я говорю — типичный чиновник с привелегиями.
А вот если бы с майнингом не вышло — вернул бы? что-то я сииильно сомневаюсь.Areso
04.01.2018 08:59Кому-то совесть позволяет красть, кому-то нет. Тем более, в массовом сознание нынче красть не зазорно — зазорно попасться. Мораль, честность, считается большинством ненужными пережитками, откровенно мешающими жить.
DrPass
04.01.2018 11:10Как-то часто разговоры о гигантских заработках на майнинге сводятся к «бесплатной» розетке, а по сути к воровству электроэнергии и/или оплате этой электроэнергии всеми жильцами дома
А это неправда. Я не буду брать в расчет Европу, но например в Украине я ради интереса прошлой весной дома запустил майнинг эфирок на достаточно бывалой Radeon 7950. Чистый доход был порядка $8/месяц. С одной, достаточно прожорливой видеокарты. И это просто на эфирках по курсу примерно $50. Сколько там они стоят сейчас, $950? Вот если бы я их тогда не продал, я бы уже заработал с месяца майнинга $150. По-моему, вполне окупаемое занятие, не правда ли?maaGames
04.01.2018 11:50Эммм, нет. Потому что тогда — не сейчас. Ведь сейчас не по 150 долларов майнится чистыми, а те же условные 8, из-за выросшего курса. Опять же, прост окупив эфир по 50 тогда и продав сейчас по 950… Но это уже совсем оффтоп.)
Areso
04.01.2018 12:46Понимаете в чем разница. Купив за деньги железку, вы получаете через пару месяцев (деньги И/ИЛИ коины) и железку на выходе.
А купив за деньги коины, вы получаете на выходе коины. Без железок, без денег.
Вероятно, потом, когда-нибудь, их можно будет продать с неким наваром, а вероятно и нет.
Поэтому люди массово уже тогда майнили, а покупать массово коины не покупали.
DrPass
05.01.2018 07:15Эммм, нет. Потому что тогда — не сейчас. Ведь сейчас не по 150 долларов майнится чистыми, а те же условные 8, из-за выросшего курса.
Если нужно подобрать формально определение процессу, то да, наверное вы правы. Если же мы говорим о «выгодности майнинга», то суть в том, что вы потратили десять долларов за электроэнергию, а на выходе через полгода получили $150. И неважно, что значительная часть этой суммы отбита за счет роста курса криптоденюжки. Вы-то ничего для этого не делали, просто майните и ждете. Тем более что вообще нет смысла рассматривать доход от майнинга в отрыве от курсового дохода, учитывая нестабильность курсов криптовалют, и что этот самый курс десять раз изменится, пока вы майните 0,1 эфирку. Это два тесно связанных процесса в одном и том же бизнесе.
Barnaby
04.01.2018 13:45Radeon 7950. Чистый доход был порядка $8/месяц.
Сейчас она почти $50 майнит. Карты все еще актуальны, хотя на них еще лайт с догами майнили.
В РФ электричество тоже дешевое и цены на него растут медленно. Например с тех пор как рубль подешевел в 2 раза у меня тариф на 40% подняли — в реальности стало еще дешевле.
saboteur_kiev
04.01.2018 16:35Как бы весь этот тред вернуть в русло статьи?
Ну например — можно же потерять доступ к своему биткоин кошельку, случайно зайдя с майнинговой машины на левый сайт?
zhukoffdenis
04.01.2018 18:27Кто победил-то?
Areso
04.01.2018 18:38Знаете, это история с открытой концовкой, и оба случившихся варианта имеют свои плюсы и минусы. Настоящая жизнь — не черно-белый мир. Каждый может решить для себя.
Если бы я мог отыграть назад и знать, что и как будет, я бы сделал как выше уже предложили — купить 250 битков и положить их в дальний угол. "Знал бы прикуп, в Сочи жил".
Как было бы правильно: купить AMD Radeon, а на намайненное (пусть и дольше, у меня "случайно" провода от подъездного освещения в квартиру не заходили) купить для nVidia 560 Ti, и осталось бы немного битков. В запас. Хоть экономика моя была бы и хуже, чем у товарища — наличие операционных затрат, трата на стороннее железо вместо реинвестирования. Зато совесть была бы чиста и в библиотеке у меня также бы водились Linux игры, а в карманах бренчали бы [s]биткоины[/s] кэш.
Moog_Prodigy
05.01.2018 17:58Я подозреваю, что даже в случае не воровства э\э оно бы окупилось. Так что про провода это лишние подробности. А так да, предыдущие ораторы все сказали верно, в том числе и про «прикуп в сочи».
vconst
03.01.2018 19:01Такие перспективы интересуют только большие корпорации, обычному пользователю надо лучше и быстрее прямо сейчас, а не через 20 лет.
Dessloch
04.01.2018 04:35Почему же от бедности? Это называется экономика) Я стал «фанатом» AMD после того как Intel облапошила с Hyper-threading, это стало своего рода принципом. И вот оно, вознаграждение за принципиальность)
tbl
04.01.2018 04:45Где можно узнать про то, что не так с hyperthreading? Помимо сегодняшнего, я из интеловских крупных хардварных багов я только про FDIV и Netburst знаю.
m_a_p_a_c
04.01.2018 18:27Подробно было тут:
«Replay: неизвестные особенности функционирования ядра Netburst»a5b
04.01.2018 19:02https://fcenter.ru/online/hardarticles/processors/12033-Replay_neizvestnye_osobennosti_funkcionirovaniya_yadra_Netburst "Replay: неизвестные особенности функционирования ядра Netburst" 25.02.2005
Почему, несмотря на более высокую тактовую частоту и широко разрекламированные маркетинговым отделом Intel архитектурные особенности Net Burst (такие, как Trace Cache, Rapid Execution Engine, Quad-Pumped Bus, Hardware prefetch и даже Hyper-Treading), призванные увеличить число команд, исполняемых за такт, процессоры Pentium 4 умудряются часто проигрывать своим менее частотным собратьям и конкурентам в лице семейств Pentium M и AMD Athlon?
С тех пор HypedThreading переделали...
shurix83
04.01.2018 20:57Ну, Dessloch вспоминает практически единственный случай, когда АМД со своими процами с открытыми кристалами обскакали Интел с их Пентиумом 4. Современную ситуацию с Ryzen не рассматриваю — как по мне, так еще рано анализировать, кто в этом раунде победил.
Areso
05.01.2018 05:35Если смотреть на Steam HW Survey, то связка Intel+nVidia. У Intel/AMD было 80/20, стало 91/9, с графикой еще более эпично. AMD с 24% скатился до 9%.
Dessloch
05.01.2018 13:27+1Сравнивая производительность Intel-AMD не стоит забывать про стоимость. Опросил несколько своих коллег-на работе все фанаты Intel, но дома у всех AMD. Вот так.
Vorber
03.01.2018 17:54Зря или не зря, но вот жрать последствия (судя по тексту новости) будут все пользователи, которые не собирают ядра вручную. Может конечно позже появится патч который будет работать избирательней, но тут именно, что «может».
Arekusei
04.01.2018 18:27Патч уже имеется. В рассылке и новостях различных ресурсах упоминается так же.
unwrecker
03.01.2018 22:49При всей любви к AMD нельзя забывать об аналогичном факапе с первым Феномом: там хоть ошибка была связана не с безопасностью, а с арифметикой, но исправление через микрокод тоже существенно снижало производительность.
Lennonenko
04.01.2018 20:01это исправление заключалось в банальном отключении TLB, в котором была ошибка
быстренько выкатили вторую ревизию, но первая успела разойтись, например, у меня на одной из машин стоит этот феном, и он даже с выключенным TLB изрядно нестабилен
icCE
04.01.2018 04:20Скорее всего AMD подвержена одной из двух уязвимостей.
ARM уже честно отчитался — developer.arm.com/support/security-update
Intel написала извините откровенную хуйню — newsroom.intel.com/news/intel-responds-to-security-research-findings
Осталось еще вспомнить, что внутри intel есть еще arc процессоры под управлением ThreadX или minix 3, с которыми в общем мало, что понятно. Но там видимо своя дискотека.VlK
04.01.2018 12:20На сайте с описанием уязвимости (https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html) указаны 3 варианта атаки, опирающихся на две уязвимости.
Насколько понимаю, Интел подвержен всем, и еще ничего не исправлено, АМД же подвержен одной, самой слабой, и это пофиксили еще в осенних обновлениях прошивок.icCE
06.01.2018 16:07>АМД же подвержен одной, самой слабой, и это пофиксили еще в осенних обновлениях прошивок.
Spectre довольна серьезная ошибка. Мы еще с ней щей хлебнем. (из которых найдено две )
По поводу первой или ее действительно нет или не смогли подобрать алгоритмы для кеша.
alexkuzko
03.01.2018 13:50Эпично. Вот теперь вопрос почти религиозный: можно ли гарантировать то, что патч НЕ будет установлен? Т.к. многие будут готовы пожертвовать гипотетической безопасностью ради существенного прироста (точнее, сохранения того что было) скорости.
mad_celt
03.01.2018 13:54Отключается в конфиге ядра.
alexkuzko
03.01.2018 13:56Я именно про осознанное отключение, инициированное пользователем. В маках или винде, насколько легко будет отключить? С линуксом-то понятно, хотя вопрос остается: будет ли эта настройка явно выведена где-то в дистрибутивах (в интерфейсе гнома, кде и т.п. синнамонов)?
leggiermente
03.01.2018 17:03Представил апплет с единственным Switch button «Security/Performance». А ещё лучше — отдельный тумблер на клавиатуре.
PapaPadlo
03.01.2018 17:08Заголовок спойлера
Serge3leo
05.01.2018 02:17В данном случае, не вопрос. Если я правильно понял методы атаки, сделать, как два пальца об асфальт. Аплет включает и выключает «Time Stamp Disable (bit 2 of CR4)» ;)
pda0
03.01.2018 17:52KPTI can partially be disabled with the «nopti» kernel boot option.
en.wikipedia.org/wiki/Kernel_page-table_isolation
fedison
03.01.2018 17:55В тех же играх 30% сильно скажется, поэтому очень даже интересно, предусмотрят ли отключение в винде
kekekeks
03.01.2018 22:4330% там на syscall-heavy сценариях. Игры же в основном упираются в GPU, сисколов там не сильно много.
DistortNeo
03.01.2018 22:57То есть обычный процесс взаимодействует с видеокартой, минуя ядро?
a5b
03.01.2018 23:56Для вызовов отрисовки — да — http://dri.sourceforge.net/doc/dri_control_flow.html, см стрелки в обход kernel: Direct rendering program (3D):
Direct rendering (3D data) -> 3D data -> Graphics Hardware
https://en.wikipedia.org/wiki/Direct_Rendering_Manager / https://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure
Alcpp
03.01.2018 23:36Учитывая, что это позволяет стороннему процессу чтение паролей и прочей секьюрной инфы в памяти, то думаю отключить будет невозможно. По крайней мере в пользовательских ОС.
sumanai
03.01.2018 13:57А куда они денутся? В десятке не так то просто от чего-то отказаться. Да и ядро люнукса не каждый скомпиляет.
KivApple
03.01.2018 16:29Вроде как ядро Linux перекомпилировать не придётся. Хватит отредактировать конфиг загрузчика, чтобы передать нужную опцию в качестве параметров ядра.
evocatus
03.01.2018 17:39Можно будет выключить через реестр Windows
twitter.com/aionescu/status/930496352781340672
runalsh
03.01.2018 13:58Судя по коду на гите, изоляцию можно отключать.
+ pti= [X86_64]
+ Control user/kernel address space isolation:
+ on — enable
+ off — disable
+ auto — default setting
famiak
03.01.2018 14:03Вопрос не праздный: падение производительности на моем стареньком Core2Quad мне совсем не нужно, а мифическая уязвимость в области виртуальных машин и прочего тревожит не сильно.
sHaggY_caT
03.01.2018 14:21Виртуальные машины тут ни при чём скорее всего. Возможно, будут и javascript эсплойты, через браузер.
iShatokhin
04.01.2018 21:47Как я понял, уже есть.
sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca
Victor_koly
03.01.2018 15:08Инфа секретная — почти любому Core 2 Quad уже больше 10 лет. Уточню — я предполагаю, что все Yorkfield существенно не отличались этим от QX9650 и не могли ещё содержать такого бага.
Про совет ниже — если термин «виртуальная машина Java» относится к указанным проблемам, то снесите Java со своей Винды:)EnigMan
03.01.2018 16:01+1Мне кажется, народ неверно понимает причины упоминания виртуализации. Как я понял, зловред сможет получить доступ к памяти ядра процессора. И не важно, есть у вас виртуальные машины на компе или нет. Для владельцев ферм виртуальных машин опасность в том, что они не контролируют, что там запускают пользователи на арендованных мощностях, а те могут получив доступ к памяти ядра получить данные (повлиять?) других виртуальных машин или хост-системы.
Victor_koly
03.01.2018 21:11Да, с такой фигней согласен. Хотя не читал конкретного описания бага в контексте виртуализации.
Действительно ли именно из виртуалки есть возможность получить доступ к памяти ядра хоста? Конечно, если скажем виртуалка сможет передать какой-то код через драйвер сетевой карты, а Вы разрешили этой виртуалке как минимум доступ к каким-то папкам на запись. В теории возможная функция для тех же хостингов или никто так не делает (максимум — создаст такой доступ через какую-то другую виртуалку, правда не знаю, какую сетевую инфраструктуру можно создать в таком случае в виртуальной среде)?
DrPass
03.01.2018 15:26Т.к. многие будут готовы пожертвовать гипотетической безопасностью ради существенного прироста
Понимаете, сейчас про суть уязвимости все причастные молчат. Но когда патчи пойдут в массы, с ней ознакомятся все желающие и заинтересованные. И безопасность будет уже далеко не гипотетической, благо, непропатченных машин для распространения зловредов будет предостаточно.Alexey2005
03.01.2018 18:09Тогда почему бы не попросить всех причастных молчать и дальше? Неужели нельзя обойтись без публикации подробностей? Ведь если уязвимость настолько неочевидна, что её 10 лет не могли найти, то без публикации кода потенциальные злоумышленники ещё лет 7 провозятся как минимум. Зачем упрощать им задачу?
creker
03.01.2018 18:15Как по мне, подробности уязвимости помогут исследователям. Каждая подобная хитрая уязвимость это идея другим исследователям, где им стоит искать, и о чем они могли даже не думать раньше. Прочитает человек, решит поискать в процессорах других архитектур, а там окажется что-то похожее.
mikelavr
03.01.2018 18:45+1en.wikipedia.org/wiki/Security_through_obscurity
Это мнимая безопасность. Информация тем и отличается, что ее дублирование происходит незаметно для оригинала.
worldmind
03.01.2018 18:55Нашли одни, найдут и другие, тем более держать в секрете сложно, там небось целая орда анализом причин занималась.
А как только будут патчи, то уже ничего скрывать — по коду разберутся.
Mixaill
03.01.2018 17:55для Linux можно просто передать ядру параметр nopti, с другими ОС пока ничего не ясно.
В целом, всё не так страшно. В играх, например, просадки может не быть вовсе
www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests
Soul_in_Gun
03.01.2018 20:09тест не самый лучший ибо используется свежайший Coffee Lake, для которого есть смягчающий импакт фактор. Вот если бы там было что-то типа i7-2600k, который явно проиграет сильнее всего…
AbnormalHead
03.01.2018 20:54<sarcasm_on>
i7-2600k, который явно проиграет сильнее всего…
Можно уже включать режим теории заговора, и утверждать что производитель подталкивает к замене процессора?
<sarcasm_off>Soul_in_Gun
03.01.2018 22:07Да нет, почему-же. Процессор до сих пор держится на уровне i5-7400 в «попугаях» многоядерной производительности и вполне справляется с «офисными» задачами и почти вытягивает современные игры в паре с какой-нибудь 1070 (при этом правда подбираясь к 100% загрузке почти вплотную в супертяжёлых релизах) — просто интересно насколько более старые, но актуальные mid-highend процессоры из второго-третьего поколения получат урона относительно более свежих — в таком случае возможно и ставить патчи смысла нет, а проще будет сразу менять платформу на свежее, благо что так или иначе эти процессоры уже подходят к границе «пора менять»
sumanai
03.01.2018 21:58По крайней мере в i5-3570 поддерживает PCID.
faultedChip
04.01.2018 18:29i5-4570 не поддерживает, а он вышел позже.
sumanai
04.01.2018 18:33Странно. Я смотрел в АIDA64.
faultedChip
05.01.2018 00:18Сейчас проверил в AIDA64 — всё равно пишет что не поддерживается. Видимо какие-то особенности линеек Intel'а.
Darknet
05.01.2018 00:51HWiNFO64 показывает поддержку PCID в i5-4570S, скрипт от Майкрософта подтверждает:
Windows OS support for PCID optimization is enabled: True
faultedChip
05.01.2018 03:43Могу скриншот привести. Я проверял и самописным скриптом через CPUID(EAX=1) и AIDA64 — в обоих случаях результат один (у меня процессор просто i5-4570, без S)
faultedChip
05.01.2018 04:00Извиняюсь за недостоверную информацию: гипервизор меняет значения CPUID, отключая в том числе PCID — при выключенном Hyper-V результаты совпали с вашими.
LaFleur
03.01.2018 14:01мало информации.
про какие процессоры речь? все core i? пни? селероны? каких поколений/годов выпуска?
какие ОС? та же XP уже ведь того…
можно ли будет отказаться от патча? ведь если есть старенький, например, селерон, который работает почти на пределе, то такой патч забрав себе эти гипотетические 30% производительности может совсем привести к необходимости срочного апгрейда машиныsumanai
03.01.2018 14:58та же XP уже ведь того…
Авось опять выпустят фикс, на крайняк от встраиваемых систем подойдёт.
deimos_lt
03.01.2018 17:55Простите, но разве работа на пределе не является индикацией для срочного апгрейда машины?
maaGames
04.01.2018 07:58Работа ПОЧТИ на пределе — индикация сбалансированной системы. А вот если компьютер простаивает, то была переплата за ненужные мощности. Но это если формально к вопросу подходить. А по факту, я тоже предпочитаю недогружать, чтобы кулерами не шелестели.
Victor_koly
04.01.2018 11:32Есть люди, которые верят, что для процессора является нормой работа на Tjunction как минимум 8700 часов в год.
fedorov97
04.01.2018 18:29Думаю, не является, если пользователю хватает скорости/возможностей, поэтому сейчас срочный апгрейд не нужен.
Exchan-ge
03.01.2018 17:59может совсем привести к необходимости срочного апгрейда машины
Вы нашли самую суть и скрытый смысл данной проблемы )vconst
03.01.2018 19:03Это заговор…
Exchan-ge
04.01.2018 18:33-1Это заговор…
Да ну, какой там «заговор».
В 1995 году еженедельник «Компьютерное обозрение» перепечатал откуда-то опрос представителей десятка крупнейших компьютерных фирм того времени на тему «Каким вы видите процессор 2005 года?» (не дословно)
Я, по тогдашней своей привычке, вырезал эту статью и сохранил ее в тематической папке.
Как раз в 2005 году, в связи с предстоящим ремонтом — я случайно наткнулся на эту, давно забытую папку, и снова прочитал этот прогноз.
Из тех компьютерных фирм к 2005 году осталось меньше половины. Прогнозы всех специалистов прошли мимо цели — кроме одного, сделанного представителем Интел.
Он, в 1995 году — точно описал параметры Р4 Prescott — тактовую частоту, количество транзисторов на чипе, размер кэша и применяемый техпроцесс.
(В случайные совпадения я не верю )
dimm_ddr
04.01.2018 19:07В интеле все-таки работают крутые профессионалы и не так уж невероятно что спец смог предположить на основе уже созданных процов, в том числе тех, что не успели выйти на рынок, а это скорее всего лет на 5 вперед линейка, параметры еще на тот момент не созданного. Круто, но не то чтобы нереально. А вот если бы он тогда уже существовал, пусть и в виде тестового образца, то спецу никто бы не дал его параметры описать.
Exchan-ge
05.01.2018 16:36что спец смог предположить
Я сам инженер, до известных событий 90х занимался разработкой и внедрением не менее интересных и сложных изделий, чем процессоры.
10 лет — это как раз тот срок, на который планируется разработка и внедрение чего-то реально нового в производство. При этом обычно уже известно, что это будет и как именно будет работать.
Упомянутая статья — всего лишь одно из подтверждений того, что этот процесс «на Западе» происходит точно также, как это было у нас (есть еще масса интересных косвенных сведений в издававшемся тогда журнале «В мире науки»).
Процессор с кодовым именем Willamette впервые появился в официальных планах компании Intel в октябре 1998 года, хотя его разработка и началась вскоре после завершения работ над процессором Pentium Pro, вышедшим в конце 1995 года, а название «Willamette» упоминалось в анонсах 1996 года… Предполагалось, что Willamette выйдет во второй половине 1998 года, однако, в результате многочисленных задержек анонс был перенесён на конец 2000 года. В феврале 2000 года на форуме разработчиков Intel (IDF Spring 2000) был продемонстрирован компьютер, основой которого служил инженерный образец процессора Willamette, получившего наименование «Pentium 4» (с) Вики
dimm_ddr
06.01.2018 13:50Я сам инженер, до известных событий 90х занимался разработкой и внедрением не менее интересных и сложных изделий, чем процессоры.
Вы занимались не процессорами, следовательно я не вижу причин почему ваш случай можно продолжить на процессоры. "Не менее сложные и интересные" — весьма слабая характеристика. И даже так ваш комментарий никак не противоречит возможности для крутого спеца реально предсказать направление разработки на 10 лет вперед.
Exchan-ge
06.01.2018 17:37Вы занимались не процессорами, следовательно я не вижу причин почему ваш случай можно продолжить на процессоры
Потому что процесс разработки и внедрения в производство зависит только от степени сложности выпускаемого изделия, а не от его конструкции и назначения. Этапы разработки будут одинаковыми.
Даже избыточное финансирование и широкое применение ВТ не дает существенного ускорения, так как в реале все зависит от человека (коллектива), а его возможности ограничены.
возможности для крутого спеца реально предсказать направление разработки на 10 лет вперед.
Вы читали вторую цитату в предыдущем сообщении?
Там все написано прямым текстом — никакого «предсказывания» не было, человек поделился реальными планами Интел (в 1995 это еще случалось )
wych-elm
06.01.2018 17:45Относительно процессоров, вы упускаете один важный момент — стоимость разработки и начала выпуска катастрофически превышает затраты на фактическое производство. Чтобы просто окупится, не говоря уже о прибыли, необходимо продать товар в огромных количествах, а это занимает значительное время. В ином случае новые процессоры бы каждые полгода появлялись, если не чаще.
Alex_ME
03.01.2018 14:09Немного оффтоп.
Раньше не задумывался, но как вообще возможен доступ одного процесса в область памяти другого (или ядра) при наличии виртуальной памяти и независимых адресных пространств? Это касается не только этой уязвимости, но даже, к примеру, дебаггеров и того же ArtMany?yurisv3
03.01.2018 14:42Что значит «независимых»? Физическая память одна. Мэпинг адресов и права прописаны в дескрипторах MMU, никто не мешает (в кольце 0) создать для разных процессов дескрипторы, адресующие одну и ту же (или с перекрытием) область.
Victor_koly
03.01.2018 15:20Попробуйте хакнуть ArtMoney процесс своего антивируса (хотя бы окна GUI).
VBKesha
03.01.2018 15:45Ну по поводу например AtMoney есть винлвые функции:
msdn.microsoft.com/ru-ru/library/windows/desktop/ms680553(v=vs.85).aspx
msdn.microsoft.com/ru-ru/library/windows/desktop/ms681674(v=vs.85).aspx
Специально для этого сделаные.
mikhaelkh
03.01.2018 14:22Через 50 лет:
Из-за уязвимости в чипах Intel, вживляемых в мозг, можно получить доступ к мыслям человека.SanekPlus
03.01.2018 22:14Из-за закрытия уязвимости в чипах Intel, вживляемых в мозг, мы снизили вам производительность работы мозга на 30%. Не волнуйтесь, вы всегда можете взять ипотеку на новый чип.
Captain_Sparrow
03.01.2018 14:23Смотрю я тут описание обновлений биоса на свою материнку… Да это же история факапов интела. Опустим локальные баги и их исправления. И так:
1. Ошибка «Prime95».
2. Глючный Hyper-threading.
3. Пробоина Intel ME.
Бонус из будущего, не войдущий в обновление BIOS'а:
4. Вот это вот всё это вот это из сабжа.
Когда я был молод и студентом, был глуп, беден и велся на маркетинговый буллщит, и поэтому купил себе ноутбук на АМД/Радеон. Отхватив горячих выхлопов из радиатора зарекся больше иметь дел с АМД.
И в связи с этим у меня к Интелу вопрос: какого мать его ты делаешь, Интел???..
Благо, когда собирал десктоп, райзены были ещё только в фантазиях инженеров.
Konachan700
03.01.2018 14:30Не факт, что у красных нет уязвимостей. Просто они намного менее популярны, вот и не ищут дыры в их процах так интенсивно.
Современные процы настолько сложные, что баги в них просто невозможно отловить полностью, ни вручную, ни автоматикой. То ли еще будет. Еще хорошо, что баг нашли, судя по сокрытию инфы, white hat-ы, а не хакер Вася Пупкин — иначе продали бы сей баг с аукциона в торе и никто бы так и не узнал о дыре.
BlackMokona
03.01.2018 16:15Вполне возможно, что уже 100 Васей продали, перед тем как её нашли добрые ребята
leggiermente
03.01.2018 17:24Современные процы настолько сложные, что баги в них просто невозможно отловить полностью, ни вручную, ни автоматикой. То ли еще будет.
Очень верно замечено. Когда в процессоре сотни миллионов логических элементов, вероятность наличия одной или нескольких уязвимостей в нём очень близка к единице. Обнаружение критических уязвимостей в существующих процессорах — лишь вопрос времени и удачи (в теорверовском смысле).
DEmon_CDXLIV
03.01.2018 17:55Возможно что условный хакер Вася продавал эту уязвимость месяц-другой до обнаружения.
Myxach
03.01.2018 17:55Не факт, что у красных нет уязвимостей. Просто они намного менее популярны, вот и не ищут дыры в их процах так интенсивно.
то-есть ситуация как с линуксом и вирусами?sHaggY_caT
04.01.2018 20:17+1то-есть ситуация как с линуксом и вирусами?
Нет, это проблема дизайна Windows. Android популярнее, чем Windows, но массовые эпидемии про Windows а не Android.
Поясню свою мысль: во всех операционных системах способы делать что-то удобно безопасные, а в Windows нет.
Что делает стадартный Windows-пользователь? Гуглит «кряк $програмнейм», «драйвер $девайснейм». Что делает разработчик очередного говноприложения, быстро наклёпанного в Windows? Хранит всё, включая динамически меняющиеся данные, в %programfiles%\$program_name, в результате говноприложение, если юзеру повезёт, для своей работы требует прав на запись в свою папку, а если не повезёт, то и админских прав.
Теоретически, в Windows есть все или почти все технологии безопасности. Есть даже мандатный контроль, вот только в Ubuntu большинство юзеров не отключает apparmor, многие не отключают в Федоре и других дистрибутивах SELinux, а в Windows почти никто не знает о существовании местного MAC, а многие отключают даже примитивный UAC (который со времён висты почти не стал лучше), работают под админом, итд. В Linux логиниться в десктоп энвайромент рутом просто неудобно.
Я думаю, что Windows 10 с её технологиями была правильным ходом. Со временем, все Windows приложения перекочуют в Windows store вместе с популяризацией плиток, когда-нибудь допилят DAC/UAC и сделают популярным MAC, начнут паковать приложения в докер-контейнеры, которые под Windows уже есть. Тогда в Windows и прекратятся эпидемии. Всего лишь нужно не просто сделать технологии безопасности, их нужно сделать такими же удобными, как в других ОС.willyd
04.01.2018 20:32+1многие не отключают в Федоре и других дистрибутивах SELinux
Справедливости ради в Федоре, если не прилетели правила, то приложение будет в unconfined запускаться. Ну и теперь еще firefox в песочнице не запустить.
А вообще, все правильно…
Hellsy22
04.01.2018 22:13-3Что делает пользователь линуксов, когда обнаруживает, что stable-версия приложения отстала лет на 5? Переходит на ~, после чего ему приходится перевести на ~ пару библиотек, а затем и пол-системы, потому как зависимости. Оттуда остается лишь один шаг до ** и установки напрямую.
говноприложение, если юзеру повезёт, для своей работы требует прав на запись в свою папку
Это уже почти стандарт — запись в свою инсталляционную директорию. А вот линуксовые приложения пишут куда попало, лишь бы хватало прав.
многие отключают даже примитивный UAC
Многие сидят под root-ом, что это доказывает-то?
Linux логиниться в десктоп энвайромент рутом просто неудобно
Не замечал каких-либо сложностей.
Добавим сверху альтернативные репозитории, немодерируемые помойки типа сборника плазмоидов, отсутствие хоть какой бы то ни было ответственности и получим полную картину.sumanai
04.01.2018 22:22Это уже почти стандарт — запись в свою инсталляционную директорию.
Это требуется только при установке. Нормальным приложениям при работе права на запись в Program Files не нужны.
Многие сидят под root-ом
Кто например? Думаю, единицы.Hellsy22
05.01.2018 02:50Кто например? Думаю, единицы
— Во второй Мировой погибло 20 миллионов советских граждан
— Кто например? Думаю, единицы.
В каком формате вы представляете ответ на свой вопрос? Я с завидной регулярностью вижу, как люди или сидят под рутом, или у них sudo не требует пароля.sumanai
05.01.2018 03:38Не верю, честно. Если сидо, не требующее пароля, объясняется тем, что при запуске несколько раз подряд в течении небольшого промежутка времени пароль требуется только в первый раз, то работа из-под рута на десктопном ПК необъяснима в принципе ничем.
Hellsy22
05.01.2018 10:09На Raspbian sudo без пароля прямо по умолчанию. В других дистрибутивах отключение запроса пароля для sudo — одна строчка, даже проще чем выключить UAC.
Работа под рутом — тоже не проблема.
И объясняется это точно так же как и отключение UAC — нежеланием сталкиваться с какими бы то ни было подтверждениями.
Я вот не вполне понимаю, почему одни и те же люди зачастую упорно доказывают, что UAC с его диалоговым окном, кстати, показывающим подписано приложение или нет — это ужас-ужас-ужас, а точно такое же окно sudo — «никому не мешает». И уж совсем я не понимаю, почему система, в которой все завязано на одну сущность с абсолютными правами (root) считается более безопасной, чем система, где права разделены между разными сущностями (System, TrustedInstaller, Administrator и т.д.)
А уж тот печальный факт, что в части дистрибутивов нет даже ArmorApp и любое приложение может читать данные других приложений без уведомлений и подтверждений…sHaggY_caT
06.01.2018 18:34На Raspbian sudo без пароля прямо по умолчанию.
Там по-умолчанию логинятся в KDE/Gnome/XFCE под рутом? При чём тут консоль?
В других дистрибутивах отключение запроса пароля для sudo — одна строчка, даже проще чем выключить UAC.
Это сделано для серверов, для того, что бы можно было запускать автоматически без ввода пароля какой-либо скрипт, причём чаще даже не под рутом, а под специфическим юзером. На десктопе типичный юзер просто поленится это отключать, а для серверов права можно выдать именно на отдельный скрипт.
Если специально постараться, можно, конечно, и систему сломать с помощью rm -rf /*
Но ведь это специально нужно что-то делать! А В Windows опасные и десктруктивные юзерские и разработческие паттерны приняты по-умолчанию.
Я вот не вполне понимаю, почему одни и те же люди зачастую упорно доказывают, что UAC с его диалоговым окном, кстати, показывающим подписано приложение или нет — это ужас-ужас-ужас, а точно такое же окно sudo — «никому не мешает». И уж совсем я не понимаю, почему система, в которой все завязано на одну сущность с абсолютными правами (root) считается более безопасной, чем система, где права разделены между разными сущностями (System, TrustedInstaller, Administrator и т.д.)
во-первых, не один юзер, а множество. Считается довольно дурным тоном запускать демоны под рутом: обычно демоны работают под своими собственными юзерами, а во-вторых, мандатный контроль, который большинство юзеров Убунты не отключает(Apprmor прекрасно работает), а на моём PC и ноутбуке включён и SELinux, а в Windows MAC фактически нет: его сделали для какой-нибудь сертификации, и не то что бы его хоть кто-то включал, никто и никогда не писал профилей для приложений для Windows MAC. Его просто не существует.sumanai
06.01.2018 19:08А В Windows опасные и десктруктивные юзерские и разработческие паттерны приняты по-умолчанию.
Это не так. Все рекомендации по написанию программ, начиная минимум с висты, предписывают вполне безопасные практики написания программ, а механизмы перенаправления позволяют работать старым программам (и кривым новым) без администраторских прав.
и не то что бы его хоть кто-то включал, никто и никогда не писал профилей для приложений для Windows MAC
Опять неверно. Даже если отбросить права доступа, то Mandatory Integrity Control настроен для многих системных процессов и файлов, и по умолчанию настроен для всех процессов в средний уровень.
willyd
04.01.2018 22:26Вам изложили анти-паттерны, а вы доказываете, что их использование — это нормально?
sHaggY_caT
04.01.2018 23:14Что делает пользователь линуксов, когда обнаруживает, что stable-версия приложения отстала лет на 5? Переходит на ~, после чего ему приходится перевести на ~ пару библиотек, а затем и пол-системы, потому как зависимости. Оттуда остается лишь один шаг до ** и установки напрямую.
Я? Я стараюсь вовремя обновляться… Но если вдруг? На сервере, не десктопе, и там RHEL6? Я просто собиру пакет со свежей версией :)
Это уже почти стандарт — запись в свою инсталляционную директорию.
Именно. И взлом очень сильно упрощается, если приложение может отредактировать собственные, в том числе бинарные, части. И части ещё кучи приложений, куда может писать тот же пользователь. Это ужасно.
Так что это очень правильно, что бинарники в Linux лежат в /usr/bin, библиотеки в /usr/lib, настройки, независимые от пользователей в /etc, а зависимые в ~/.$APP_NAME или в ~/.local
В Windows есть Documents and settings, но говноприложения его игнорируют. Линуксовые говноприложения могут падать, глючить, не работать без длительного применения напильника, но их файлы раскиданы по ОС секьюрным способом, если приложение включено в репозиторий.
Типичный дизайн Windows-приложений тем ещё ужасен, что каждое приложение тащит с собой кучу либ, разработчиком которых является вовсе не разработчик приложения. Эти либы, часто совершенно дырявые, лежат в папке самого приложения, и на их обновление все забивают.
Никсовая система божественна, как системные пакеты, так и pip, rvm, итд инсталляторы. Когда-то были распространены проблемы депенси хэлл, но теперь это всё в прошлом, а библиотеки, которые шарятся между приложениями, экономят шаренный RAM и дорогое место на SSD дисках помимо секьюрити.
Многие сидят под root-ом, что это доказывает-то?
В KDE или Gnome? Вы много знаете таких мазохистов? Ведь всё будет глючить, падать, отваливаться или работать странным образом :(
Добавим сверху альтернативные репозитории,
Да ладно, мало кто их подключает! Даже гентушники оверлей или арчеводы AUR. А кто подключает, знает, что делает :)
Если мне нужно что-то, чего нет в официальных репах федоры и трёх самых популярных репозиториях от коммьюнити, возьму спек src.rpm из «левого» репозитория и официальный тарболл, и соберу пакетик несколькими несложными командами.willyd
04.01.2018 23:31В KDE или Gnome? Вы много знаете таких мазохистов? Ведь всё будет глючить, падать, отваливаться или работать странным образом :(
RHEL и Centos еще и сопротивляться будут. Да и большинство дестоп-дистрибутивов сейчас даже не спрашивают пароль для рута при установке.
Если мне нужно что-то, чего нет в официальных репах федоры и трёх самых популярных репозиториях от коммьюнити, возьму спек src.rpm из «левого» репозитория и официальный тарболл, и соберу пакетик несколькими несложными командами.
На самом деле я еще не столкнулся с проблемой, что мне чего-то не хватает в fedora и rpmfusion. В генту приходилось один или два оверлея подключать, но с ней долго жить невозможно, в конечном итоге тебе надоедает повышать энтропию вселенной сборкой какого-нибудь хромиума и ты съезжаешь на что-то более удобное. Хотя по скорости с ней никто не сравнится.
А по работе без проблем пересобираю пакеты, когда нужно было отключить зависимости или добавить поддержку библиотеки, которой нет в стандартном пакете.
Hellsy22
05.01.2018 03:08бинарники в Linux лежат в /usr/bin, библиотеки в /usr/lib
А так же в /usr/sbin, /opt/somedirname, а кое-что валяется и в ~/somedirname
Кроме того, чего вы ограничиваетесь бинарниками? Почти в любом дистрибутиве линукса есть питон и перл, с помощью которых можно сделать ээ… все. А уж shell-скрипты валяются вообще всюду, включая /etc
А где лежат, скажем, плазмоиды или плагины для разнообразного софта?
Да ладно, мало кто их подключает!
Увы-увы, в некоторых дистрибутивах СПО головного мозга доходит до того, что в базовых репозиториях нет проприетарного софта типа Chrome (а иногда и Chromium), Java или Flash Player — сейчас это уже не так страшно, а вот пару лет назад…
Если мне нужно что-то, чего нет в официальных репах федоры и трёх самых популярных репозиториях
Пользователи Windows аналогично берут софт на популярных репозиториях. Или с сайта разработчика, что вообще мало чем отличается от выкачивания готовой сборки с git-а.
Когда-то были распространены проблемы депенси хэлл, но теперь это всё в прошлом
Гентушники смотрят на вас со скепсисом. Достаточно не обновляться пару месяцев, чтобы выяснить, что мейнтейнерам захотелось сделать очередную перестановочку и разгребать конфликты придется вручную. А это чудо, когда ебилд требует новой версии Перла, но при перестановке Перла слетают все базовые библиотеки и потому билд падает из-за отсутствия в системе какого-нибудь Locale::gettext. Разумеется, Gentoo — не для слабых духом, но все же не надо кривить душой говоря, что все проблемы в прошлом. А уж если и железо хоть немного нестандартное, то… что ни версия ядра — то какой-нибудь праздник. То mtp2sas отвалится, то ath9k просто перестанет работать потому что… потому что! То кернел-паник из-за l2tp.willyd
05.01.2018 03:38Увы-увы, в некоторых дистрибутивах СПО головного мозга доходит до того, что в базовых репозиториях нет проприетарного софта типа Chrome (а иногда и Chromium), Java или Flash Player — сейчас это уже не так страшно, а вот пару лет назад…
Если нет в оффициальной репе, будет в комьюнити, которая заслуживает доверия, как софтина, так и библиотеки нужные библиотеки. Сейчас даже быстрее чем для win все найдется.
Гентушники смотрят на вас со скепсисом. Достаточно не обновляться пару месяцев, чтобы выяснить, что мейнтейнерам захотелось сделать очередную перестановочку и разгребать конфликты придется вручную.
За год общения была проблема только раз. Именно с Перлом, но из-за рассинхрона репозиториев, в течении суток решилась.
Разумеется, Gentoo — не для слабых духом, но все же не надо кривить душой говоря, что все проблемы в прошлом. А уж если и железо хоть немного нестандартное, то… что ни версия ядра — то какой-нибудь праздник. То mtp2sas отвалится, то ath9k просто перестанет работать потому что… потому что! То кернел-паник из-за l2tp.
Не уверен, что я делал не так. Все работало отлично, ничего не слетало, до сих пор считаю Генту самым быстрым десктопом. Вот только сборка хромиума и еще пары пакетов, которая занимала несколько часов, — это меня пересилило. Ушел на Федору.
зы а вообще начинается линукс-срачHellsy22
05.01.2018 10:37+1будет в комьюнити, которая заслуживает доверия
Чем это в итоге-то отличается от установки софта в винде из «заслуживающих доверия» крупных репозиториев софта или от известных компаний?
Все работало отлично, ничего не слетало
У меня за последние 15 лет ни разу винда не слетала и, в целом, «все работало». У ребенка последние пять лет тоже была винда и линукс и тоже все как-то работало (потому что нет административных прав и не будет).
Но что в винде, что в линуксе, достаточно сделать лишь шаг в сторону от стандартных запросов и проблемы начинают сыпаться как из рога изобилия.
Например, уже упомянутая выше проблема с mtp2sas — я вот такой странный человек, что у меня на домашнем компьтере аппаратный RAID5. Ну там, знаете, надежность, производительность и вот это все. И для меня было сюрпризом, когда после очередного обновления init.d внезапно localmount стал запускаться до появления рейда в /dev. Решение было чудовищным — добавил sleep 15 и все заработало. А через пару месяцев так же тихо баг исправили.
Или вот актуальная проблема — есть китайская беспроводная мышка. Под иксами (любыми) она двигается с задержкой в полсекунды. Под виндой — работает нормально. Почему? Я не нашел решения.
Чтобы меня не обвиняли в однобокости припомню проблемы W10 и CH341 — популярнейшим китайским UART-чипом: первый год после выхода W10 драйвер для CH341 просто не работал и единственная рекомендация на форумах была «используйте W7». А как-то я захотел сделать нормальный мост на W10 Pro, с DHCP и роутингом. Промучавшись три дня, перелопатив тонны документации и перепробовав в том числе кучу стороннего софта я махнул рукой и за десять минут сделал то же самое на линуксовой машине. С другой стороны, я помню как мучился с L2TP (accel-ppp) — он насмерть вешал линуксовую машину время от времени…
В общем, я это к тому, что пока вам нужен от системы в основном браузер и видеопроигрыватель, то выбор OS в целом не принципиален — линукс тоже без особых усилий справляется с подобными задачами. Но когда дело доходит до специфических задач, то вылезают тысячи нюансов и проблем. Везде. И универсальных решений нет.willyd
05.01.2018 12:21Чем это в итоге-то отличается от установки софта в винде из «заслуживающих доверия» крупных репозиториев софта или от известных компаний?
Зависит от этих самых неизвестных производителей софта. Если они нормальные, то у них в винде инсталляция будет нормально происходить, в репе, типа rpmfusion, есть хоть какой-то контроль сообщества, и велика вероятность отбраковки корявого приложения. Но shit happens, ничего не поделаешь…
Но что в винде, что в линуксе, достаточно сделать лишь шаг в сторону от стандартных запросов и проблемы начинают сыпаться как из рога изобилия.
В силу перечисленных sHaggY_caT причин, в винде сделать этот шаг проще. Если следуете минимальным правилам, не утанавливать подозрительный софт, не работать под рутом и т.д., везде будет хорошо.
И для меня было сюрпризом, когда после очередного обновления init.d внезапно localmount стал запускаться до появления рейда в /dev. Решение было чудовищным — добавил sleep 15 и все заработало.
chkconfig не пробовали прописать с нужными приоритетами на start/stop? Ну или depend() если был OpenRC.
В общем, я это к тому, что пока вам нужен от системы в основном браузер и видеопроигрыватель, то выбор OS в целом не принципиален — линукс тоже без особых усилий справляется с подобными задачами. Но когда дело доходит до специфических задач, то вылезают тысячи нюансов и проблем.
И универсальных решений нет.
Все хорошо везде, пока не нужно строить костыли. И это, в принципе, относится к обоим. Я не могу быть категоричным в этом вопросе. Меня полностью устраивает Linux для работы, у меня нет никаких проблем ни в играх(кроме отсутствия нормально видео карты) ни с проигрыванием media. Windows, еще отлична для enterprise и замены пока особо не видно, хотя я знаком с компанией, которая имеет пару тысяч продуктовых магазинов и использует SUSE, к сожалению уже не помню какую версию версию точно, открытую или enterprise.Hellsy22
05.01.2018 12:44Гхм, я все же возражу насчет игр, поскольку игры и продукты Adobe для меня являются основной причиной использовать Windows.
Все-таки Wine кое-как работает с DX9, но не с DX11/12/Vulkan. Портированные же на Linux игры зачастую работают хуже, чем под Вайном да и не так уж их и много. У меня большие надежды на gpu passthrough в будущем, но конкретно на моей конфигурации железа он не работает.willyd
05.01.2018 13:31+1Мое желание поиграть могут полностью удовлетворить тайтлы из раздела Linux в steam'е. Но думаю, что если, будет нормальная видеокарта, то я смогу для развлечения поднять win в kvm и прокинуть туда карту.
Для работы мне удобнее использовать линукс, и пока это главный повод.
AbnormalHead
03.01.2018 21:21Вводишь в любом поисковике ключевую фразу «XXXXX errata», где XXXXX — название любого процессора (включая всякие микроконтроллеры).
И узнаешь много интересного про устройство XXXXX.
dark_snow
03.01.2018 14:24Вот не зря я фанат красных, как нутром с детства чувствовал… Правда сейчас сижу на кор кваде (ПК собран из халявного железа) но на 7ку и хр можно не ждать патчей думаю, так что с производительностью все нормально будет =)))
sHaggY_caT
03.01.2018 14:36так что с производительностью все нормально будет =)))
Думаете, майнеры, ддосеры, и спам-рассыльщики, которые пропишутся через уязвимость на уровне ядра, будут оставлять Вам больше производительности, чем патч на уровне ОС?PavelZhigulin
04.01.2018 06:51Принцип неуловимого Джо ему поможет :)
sHaggY_caT
04.01.2018 18:46-1Вряд ли. Не зря ведь есть поговорка «С дряной овцы хоть шерсти клок», и миллионы когда-то уязвимых ПК, теперь включённых в ботнеты.
Tyrauriel
03.01.2018 14:51А как обстоят дела в BSD системах? Нужен ли им аналогичный патч?
Konachan700
03.01.2018 15:16+1Судя по слухам (а другой инфы нет пока), уязвимость аппаратная и затрагивает все ОС. Где-то в проце при определенных условиях не проверяется какой-то бит из состава блока защиты памяти.
Поговаривают, что даже ARM64 зацепило — а это значит, что баг вполне может быть в лицензируемом третьей строной блоке логики, используемым многими вендорами.Tyrauriel
03.01.2018 15:45Сложилось впечатление что BSD уже работали в том режиме, на который сейчас котят пропатчить Linux и Windows. Или я все-таки перепутал операционки? Ведь точно уже есть такая для которой патч не требуется.
udivankin
03.01.2018 15:57В некоторых источниках пишут что баг архитектурный — в упреждающем выполнении кода без каких-либо проверок
wych-elm
03.01.2018 19:33Стойте, вы про т.н. спекулятивное выполнение, когда выполняются обе ветви if, параллельно, а потом отбрасывается ненужная? И если такая проверка — это if процес_имеет_доступ_к_памяти { читать_из_памяти } else { поднять_исключение }, то мы сможем прочитать из любой памяти (тут важный нюанс, очевидно, интеловские процы спекулятивно прочитанные таким образом данные не стирают и мы можем получить к ним доступ). Кстати, записать в память таким образом не получится, потому что запись в память вызывает сброс конвейера и спекулятивное выполнение не происходит (что соответствует этой дыре — память ядра можно только читать).
kekekeks
03.01.2018 22:50Там спекулятивный выполнятор запрашивает кусок доступной юзерспейсу памяти в L1-кэш в зависимости от результата выполнения инструкции, породившей исключение доступа. А наличие памяти в L1-кэше легко проверяется по задержкам доступа. Такие дела.
Kghrast
04.01.2018 18:30Точные детали уязвимости неизвестны, но на основе обсуждения патча «Do not enable PTI on AMD processors» (https://lkml.org/lkml/2017/12/27/2) предполагают, что речь именно о спекулятивном выполнении. Оно явно упоминается в обсуждении того, что процессоры AMD не подвержены уязвимости.
nun-buoy
06.01.2018 03:48Позапускал код, приведенный в конце spectreattack.com/spectre.pdf. На начальном этапе код заставляет процессор загрузить в кэш один из 256 кусков памяти, в зависимости от значения байта. Затем проверяется время доступа ко всем 256 кускам, и номер куска, который считывается быстрее остальных, и является искомым значением.
ARD8S
03.01.2018 18:22Теоретически, подобные уязвимости могут быть и в «спец. процессорах, которые ну уж совсем точно без закладок» (нувыпонели) или, например, в асиках?
xcore78
04.01.2018 20:32На мой взгляд, предсказание ветвлений ASICам не очень требуется. Еще на ASIC сложно выполнять произвольный код.
equand
04.01.2018 03:39BSD не подвержена, насколько видно в релизах патчей
equand
04.01.2018 03:45Ан нет, врали патчи
lists.freebsd.org/pipermail/freebsd-security/2018-January/009651.html
Barlog
03.01.2018 14:57Может быть эта ошибка даст повод руководству intel хотя бы задуматься о возвращении к двухгодичному релиз циклу.
asm0dey
04.01.2018 13:23Во времена когда все, даже Java, переходят на суть ли не полугодичный? Intel уже замедлились в том плане, что от схемы tic-tac перешли на tic-tac-tac.
Barlog
04.01.2018 13:25Ты путаешь твёрдое с мягким. ;)
asm0dey
04.01.2018 13:29Формально релизный цикл уменьшился в два раза, фактически увеличился в полтора. Ведь внутри одного поколения они почти ничего не меняют.
Barlog
04.01.2018 13:30Вот это «почти ничего не меняют» и является основным источником ошибок.
asm0dey
04.01.2018 13:33Последние громкие ошибки существовали годами вроде, нет? Что вот эта дыра (особенно spectre, которой подвержен даже AMD), что дыра в IME. как ни странно, но возникли они как раз не во время оптимизации (которая происходит на tack), а во время создания новой архитектуры (tick).
Barlog
04.01.2018 13:36Но их не нашли, потому что «зачем всё проверять, мы же совсем чуть-чуть поменяли, если что в следующем процессоре исправим, через год же всего выходит»
asm0dey
04.01.2018 13:45Их не нашли потому что это невозможно сделать целенаправленно. Так же как ты не можешь найти все баги в софте (начиная с какого-то уровня сложности) даже если целиком его писал сам — всё предусмотреть невозможно. А процессоры, так же как и софт, делаются не одним человеком, а большими командами. Я думаю, что в Intel серьёзно относятся к безопасности и надёжности (на этом месте можно спросить у @shipilev, он там рядом варился) и гонка за скоростью ради качества, думаю, достаточно ограничена.
Barlog
04.01.2018 14:04Всё можно проверить на 100% и отладить до конца. Вопрос времени. Но возвращаюсь к моему первому ответу: софт можно легко исправить, поэтому на тестировании экономят, железо — нет, но почему-то на тестировании тоже экономят.
willyd
04.01.2018 14:11Всё можно проверить на 100% и отладить до конца.
Не все и не всегда, и тем более в очень сложных системах.
Всегда найдется человек более умный или изобретательный и придумает тест-кейс, который еще не внедрили, что и сделали исследователи нашедшие данную уязвимость.
lpwaterhouse
04.01.2018 15:14«Целое больше, чем сумма его частей»
Вы можете отладить часть системы, каждую отдельную часть системы, систему целиком, систему с некоторой внешней средой, но в итоге проверить абсолютно все вы не сможете. И даже если сможете, всегда будут незадокументированные и неочевидные взаимодействия. Это бессмысленно. Баги есть, будут всегда и их не искоренить. Можно лишь оставить те, вероятность обнаружения которых довольно низка.
asm0dey
04.01.2018 16:55Железо обычно правится исправлениями микрокода (и интел регулярно выпускает обновления). А вот тут вот такое вот что не повезло. Гипотетически ты прав — проверить можно вообще всё. Надо просто прогнать все возможные комбинации параметров и комбинации комбинаций. То есть запустить весь возможный софт в случае процессоров. Но это настолько долго и дорого, что легче называть это «невозможно».
dimm_ddr
04.01.2018 19:11Это не просто слишком дорого. Если взять все возможные комбинации входных параметров и проверить что нигде ничего не ломается (что само по себе не просто и неизвестно возможно ли, но пусть будет возможно), то я сильно подозреваю что с текущими вычислительными мощностями тепловая смерть вселенной наступит раньше. Так что это реально невозможно практически.
asm0dey
04.01.2018 19:52Вам не кажется что вы другими словами повторили то, что написал я? :)
Всего возможного софта пока что не написано, так что на настоящий момент такая проверка невозможна.
Однако то что сказал я показывает фальсифицируемость гипотезы о том, что можно проверить что-то на предмет 100%-надёжности, что в общем-то делает эту гипотезу как минимум наукообразной :)
arthi7471
03.01.2018 15:12Мда… Десять! Десять маза фака лет нас могли поиметь по железу и скорее всего имели и вдруг, совершенно неожиданно, заметили что что-то не так.
SNPopov
03.01.2018 15:30Все как по анекдоту. Приговоренного к смерти после длительной отсрочки выводят на казнь. Тут он спрашивает — А какой сегодня день недели?.. Ему отвечают — Понедельник. Он — Ничего себе неделька начинается…
gearbox
04.01.2018 14:13там по тексту — все происходит в туманно-дождливый понедельник, и один из конвоиров ему отвечает — тебе то что, а вот нам еще назад возвращаться.
Alter2
03.01.2018 15:16+2К счастью, последние модели процессоров Intel с технологией PCID (идентификаторы контекста процесса), возможно, позволяют уменьшить падение производительности
Устав бороться за прирост производительности новых процессоров, решили понизить производительность старых?
Или кто-то вскрыл аппаратный бэкдор специально заложенный производителем а-ля Intel Management Engine? Кстати, то что уязвимы модели процессоров за последние 10 лет, неплохо коррелирует с внедрением IME.
erazel
03.01.2018 15:27ИМХО есть еще один вариант — так Интел хочет увеличить отрыв будущих процессоров(которые только разрабатываются) от текущих поколений. Что бы стимулировать переходить на новые модели. Не секрет что вот уже лет 7 мы имеем очень малый прирост быстродействия у Интел. Поэтому покупатели не торопятся обновляться.
Хотя это больше касается десктопного сегмента, а тут под угрозой больше серверные системы.KivApple
03.01.2018 16:40Уязвимость то реальная (после публикации всей информации её сможет проверить любой желающий) и появилась не меньше чем лет 10 назад. Едва ли кто-то будет планировать такую многоходовочку «заложим уязвимость сейчас, а потом через 10 лет сольём её, чтобы выпустить процессоры без неё и поднять продажи»:
Во-первых, уязвимость могут найти раньше времени. Во-вторых, до выхода новых процессоров велик риск, что покупатели уйдут к конкурентам, у которых этой уязвимости нет. В ближайшее время от этой новости может выиграть только AMD.
San_tit
03.01.2018 18:26Скорее могло быть так: щас сделаю вот такой вот костыль, пока работает, а потом можно будет доделать.
AlexanderS
03.01.2018 15:31Прошло только 3 дня нового, 2018 года и… какие замечательные новости!
Причём самое печальное не то, что косяк нашли. Косяков не делает тот, кто ничего не делает вообще. Печально то, что наверняка об этом косяке кое-кому было хорошо известно какое-то время, но, по вполне понятным причинам, особо это никто не стремился исправлять.
Мало технодробностей. Как нашли, как именно эксплуатируется, какое железо затронуто?
Может это всё этот… заговор? ) Интел решил массово всех подтолкнуть к будущим апгрейдам железа в котором этих косяков нетно есть другие.a5b
04.01.2018 00:03Первая публикация "по мотивам" была Jun 24, 2017 https://gruss.cc/files/kaiser.pdf, патчи Linux уже несколько месяцев пишут — https://lkml.org/lkml/2017/12/4/709 https://lkml.org/lkml/2017/12/4/709 [patch 00/60] x86/kpti: Kernel Page Table Isolation (was KAISER)
на базе пакета патчей, готового к 1 ноября 2017 https://github.com/IAIK/KAISER "Kernel Address Isolation to have Side-channels Efficiently Removed"
Latest commit 6112890 Nov 1, 2017 @dgrussAlexanderS
04.01.2018 11:12Ну, я-то домашний хомячок + работа вообще-то не по тематике IT, поэтому руку на пульсе не держу, поэтому «неожиданно» узнаю о проблемах вот из таких новостей.
Спасибо за ссылки.
Neuromantix
03.01.2018 15:32[paranoic mode on] Может, это под впечатлением от Black mirror s4ep05, но почему мне кажется, что подобный подход — обмен надежности на удобства — может плохо кончится? Сколько еще таких дыр в железе и софте, которые напиханы или будут напиханы в ближайшем будущем в боевых роботов, в системы жизнеобеспечения, в коммуналку и в кучу других вещей, на которые опирается нынешняя цивилизация? [paranoic mode off]
neomedved
03.01.2018 16:24Но ведь это наоборот обмен удобства на надёжность.
Neuromantix
03.01.2018 16:56Это костыль, необходимый как раз из-за размена надежности на желание побольше хапнуть и выпускать сырые дырявые продукты. Ведь (к примеру) 1080 — мало, надо 2к, 4к, 8к, 16к и до бесконечности, нужно больше сокетов, обновлений, архитектур, чипов, золота и зиккуратов, а на все прочее — плевать.
Areso
04.01.2018 10:19Но вот ведь интересный момент. 1080 Ti можно воткнуть в G31 материнскую плату и она будет работать (пусть и будучи ограниченной PCI-E v1.1), а вот любой современный процессор в ту материнскую плату не воткнуть.
Так что уж в кого и кидать камни, так не в PCI-E.
SinsI
03.01.2018 15:48«Приятная» новость для линуксоидов —
As it turns out, apparently the Linux patch that is being rolled out is for ALL x86 processors including AMD, and the Linux mainline kernel will treat AMD processors as insecure as well. As a result, AMD CPUs will feel a performance hit as well, though the bug only technically affects Intel CPUs and AMD recommends specifically not to enable the patch for Linux.
— если у вас АМД, вам всё равно впаривают этот патч.Konachan700
03.01.2018 15:53Действие патча отключается параметром ядра. Сделано для того, чтобы не создавать хаос в дистрибутивах и не разводить холивары «надо или не надо». При установке будет тест на типа проца, для амд добавит инсталлятор параметр и всё.
KivApple
03.01.2018 16:43А логичнее было бы при загрузке определять модель процессора (это в любом случае делается, потому что в ядре есть куча других work-around для других багов) и применять опцию (раз её можно менять параметром ядра — значит поведение можно менять без перекомпиляции) только если процессор от Intel. Хардкодить в конфигах параметры, которые легко и быстро определять при загрузке — плохой путь. Процессор может и смениться (если это, например, LiveUSB) между перезагрузками.
Konachan700
03.01.2018 16:55Так в последнем патче так и сделали. Баг критикал, потому первый коммит был направлен на скорейшее его закрытие, главное, чтобы он за собой ничего не ломал — остальное можно допилить потом. Это нормальная практика, иначе критикал патчей придеться ждать месяцами, если все учитывать и тестировать по-полной…
VlK
03.01.2018 16:01Насколько понимаю, ответственные решили так не маньячить и упростить все для АМД:
patchwork.kernel.org/patch/10133447
В сущности, там проверка типа «для всех 86» заменяется на «для всех Интелов».
huhen
03.01.2018 15:53Судя по патчу, добавляется защита на доступ из юзерспейса(ring 3) — видимо TLB кеш позволяет заглянуть куда не следует. Так что баг касается и домашних компьютеров, но судя по тексту статьи позволяет еще и добраться до гипервизора.
Пока нет подробностей можно надеяться на лучшее и эта «фича» не будет работать например при выключенной виртуализации(хотябы «домашние» компы не просядут).vconst
03.01.2018 16:01Выше высказади опасения, что это может касаться любых «песочниц», включая js в браузере. Это и правда так может быть? Я не спец, но выглядит очень опасно…
huhen
03.01.2018 16:09Тут скорее всего потребуется двойная уязвимость:
— исполнение произвольного кода
— и за счет этой уже выбираемся из «песочницы».KivApple
03.01.2018 16:46Иногда JIT может сгенерировать такой код, который корректен с точки зрения поведения в идеальных условиях, но тоже триггерит уязвимость. Так что если повезёт, то явных уязвимостей в движке и не нужно.
vasiliysenin
03.01.2018 16:31Уже давно на хабре была статья про то, как из JavaScript определить где физически размещены данные. Если при выделении памяти, всегда затирать её нулями, то вроде бы такая уязвимость не так и страшна.
Если же аппаратная ошибка в механизме виртуальной памяти, то единственный вариант защиты — это интерпретация машинного кода. В этом случае падение скорости на 30% это минимум.
Если погуглить фразу «KAISER patches», то там говорится о "...KAISER, a kernel isolation technique to close hardware side channels on kernel address information.", то есть рандомизация размещения в памяти.
Замедлять компьютеры на процессорах AMD это конечно интересное решение Линуса Торвальдса.sumanai
03.01.2018 17:21Если при выделении памяти, всегда затирать её нулями, то вроде бы такая уязвимость не так и страшна.
Вообще-то так и делается, по крайней мере в Windows.huhen
03.01.2018 18:43А можно пруф?
Иначе зачем например openssl при освобождении забивает еёнулямирандомными значениями? Как раз чтобы другому процессу ОС случайно не отдала блок с важными данными. Да и в Windows неспроста присутствует функция RtlSecureZeroMemory.Konachan700
03.01.2018 19:12Пруф можно получить, сделав malloc(1) и дальше в цикле инкремент этого указателя (будет читаться невыделенная память) — там будут или нули, или данные нашей программы. Но там не будет ничего чужого. Я это лично когда-то проверял, тоже казалось, что по невалидным указателям должны читаться ошмётки от других программ, примерно как в ардуино лол…
Затирают же для того, чтобы в памяти не висели ключи и прочая секретная информация. Из другого процесса это может и не достать, но вот из ядра вполне себе достается. RtlSecureZeroMemory нужна потому, что компилятор выбрасывает все конструкции типа memset(), если данные после них более не используются.maaGames
04.01.2018 08:08Возможно, зависит от языка программирования, но менеджер памяти ничего сам не затирает, т.к. на это тратится время. Далее говорю только за С/С++.
Проверяли вы, скорее всего, в debug-режиме, а в нём как раз затирается, для удобства отладки. А в релизе ничего не затирается ни при выделении памяти, ни при освобождении. Поэтому, при необходимости, обнуление выполняется вручную, но оптимизирующий компилятор может эти затиранния удалить, если не считает их важными для работы алгоритма. Выше уже написали о функции RtlSecureZeroMemory, которую компилятору не разрешается удалять, как раз для того, чтобы гарантировано обнулить память.sumanai
04.01.2018 13:36Не затирается память, выделяемая внутри приложения. Всё, что отдаёт ОС, затирается. То есть в обычном режиме программа может прочитать только свою память.
maaGames
04.01.2018 13:43В принципе, не важно, в каком виде память получается при выделении. Важно, в каком виде память остаётся после использования. Если после удаления объекта память не была обнулена/заполнена мусором, то достаточно вызова ReadProcessMemory, чтобы прочитать данные, которые в блоке памяти были записаны. Как я понял, из-за ошибки не проверяется, есть ли право чтения памяти по указанному адресу, поэтому можно прочитать любой блок памяти, даже тот, которым пользуется ядро. В нормальной ситуации был бы сегментфолт или другое исключение, но не в этот раз.
CoolCmd
04.01.2018 18:31+1венда обнуляет память, которую ей возвращают проги. (может и при выделении, если специально попросят, например HEAP_ZERO_MEMORY). но когда Си-шная прога вызывает free(), этот кусок памяти не обязательно сразу отдается венде.
размер обнуленных страниц памяти показывает process explorer.
huhen
03.01.2018 19:14Хотя поискал, действительно начиная с Windows Vista(?) выделенные страницы обнулены.
sumanai
03.01.2018 19:38Виста? Так делает любая NT как минимум. Это базовое требование безопасности, заложенное в архитектуру ОС по требованию каких-то там правительственных служб. Инфа из книги «Внутреннее устройство Microsoft Windows» интересующей вас версии, я читал от 2000 до семёрки.
Кстати, память на дисках так же зануляется для пользователей с ограниченной учётной записью, а вот админы могут прочитать и так, как впрочем и память других процессов, кроме защищённых.
Mabu
05.01.2018 03:18Вызываю функцию HeapAlloc без флага HEAP_ZERO_MEMORY, страницы тоже будут обнулены?
sumanai
05.01.2018 03:41Память будет обнулённой при вызове HeapCreate. При выделении памяти в этой куче обнуления не происходит, так как эта память принадлежит процессу, и это его забота, что там есть.
Mabu
05.01.2018 17:58Память будет обнулённой при вызове HeapCreate.
Это при условии, что мы заранее указываем размер создаваемой кучи. А если не указывать, то куча куча может расти, и каждое выделение памяти из неё не будет обнуляться.sumanai
05.01.2018 19:10Вы не правы. При росте кучи сверх текущих размеров новая память для неё будет выделяться стандартными средствами из списка очищенных страниц большими блоками, а уж потом из неё выдадут блок запрошенного размера, и вот тут обнуления не будет. Никаких утечек приватных данных, доступных для обычных приложений, в Windows нет.
Mabu
06.01.2018 04:45Только что проверил. Вызвал функцию HeapAlloc без флага HEAP_ZERO_MEMORY, выделив 154000 байт. Получил не нули, а мусор. Я туда не записывал, только читал. Что это за данные? Эти данные от предыдущих программ? То есть это могут быть логины и пароли?
sumanai
06.01.2018 15:01Это ваши же данные. Структуры самой кучи, мусор от запуска рантайма. Посмотрите на размер экзешника, на него в дизасме. Там кроме вашего кода валяется в 100 раз больше кода от компилятора.
Попробуйте выделить десяток мегабайт, чтобы заставить ОС отдать новые страницы памяти, а не переиспользовать старые.
wadeg
06.01.2018 03:18Система выделяет память пользовательскому процессу вызовом
VirtualAlloc[Ex].
The function also guarantees that when the caller later initially accesses the memory, the contents will be zero. Actual physical pages are not allocated unless/until the virtual addresses are actually accessed
malloc etc — это уже надстройка (система кучи) со своими правилами, которые тоже нужно понимать.
SinsI
03.01.2018 16:55Не может ли эта уязвимость быть связана с IME — ведь ей как раз десяток лет?
Это могло бы объяснить, почему она так долго оставалась незамеченной…
Scratch
03.01.2018 17:33А 29 ноября CEO Intel слил все свои акции.
Совпадение?novice2001
03.01.2018 22:50Во-первых, не все.
Во-вторых, те акции, что он продал, были куплены по опциону ниже рынка.ivan2kh
03.01.2018 23:06вообще-то все что мог, кроме обязательного минимума
novice2001
04.01.2018 00:16Только вот минимум — это столько же, сколько и продал. Так что чувак просто наварился на разнице цен — а из этого делают какие-то выводы.
prianichnikov
04.01.2018 18:31+1Есть предположение, что просто комбинирует с налогами:
I will offer an alternate explanation. He lives in CA. Due to the recently passed federal tax changes, there may be good reasons to realize some gains under 2017 tax regime vs 2018. The limits on write off of state tax against federal will certainly hit him. So taking the action in 2017 he can use the deduction, but not in 2018. He is certainly hitting top tax brackets so 13.3% * 39.6% works out to a >5% take home difference. Not earth shattering, but definitely worth considering pulling some transactions in 2017.
Reddit
MaxKorz
03.01.2018 17:57Патч с решением (kpti) для Linux добавил в ядро лично Линус Торвальдс.
Ну давайте еще больше жути напустим. Линус просто мержит ветки, и если открыть по ссылке log то это прекрасно видно, к патчу он не имеет отношения.
budoraq
03.01.2018 17:57— Как продавать больше новых процессоров?
— Давайте дискредитируем все старые за последние 10 лет!
— Ты чудовище! Какое хочешь повышение?
Kogolbok
03.01.2018 17:57А макось уязвима? В громком названии её не вижу. Это просто потому, что они пока никак не отреагировали, или они-таки не подвержены в силу тех или иных причин?
PlayTime
03.01.2018 18:01Это не идеальное решение проблемы, но грядущие патчи для Windows, Linux и macOS будут использовать именно этот подход.
Kogolbok
03.01.2018 19:12Да, но в названии числятся только две операционки. И название-то, шокирующее и наводящее на определённые размыщления. ТС писал с Мака? :)
lpwaterhouse
03.01.2018 19:26+1Просто уязвимость мака — это несерьезно. Винда — огромный процент в юзер-сегменте, Линукс — серверный, а Мак — игрушка с грошами на фоне остальных цифр.
MuLLtiQ
04.01.2018 14:22macOS пропатчили еще в декабре, насколько я понимаю support.apple.com/en-us/HT208331
SergeyMax
03.01.2018 17:57некоторые подробности всё-таки выплыли наружу благодаря Python Sweetness и The Register
Странно, а по первой ссылке слово «Intel» вообще не упоминается, более того, написано «security bug impacting apparently all contemporary CPU architectures that implement virtual memory». Не трахнули ли несчастного журналиста ещё раз?
xl-tech
03.01.2018 17:57Объясните, пожалуйста, а если я ставлю патч сначала на хостовую машину, потом на виртуальную, я получаю падение производительности до 60%? Или на виртуальные машины оно так влиять не будет?
danzealzer
03.01.2018 18:3030% — это среднее по больнице. На некоторых задачах можно и по-более отхватить, согласно Фороникс. А может и вовсе не увидите разницы, как мне кажется.
nidalee
03.01.2018 20:19Нет, до 30% — это до 30%. В таком случае «среднее по больнице» — это 15%. Среднее между 30 и 0.
Mixaill
03.01.2018 20:50В исходном тексте не совсем корректные данные. В худшем случае падение более чем в два раза lwn.net/Articles/742522
HaltAction
03.01.2018 17:57А тем временеим CEO Intel за месяц до этого продал акций на 11 миллионов
www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
pda0
03.01.2018 18:22Тут другое интересно. Получается, в VPS эту штуку придётся держать включенной на каждой виртуалке? Гостевые OS с nokpi гонять не получится?
asm0dey
04.01.2018 13:39Зачем? Основная проблема-то — уязвимость хоста. Остальное всё-так ближе к проблемам клиента. Дальше всё зависит от ваших отношений с клиентами и обязательств перед ниим. Если их безопасность находится в сфере ваших интересов — тогда да, им тоже надо порекомендовать поставит патч.
pda0
04.01.2018 15:35Эм… Тут все крутые, но я скорее с позиции клиента рассматриваю. :) Раз уязвимость в процессоре, а виртуализация — аппаратная, то патч придётся ставить не только хостеру, но и на гостя. И держать его включенным. Получая, возможно, двойной штраф…
asm0dey
04.01.2018 17:04Тогда да, учитывая что клиентская виртуалка может словить малварь — конечно там тоже должна быть заплатка в большинстве случаев.
shikhalev
04.01.2018 18:32+1Двойного штрафа, насколько я понимаю, не будет — основное замедление из-за инвалидации процессорного кэша, а не из-за инструкций, которые эту инвалидацию делают. Могу ошибаться.
pda0
04.01.2018 21:26Так они кэш инвалидируют? Тогда нам всем ещё повезло, что просадка всего на 30%. Помню, на старых компах была опция в BIOS по отключению кэша. Сразу раз в 20 медленнее работать начинал компьютер.
shikhalev
05.01.2018 19:01Сорри, был не совсем прав, там всё сложнее. Так что двойной штраф возможен. Хотя, мне кажется, не каждому вызову syscall на госте будет соответствовать таковой на хосте, т.о. штраф будет в среднем между единичным и двойным.
Terras
03.01.2018 18:35Интересно, двинет ли это рынок процессоров в объятия AMD?
Alcpp
03.01.2018 23:57Рынок б.у. процев — да.
Новых — не сильно. Увеличение количества новых процев произойдет не скоро (измеряется месяцами), т.к. заказы не так просто разместить. А Интел может уже через пару недель выкатит хардварный апдейт.GalVorbak
04.01.2018 17:42А Интел может уже через пару недель выкатит хардварный апдейт.
Я менее оптимистичен и мне кажется, что уязвимость подобного уровня править будут чуть ли не до следующего поколения. При том ещё есть вероятность задержки выхода этого самого нового поколения. Существующие на рынке продукты изменить не представляется возможным, так как партии на ближайший год либо уже произведены, либо уже отданы на очередь, так что отзыв из производства приведет к дичайшему дефициту процессоров, а также к неустойкам заводу.
Meklon
04.01.2018 20:06Это ж с каким дисконтом продавать надо будет? Все будут ждать чистое поколение.
GalVorbak
04.01.2018 21:44А будет ли дисконт вообще? Они вроде наоборот все сливки снять намерены, ведь зная об уязвимости выходящего на рынок поколения они наоборот сдвинули его запуск на два месяца раньше (знатоки теорий заговоров в треде и вещают ещё и про то что их СЕО ещё в осенью продал свои акции сколько смог, зная что они упадут после массовых публикаций об уязвимостях). В то-же время, простые люди покупать их процессоры будут, потому что большинству до лампочки новости из сферы безопасности, а упираются в потолок производительности они относительно редко.
А с серверным действительно интересно, поможет ли сильный дисконт, учитывая, что даже без выявленной уязвимости EPYC получался, вроде как, довольно хорошими за свою цену.
metric_ghost
04.01.2018 20:56Хардварный апдейт, КМК, потребует полной переработки масок. Я так понимаю, это не степпинг по мелочи поправить, это очень-очень дорого. Голосую за то, что восьмое поколение останется без апдейта, а если маски уже создали для девятого поколения, то не факт, что и оно его получит.
tmnhy
03.01.2018 18:59cher11
03.01.2018 20:17А не могли бы вы объяснить, что именно произошло на скриншоте? Первая команда — компиляция, понятно. Затем запуск бинарника, и?..
VlK
03.01.2018 20:20Он сначала прямиком читает из таблицы символов ядра (собственно, баг).
А потом показывает, что это правильные адреса через обычный интерфейс (директорию /proc/).
huhen
03.01.2018 20:31Как я понял при его участии в феврале была опубликована инфа про обход ASLR через js. Если верить публикации обход сработал на 22 разных процессорах, в атаке насколько я понял использовалось особенности работы кеша процессора и TLB, видимо капнул дальше.
springimport
03.01.2018 21:08Видимо началась новая эпоха замедлений. Эпл и Интел стали первопроходцами. Интересно, какие будут причины придумываться.
Nedder
03.01.2018 21:40А вот интересно, а как насчёт судебных исков из-за падения производительности на 15%-30%?
Фольксваген за несчастный газовый тест на миллиарды засудили, а тут что? Забыть и простить?
sumanai
03.01.2018 22:02Фольксваген за несчастный газовый тест на миллиарды засудили
Вообще-то они нарушили законы, запрещающие продажу новых авто, не соответствующих эко-стандартам. То, что эти стандарты практически невыполнимы, никого не интересует.
В случае же интела никто не регулирует производительность процессоров, придраться можно разве что к рекламе, да и там обычно идёт сравнение с предыдущими версиями продукта, а тут они все будут замедлены одинаково.novice2001
03.01.2018 23:14Стандарты выполнимы. Иначе засудили бы не только VW. И засудили их за мошенничество.
idiv
03.01.2018 23:38Тут сложнее. Есть идея, что это была акция против крупнейшего в мире конкурента. Еще один вариант — слишком уж нагло они это делали и далеко не один год. А так сейчас смотрят в сторону Крайслер-Фиат и Мерседес.
sumanai
04.01.2018 13:44Стандарты выполнимы.
Только получается совсем не то, что хочет потребитель.
Иначе засудили бы не только VW.
Проще было изменить законы и разрешить превышение по выхлопам в два раза.
darthmaul
03.01.2018 22:11Фольксваген за несчастный газовый тест на миллиарды засудили, а тут что? Забыть и простить?
Фольксваген нарушил интересы государства, а Интел — всего лишь интересы простых смертных. Увы, ничего им не будет.
ARD8S
03.01.2018 22:54Репутационные потери никто не отменял. Потери капитализации. Вообще, они всё грамотно делают, если что, всегда есть пункт под "*" о производительности.
Ну продажи могут просесть, цены придётся немного скидывать на старые поколения, если AMD не повысят.
Интел — всего лишь интересы простых смертных
Некоторые большие корпорации (и гос. компании/органы) могли поиметь из-за этого проблем (и не факт, что их не было). Сейчас, как минимум замедление виртуализации, а это некислый такой кусок бизнеса Intel и VPS площадок. Вообще, оправдатели AMD лукавят, протравливая свои «выстрелившие» удачные платформы.
новые серверные чипы EPYC от AMD, а также их десктопные процессоры Ryzen Pro имеют технологию шифрования защищённой памяти, дающую дополнительную защиту от атак подобного рода.
а для других, как я понял всё это доступно, только уже«Архитектура AMD не позволяет получить доступ к данным при отсутствии соответствующих привилегий»
т.е. с соответствующими привилегиями не факт, что невозможно.huhen
04.01.2018 00:27т.е. с соответствующими привилегиями не факт, что невозможно.
А почему поток с соответствующими привилегиями не должен иметь доступа к данным?ARD8S
04.01.2018 01:57Да, это я понимаю. Если человек работает под root/админской учёткой или процесс запускается с повышенными правами, или использует другую уязвимость, повышающую права, то проц AMD не обезопасит от этого. Хотя, если уж всё так, то тогда конкретно эта дырка будет уже не нужна. Т.е., допустим, многие сервера работают под рутом, многие виртуалки так же. И всё. Просто как бы не началась истерия — интел говно, покупайте AMD, они неуязвимы. «И вирусов там нет» (с).
Mightywill
03.01.2018 22:37это не уязвимость, это цру попросило сделать, а инфа утекла или ктото случайно нашел эту дыру
SanekPlus
03.01.2018 22:46инфа 146% ?
DjOnline
04.01.2018 12:19Ну достаточно почитать wikiliks, чтобы понять, что они активно сотрудничают как с производителями (в том числе материнских плат, процессоров, жёстких дисков), так и с хакерами, выкупая 0-day раньше всех.
Так что по сути неважно, по их ли инициативе это появилось или вследствии ошибки, важно то, что они этим как минимум пользовались с ноября, а возможно и годами раньше.
equand
04.01.2018 12:30В АМД такого нет. Так что похоже на то, что ЦРУ ничего не просила, похоже на оптимизацию из разряда предкалькуляции. Видимо весь прогресс Интела на этой баге и висел.
interprise
04.01.2018 12:32«чистая» производительность без сисколов падать не будет, те интел в производительности на ядро все равно быстрей и баг тут не причем.
equand
04.01.2018 12:34Не важно ибо по текущей производительности AMD до патча догнал Intel, после патча получается у Intel еще и сисколлы будут в тормозе.
alexr64
04.01.2018 18:33-1Чистая производительность, без обращений к ядру ОС, в настоящее время является узким местом только в ограниченном круге задач. БОльшая часть упирается в ввод/вывод.
Mightywill
04.01.2018 14:34в АМД нет или еще не нашли? почему вы думаете что дыры должны быть в одном месте? (кривая ухмылка)
к тому же бага в каком наборе инструкций? если это интел-специфик то в амд его и не будет
funnybanana
03.01.2018 22:48Минуточку:
Также сообщается, что патч для Linux будет по умолчанию включать kpti и на компьютерах с процессорами AMD, вызывая соответствующее падение производительности.
Зачем это делать если об уязвимости АМД процессоров ничего не известно?
P.S сижу на AMD a10a5b
04.01.2018 00:35Представитель amd заявил, что их микроархитектура не допускает доступа к более привилегированной памяти из менее привилегированного контекста (в т.ч. спекулятивного) и предложил не включать "kpti" на AMD
https://lkml.org/lkml/2017/12/27/2 Tom Lendacky (amd)
AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault. Disable page table isolation by default on AMD processors by not setting the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI is set. - /* Assume for now that ALL x86 CPUs are insecure */ - setup_force_cpu_bug(X86_BUG_CPU_INSECURE); + if (c->x86_vendor != X86_VENDOR_AMD) + setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
NiTr0_ua
03.01.2018 22:58to funnybanana:
то было первое решение «лишь бы залатать». уже принят новый патч patchwork.kernel.org/patch/10133447
//промахнулся немного веткой…
Neuromantix
03.01.2018 23:55Уже фигурируют страшные цифры -63% twitter.com/grsecurity/status/948170302286172160
robert_ayrapetyan
04.01.2018 00:25Пока что в единственно показанном PoC на скриншоте в твиттере видно чтение, а что с записью? Ведь если запись недоступна, то все не так страшно?
willyd
04.01.2018 00:55Я вот не знаю. В теории нельзя написать такую инструкцию, которая скомпрометирует критические данные с хост-сервера, к примеру?
Да и после такого громкого выстрела только ленивый не будет копать в поисках схожих уязвимостей, причем не только в Intel…
ShashkovS
04.01.2018 00:49Пишут, что postgresql с этим фиксом проваливается на 17-23%. Жесть, конечно.
Пруф: www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3.anarazel.deMuLLtiQ
04.01.2018 01:35Note that real-world scenarios probably will see somewhat smaller
impact, as this was measured over a loopback unix sockets which'll have
smaller overhead itself than proper TCP sockets + actual network.
Все-таки хочется посмотреть насколько все плохо на реальных БД: там очень многое зависит от производительности диска и сети.
ange007
04.01.2018 01:22Только блин купил мать под 8е поколение.
Теперь остаётся ждать хардварной заплатки, либо снижения цен на старшие модели процессоров.interprise
04.01.2018 01:38вы хотя-бы можете ее продать и тут же купить рейзен с небольшими потерями по деньгам. Я купил 6800к, который после выхода райзена подешевел почти в 2 раза и теперь не продать, и производительность на 6том поколении падает сильней и что делать хз.
tbl
04.01.2018 02:27только хотел в следующем месяце на рейзен переехать с FX-8350, не успел (( Ща цены на него взлетят
vsespb
04.01.2018 01:57Google считает что AMD тоже
security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel
tbl
04.01.2018 02:09В AMD branch target injection сработает на linux только если включить BPF JIT, но оно и понятно, что с помощью правил для файрвола и зондирования с локалхоста можно пощупать, что там в kernelspace хранится. Да и кому попало BPF настраивать не дают в ядре (по-хорошему только рут это должен делать).
tbl
04.01.2018 02:01Похоже, что в Intel спохватились и дали ответ в обход снятия эмбарго. Но он какой-то невнятный: «Баг — не баг, а эксплоиты не corrupt, modify or delete data». А то, что из юзерспейса можно почитать kernelspace — это по их мнению не critical.
interprise
04.01.2018 02:03да мелочь то какая, прочитать ssh ключи соседней машины. Правда, где тут критичность
tbl
04.01.2018 02:16из своего юзерспейса в соседний не пролезешь, только в гипервизор, но иногда и этого достаточно
tbl
04.01.2018 02:21ошибся, можно пролезть: с точки зрения бажного cpu — все равно, какие данные использовать для спекулятивного исполнения в предсказателе переходов — память ядра или память соседнего процесса
DistortNeo
04.01.2018 03:07А как текущий процесс попадёт в память соседнего процесса, если в таблице страниц памяти сидит только память текущего процесса и ядра?
ElegantBoomerang
04.01.2018 18:33Может! Например, в Линуксе для удобства в память ядра отображена вся физическая память. А одна из разновидностей уязвимости атакует через данные предсказания веток, чтобы другой процесс при исполнении работает за другое время — а это и замеряется, атака по сайд-каналу же.
MacIn
04.01.2018 20:14в Линуксе для удобства в память ядра отображена вся физическая память
А если ее больше, чем address space за вычетом служебных зон? Скажем, 4 гига на 32 битной платформе?
А если память соседнего процесса выгружена к своп?DistortNeo
04.01.2018 20:48Видимо, это касается только 64-битных систем, где нет никакой проблемы отобразить всю физическую память в логическое адресное пространство.
А если память соседнего процесса выгружена к своп?
Наверное, зависит от того, происходит ли page fault с подгрузкой страницы в память при спекулятивном выполнении команд.
sumanai
04.01.2018 22:08Наверное, зависит от того, происходит ли page fault с подгрузкой страницы в память при спекулятивном выполнении команд.
Вряд ли, это тормоза.
MacIn
04.01.2018 22:52ПМСМ, если нужна подгрузка страницы, то это очень большой оверхед, чтобы можно было использовать такую уязвимость.
ElegantBoomerang
04.01.2018 21:19На 32битных системах мапят, как я знаю, отрезок, сколько влезет. Его постоянно переключать не очень удобно, вот на 64 битах и решили мапать всё.
xcore78
04.01.2018 20:25Этот текст писали юристы с определенной целью. Было бы странно оценивать его с технической точки зрения.
mike_y_k
04.01.2018 02:09Скачал последние исходники ядра.
Буду смотреть на kpti и пытаться отделить истину от потока малосодержательной пока информации.
Может тогда станет понятна суть ошибки.
Возможно Intel найдёт менее торомозящее лекарство от собственных ошибок.
Заодно стоит внимательно посмотреть на ситуацию с macOS, с прошлого года пока не открывал крышку…
tbl
04.01.2018 02:34пошла жара от intel:
https://s21.q4cdn.com/600692695/files/doc_presentations/2018/Side-Channel-Analysis-Security.pdf
Krypt
04.01.2018 03:01twitter.com/brainsmoke/status/948561799875502080
Насколько я понял, кому-то удалось успешно провести атаку на практике. Так что «NOT OBSERVED ACTIVE DEPLOYMENT» — это временно.tbl
04.01.2018 04:30Один из авторов статей Meltdown и Spectre у себя в твиттере обещает на следующей неделе выкладку исходников эксплоитов. Видео там интересное, хотелось бы посмотреть (да и следующий скрин про дамп памяти браузера интересен).
firk
04.01.2018 07:55Уже выложили https://spectreattack.com/spectre.pdf
Как я понял это баг не совсем в конкретной реализации, а в самой идее предсказания ветвлений и предварительной подготовки к выполнению будущих инструкций, считая чтение операцией, не меняющей состояние (а она давно не такая из-за кеща). Если там всё по-честному проверять — предсказание ветвлений будет иметь гораздо меньше смысла. Если нет — получается вот такой read-only доступ куда не следует.
И эти заплатки с изоляцией системной памяти от чего-то защитят, но всё равно могут оставить дыру в эксплуатации особенностей исполнения ядерного кода (в нём то ядерная память доступна и могут непреднамеренно быть конструкции, использующиеся в эксплойте с входными данными от юзера — когда его писали никто про такое не думал, да и даже зная о такой "особенности" сложно это предусмотреть везде).
Но не всё так плохо. Получить доступ на чтение к ядерной памяти тут относительно легко, а вот к памяти соседнего процесса — намного сложнее, если вообще возможно (как описанным в статье способом так и тем вторым, что останется после этих заплаток). А важные данные типа паролей/ключей хранятся как раз обычно в памяти процессов, а не в ядре.firk
04.01.2018 09:05А, упустил деталь
тут https://meltdownattack.com/meltdown.pdf написано
as well as the entire kernel space, which typically also has all physical memory (in-use) mapped
видимо это нововведение 64-битных ядер (т.е. зависит от ОС, и не указано какой ОС, в каких-то этого может и не быть), из-за которого красть данные теперь можно не только из ядра, но и из соседних процессов (которые теперь там тоже выставлены на обозрение) тоже. Хорошо у меня 32-битное ядро хоть и на 64-бит проце.
jcmvbkbc
04.01.2018 10:12На 32-битном ядре почти гигабайт физической памяти замаплен точно так же. И нет, это не нововведение.
firk
04.01.2018 16:37Ну, гигабайт — далеко не вся память. И опять же это может зависеть от ОС. Замапленная память ядра — понятно зачем нужно, чтобы не переключать карту памяти для большинства системных вызовов, и если её убрать — действительно понизится быстродействие. И поэтому скорее всего так будет сделано по умолчанию во всех вменяемых современных ОС (до того, как привлекли внимание к обсуждаемой особености процов). Замапаленная просто рандомная (или вообще вся) физическая память — просто небольшое удобство и на быстродействие почти не влияет.
crea7or
04.01.2018 05:07Azure уже написал и обновляет виртуалки: Dear Azure customer,
An industry-wide, hardware-based security vulnerability was disclosed today. Keeping customers secure is always our top priority and we are taking active steps to ensure that no Azure customer is exposed to these vulnerabilities.
vsespb
04.01.2018 10:51Интересно, можно как-нибудь сделать чтобы root процессы в host машине не тормозились этим патчем. Ибо руту всё равно можно всё и нечего его ограничивать. Тогда хоть будет возможность запустить какие-то тяжёлые задачи под рутом, что лучше чем ничего.
vasimv
04.01.2018 19:33В виртуалках тоже руты живут. Надо еще и проверять, что этот рут — настоящий рут :)
alhimik45
04.01.2018 10:58А что делать владельцам старых линуксовых ядер?) Будут ли бэкпорты в 3.x ветки?
alix_ginger
04.01.2018 11:39Если сделаете — будут!
Areso
04.01.2018 12:54Вы считаете у каждого программиста достаточно квалификации, чтобы сделать бэкпорт патча в старое ядро и успешно его собрать потом?)
alix_ginger
04.01.2018 16:31Не у каждого, а только у тех, кому достаточно квалификации, чтобы принять решение, что старая версия ядра ему подходит лучше.
alhimik45
04.01.2018 18:23То есть если человек сидит на старом ядре из-за того драйвера wifi для его ноутбука под 4ю ветку не собираются, то он сразу получает знания о бэкпортировании патчей в это ядро?
alix_ginger
04.01.2018 18:34Если он заботится о безопасности, то он же как-то устанавливает остальные патчи :)
Hayate
04.01.2018 11:53Версий процессоров без уязвимости нужно будет ждать пару лет?
dfgwer
04.01.2018 12:58-1Бери АМД
vasiliysenin
04.01.2018 18:11+1googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html?m=1
АМД тоже подвержен этой уязвимости ( Spectre )
iDm1
04.01.2018 18:50+1Исходя из заголовка речь идет об уязвимости Meltdown, устранение которой программно как раз и снижает производительность, а ей процессоры AMD не подвержены.
В случае со Spectre, которая касается всех процессоров, то ее снижающий производительность KPTI не устраняет. Над вариантами решения проблемы данной уязвимости работа все еще идёт и не ясно чем все закончится.
NoRegrets
04.01.2018 12:07-2Интелгейт какой-то. Это брак процессоров, имхо, и штеуд должен произвести замену. Хотя их лоеры со словами «это фича, а не баг» будут стоять до конца.
willyd
04.01.2018 13:07По вашей логиге, возможность намеренного повреждения шланга к вакуумному усилителю тормозов авто — это брак, и все машины должны быть отозваны.
Hayate
04.01.2018 13:13Скорее это наличие в машине центрального замка, сигнализации, бронестекла, видеорегистратора и при это форточки для проветривания которая никак не закрывается и находится в мёртвой зоне камеры.
NoRegrets
04.01.2018 13:17Кривая и глупая аналогия.
Устройство используется по назначению, согласно тех. документации. И имеет такую ошибку в дизайне, которая не допускалась в тех. документации и которая снижает функциональность устройства. Это ошибка проектирования, брак. Пользователь получил не то, за что заплатил деньги.willyd
04.01.2018 13:23Без действия третьей стороны все работает и нет никаких проблем. Функциональность не снижается, повреждений данных нет. Вы же работаете с продуктом по тех.документации.
Атака — это действие третьей стороны, которое описать или предугадать невозможно.Neuromantix
04.01.2018 13:43+1Я купил меганавороченную систему безопасности, однако она открывается зубочисткой. Но взлом системы безопасности — это действие третьей стороны. поэтому все нормально. Так что ли?
Это таки брак — как минимум в том месте, где костыль жрет производительность (и не важно, 1% или 50%). Ну и это слишком опасный прецедент, чтобы оставлять корпорации безнаказанными — завтра они выпустят еще какое-нить баганутое поделие, а потом еще и еще — потому что ответственности ноль.willyd
04.01.2018 14:03Еще раз.
Вы не купили систему безопасности. Вы купили вычислительный модуль, который производит для вас вычисления. И в данном случае, проблем с этим нет — никаких, все вычисления он проводит в штатном режиме и его функциональность не нарушена. Обнаружили уязвимость в изоляции памяти ядра, но это проблема решается одной переменной в конфиге ядра линукса, к примеру. Где тут брак? Вы просто расплатитесь производительностью за безопасность своих личных или бизнес данных. И поверьте, на том же azure, aws, gcp крутятся сервисы компаний, для которых падение производительности на 5% исчисляться восьмизначными суммами долларов в год.
Возвращаясь к автомобилям. Вы купили автомобиль, у него есть замок и ключ и какой-никакой иммобилайзер, но вы ставите дополнительную сигнальную систему, на которую нужно потратить деньги и которая добавляет точек отказа системы.Neuromantix
04.01.2018 15:17Я не хочу расплачиваться своей производительностью за чужие баги. Я купил процессор с заявленными характеристиками ( в частности никто не заявлял. что он дырявый) и с заявленным быстродействием. И получил в итоге дыру и падение быстродействия, и мне еще говорят, что все нормально, так и должно быть.
sumanai
04.01.2018 15:23и с заявленным быстродействием.
А это что? Тактовая частота и прочие характеристики процессора ни капли не изменятся. Это ОС будет тормозить. Можете использовать старые ОС, я уверен, XP будет работать так же шустро, как и раньше.
evgenyk
05.01.2018 17:18«Перечитывал пейджер, много думал.»
Процессор не только уязвим, он в своем кэше так же портит данные!
Не в физической памяти конечно, а процесс может получить неверные данные.
2) Не обязательно таймер, можно просто хранить 1 число и сравнивать значения, это сработает для случаев кроме того, когда считываемое значение равно хранимому числу.
NoRegrets
04.01.2018 15:13По тех.документации процесс не может читать память за пределами своих выделенных страниц. А он читает. Это невыполнение функции защищенного режима процессора. Одной из основных его функциональностей.
Все ОСи написаны с учетом предоставляемой защиты, а ее по факту нет. И сейчас они городят кучу костылей, чтобы ее реализовать на софтовом уровне.willyd
04.01.2018 15:57Как вы не поймете, от багов никто не застрахован, и даже при улучшении методологий тестирования, с сегодняшними темпами усложнения систем и перехода на более высокие уровни абстракций при написании программных продуктов, тенденция в раскрытии критических уязвимостей подобно этой будет усиливаться. Это естественный процесс, которому тяжело, что-то противопоставить, всегда найдется более умный, смекалистый, с нестандартным мышлением, который сможет создать условия и окружение для компрометации данных. Это не всегда будет приводить к таким масштабным последствиям, но думаю, что данная уязвимость открыла новую эпоху и нас ждет еще много чего интересного. c'est la vie…
SADKO
04.01.2018 20:25-1Смешно читать такие или около такие рассуждения ибо уязвимость то боянистая, лет шесть уже как модули на её основе имеются в продаже, пора бы и честь знать…
И это не баг, вот уж чего обывателю никак не понять!
Это новый контекст использования :-)
И дело не в умении и смекалистости, дело в постановке задач, которые у каждого свои.willyd
04.01.2018 20:49+1Ну так поделитесь ссылкой на аукцион, а мы посмотрим.
А то как-то выходит, что 6 лет эксплойт в свободной продаже, но при этом никто и не слыхал про него. Это как? Я еще понимаю, если его спецслужбы используют, но тогда о какой свободной продаже может идти речь. А если другая сторона использует, то мы бы наверное чаще читали новости об уведенных кошельках или потерянных через swift суммах.
Мне вот тяжело понять, какая была «постановка задачи», что он всплыл только сейчас…
metric_ghost
04.01.2018 21:00Интелу тоже за шесть лет было никак не понять? Ждали, пока на них ведро навоза выплеснут? А подумаешь, репутация, штрафы, рыночная доля, это же всё просто слова, да?
rogoz
04.01.2018 16:26Если что, Интел отзывала процессоры по гораздо менее важной причине: ru.wikipedia.org/wiki/Ошибка_Pentium_FDIV
saboteur_kiev
04.01.2018 16:40Не отзывала, а предлагала обмен всем желающим, ибо в реальности, эта проблема касалась очень узкого круга пользователей. Сколько конкретно пользователей воспользовались услугой замены — неизвестно. Заявленные потери Интел учитывали в основном маркетинговые проблемы, а не саму замену процессоров.
В данном же случае, проблема касается всех и каждого.
kafeman
04.01.2018 13:13+2Which systems are affected by Meltdown?
Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013).kafeman
04.01.2018 13:15+2Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.
vsespb
04.01.2018 16:49Тут новость что придумывают патч, который не так сильно скажется на производительности www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Retpoline-Patches
Aleks1113
05.01.2018 03:19Да в принципе, пока что логично поставить те патчи, что есть, а потом уже с спокойной душой дождаться новых патчей, которые не будут так сильно бить по производительности — пускай некоторое время посидишь с замедленным компом, зато за сохранность данных банковской карты можно не беспокоиться.
Sap_ru
05.01.2018 13:31+1Это от spectre. А тормозит систему Meltdown. Сейчас их смешали в кучу, но это разные уязвимости, разные патчи и разные последствия.
Spectre не так страшен и от него уже и так есть защита (отключение/эмуляция таймеров, дополнительный уровень гипервизора, шлюзы и т.п.) — вопрос в том, какой путь лучше.
А с Meltdown все плохо — сброс кэша при перезагрузке таблиц страниц).
Кстати, есть мнение, что рекламируемая PCID совсем не панацея. Там тэги не для всех видов данных и все равно частично кэш сбрасывается.
no1D
04.01.2018 17:20MS Выложило вроде как апдейт
www.catalog.update.microsoft.com/Search.aspx?q=KB4056898 Windows 8.1
www.catalog.update.microsoft.com/Search.aspx?q=KB4056897 Windows 7AtaZ
05.01.2018 18:42Установил обновления, уж не знаю оно это или нет, но никаких существенных отличий в работе не заметил.
pdk10
04.01.2018 18:35-1предвижу массовые возвраты в магазины и коллективные иски, я вот не собираюсь копаться с патчами и терпень просадки производительности, компьютеру нет 6 месяцев, пусть intel выпускает официальный пресс релиз на основании которого организуют массовый отзыв процессоров, что делать с материнками под процессоры, которые все уязвимы тоже не понятно
dakiev
04.01.2018 18:35-2А никто не думает что уязвимость была заложена в интересах третьей стороны? Не страдаю теориями заговоров, но вероятность имеется и слишком уж долго уязвимость оставалась ненайденной.
willyd
04.01.2018 19:00+1Если бы делали закладку, она была бы более юзабельной в плане поиска нужных данных.
metric_ghost
04.01.2018 21:04Оставалась ненайденной, пока искать не начали. Да и слишком просто её использовать кому угодно после обнаружения, инфраструктура на процессорах интела не только в странах потенциального противника есть.
Nick_Shl
04.01.2018 18:35+1Где группа подающих в суд? Запишите меня тоже!
Только купил ThinkPad P71 с i7-7700HQ. Глядя тесты в интернете видел производительность возросла за последние 5 лет всего где-то на 16% и рассчитывал, что мой процессор ещё долго будет актуален, а тут баг который одномоментно "состарил" процессор на 5 лет!
Пусть или процессор меняют(как это было с первым Пентиумом), или 30%(ладно, соглашусь и на 15%) от цены ноутбука возвращают!CapricornTV
05.01.2018 18:42Тогда уж процент от цены процессора, интел не отвечает за всю остальную мишуру на вашем ноуте.
Farxial2
05.01.2018 00:34и Intel по понятным причинам предпочитает молчать
Это называется трусость.
под удар, в первую очередь, могут попасть компании, использующие виртуализацию
А их пользователи? И что им делать?
chabapok
05.01.2018 01:08Что-то я не пойму. Уязвимость нельзя закрыть обновлением микрокода — но будет патч, который уменьшит производительность. Надо патчить каждую программу(это из каментов) — но будет выпущено ядро с такой функцией. Это же все — взаимоисключающие утверждения.
Farxial2
05.01.2018 01:17Потому что Intel ссыкуны и думающие о прибыли, а не о людях, эгоисты, ну. (Надеюсь, этот коммент не потрут, ибо оскорбление — поведение Intel.)
Во-первых, всё зависит от микроархитектуры. Если микроархитектура позволяет, то можно обновить микрокод, и в худшем случае пострадает производительность. Т.е. полностью отключаем кэш, например. (Не, ну а что ещё делать? *dunno*)
Во-вторых, если микархитектура не позволяет, то, наверное, надо честно сказать об этом людям, причём сказать, какая микроархитектура проблемная, а какая нет. Для этого может потребоваться раскрыть информацию о микроархитектурах — ибо как ещё людям понять, что их не обманывают? Но они не хотят и, скорее всего (если только не произойдёт чуда), не захотят сделать это из-за конкуренции.
Darknet
05.01.2018 12:04Сначала обновляем антивирус, Windows Update проверяет флаг в реестре перед установкой чтобы не упасть в BSOD. Обновляемый статус антивирусных продуктов.
Затем устанавливаем обновление Windows, через Update или вручную.
Используем скрипт Powershell от Microsoft, убеждаемся что CVE-2017-5754(Meltdown) закрыт.
Обновляем браузеры, на Firefox утром прилетело обновление от Spectre.
Проверяем сайт производителя на наличие обновления BIOS, устанавливаем если оно есть.
Вновь запускаем скрипт от Майкрософта, убеждаемся что CVE-2017-5715 (Spectre) закрыт.
Nvidia написала об обновлениях драйверов для устранения этой уязвимости, пока непонятно, но стоит проверять и их сайт.
После этого можно слегка расслабиться.fpir
05.01.2018 21:46И так на N машинах. Даже с winsus и политиками есть чем заняться, особенно с BIOS/UEFI.
Serge3leo
05.01.2018 02:11Хм. Так и Вы будете смеяться, но ещё в прошлом веке, Intel для по-настоящему защищённых операционных систем, а не всяких там Linux/Windows, реализовала «Time Stamp Disable (bit 2 of CR4)». Вероятно по заказу АНБ. Они что-то ещё тогда знали ;)
Farxial2
05.01.2018 02:24О, TSD это же круто.
Добавлю, что при TSD=1 rdtsc[p] на x86 генерирует #GP(0), а значит можно запилить обработчик прерывания #GP(0), который будет эмулировать rdtsc[p]. И патчить кучу софта не потребуется. Если я прав, то было бы здорово.
Хотя, может, злоумышленники могут использовать не только TSC…Serge3leo
05.01.2018 02:37С тех появилось некоторое количество отладочных регистров и счётчиков производительности, но они тоже все отключаемые. А без них, ни meltdown, ни spectre, ни многое и многое иное, не пройдут ;)
a5b
05.01.2018 17:35Для замера времени без TSC иногда предлагают запустить второй поток, который будет просто постоянно инкрементировать счетчик в общей памяти. Метод от тех же самых Graz UoT… (Можно запретить потоки, запретить запускать свой код, запретить наличие кодогенераторов, см iOs: https://stackoverflow.com/questions/5054732/is-it-prohibited-using-of-jitjust-in-time-compiled-code-in-ios-app-for-appstor "3.3.2 An Application may not download or install executable code...")
https://news.ycombinator.com/item?id=16066871&ref=hvper.com Timer coarsening is a bad idea. Turns out [1], a simple timer thread is a good enough poor man's cycle counter. What are you going to do: ban variables?
https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_lipp.pdf ARMageddon: Cache Attacks on Mobile Devices (Moritz Lipp, Daniel Gruss et al, Graz, August 10–12, 2016) 3.3 Accurate Unprivileged Timing ..
Cache attacks on x86 CPUs employ the unprivileged rdtsc instruction to obtain a sub-nanosecond resolution timestamp. The ARMv7-A architecture does not provide an instruction for this purpose… We broaden the attack surface by exploiting timing sources that are accessible without any privileges or permissions.
Dedicated thread timer. If no interface with sufficient accuracy is available, an attacker can run a thread that increments a global variable in a loop, providing a fair approximation of a cycle counter. Our experiments show that this approach works reliably on smartphones as well as recent x86 CPUs. The resolution of this threaded timing information is as high as with the other methods.https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
, mitigation we are disabling or reducing the precision of several time sources in Firefox. This includes both explicit sources, like performance.now(), and implicit sources that allow building high-resolution timers, viz., SharedArrayBuffer.Serge3leo
05.01.2018 18:55На мой взгляд, Мозилла дует на воду, таймер в соседнем потоке имеет разрешение заметно ниже вариации работы кэш L1 или спекулятивного выполнения. Впрочем, это зависит от модели общей памяти, для Intel точно ниже.
TheOleg
05.01.2018 02:16Для диванных экспертов сделали первые бенчмарки.
www.techspot.com/article/1554-meltdown-flaw-cpu-performance-windows
www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2
www.phoronix.com/scan.php?page=article&item=linux-more-x86pti&num=1
Никаких 30% там даже близко нет.
В некоторых играх так FPS даже чуть повысился.Sap_ru
05.01.2018 13:23Это мало кому интересно. Основной рынок это сервера. И там все довольно плохо.
Andy_U
05.01.2018 14:03У меня на Windows 7.1 64 bit/i7 3770K@3.7 ггц/Geforce 1080/2560x1600 60 гц frame rate в игре WarThunder упал. До MS патча, с отключенной вертикальной синхронизацией было ~150 на максимальных настройках (в игре, а не во встроенном benchmark'е), причем загрузка видеокарты была под 100% (что позволяло играть на «fast» синхронизации с 120 гц «развертки»). А теперь все уперлось в процессор при frame rate чуть меньше 120 гц и загрузке видеокарты в 65-70%. Или процессор скальпировать и еще разгонять, или с настройками игры экспериментировать, или, что проще всего, отказаться от «fast» вертикальной синхронизации — тогда нагрузка на процессор (ядро) падает до ~70-80%, на видеокарту — до 55-60%.
Пробовал отключить защиту с помощью ключей регистра (требуется перезагрузка!), описанных в: https://support.microsoft.com/en-gb/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution. Защита (см. Powershell скрипт, указанный в конце указанной страницы), отключается, но быстродействие не восстанавливается :(
P.S. Если интересно, могу показать вывод скрипта до патча, после патча и после отключения защиты.
creker
05.01.2018 15:50Я не диванные эксперты читали, в каких условиях падение ожидается и почему? Эти тесты никаким образом не касаются ожидаемого замедления, которое на реальном софте тестами уже подтвердили неоднократно.
TheOleg
05.01.2018 16:17+1Как я понял, замедляется только работа с syscalls.
В бенчмарках в моём комментарии видно проседание на процентов так 10, для реальности надо прибавить ещё само время работы серверов + сетевого стека.
Сам гугл так же выпустил статью про то, что много спекулятивных статей и на их серверах «незначительное» изменение производительности.
security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
unxed
06.01.2018 04:10Интересно, почему никто из диванных аналитиков до сих пор не предположил наличие связи между стремительным ростом альткойнов (на фоне стабилизировавшегося биткойна), существенная часть которых майнится на процессорах, и временем обнаружения/раскрытия дыры в процессорах, спешно сделанное исправление которой «на некоторых задачах» даёт потерю производительности до 30%?
alexr64
06.01.2018 05:11Мимо. Майнинг к этим задачам не относится. При майнинге преобладают именно голые вычисления, а не активный IO, где нужно часто обращаться к ядру ОС.
Waki
Хорошо год начался
Kinokus
И не поспоришь…
Dmitri-D
они всё-таки дают комментарии, но не торопятся
Вот их заявление — в считанные часы после статей
newsroom.intel.com/news/intel-responds-to-security-research-findings
Другое дело, то вообще-то об уязвимости было известно уже в ноябре, и именно интел сообщил разработчикам, что фикса в микрокоде не предвидится.
amarao
Врут и передёргивают в каждом абзаце.
Intel believes these exploits do not have the potential to corrupt, modify or delete data.
(но позволяет читать чужие данные, включая пароли).
Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
(Все подвержены Spectre, но Meltdown — чисто интеловская проблема).
Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
(тормозит в IO, нормально в математике).
Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.
(без комментариев).
iOrange
Здесь пишут что Meltdown так же затрагивает и ARM64
www.opennet.ru/opennews/art.shtml?num=47856
Dmitri-D
совершенно верно
обе эти атаки — это по сути один трюк, с той лишь разницей, что при meltdown происходит переключение контекста на более привелигированный. Если AMD делает это медленнее или быстрее, то, соответственно, и алгоритм нужно адаптировать. И авторы честно об этом заявляют — что это вопрос оптимизации. Это же тайминговая задача.
Практически — да, уязвимость meltdown продемонстрирована только на интеловских ( и на AMD в специальном режиме) Но, AMD всё-таки могло бы за эти 7 месяцев от демонстрации PoC (от 1 июня 2017го — был анонс PoC в адрес чипмейкеров, не публичный анонс, публично пошло вроде как в ноябре) найти и объявить какой конкретно механизм в AMD процессорах делает неуязвимым платформу этим атакам. Ничего не предъявлено. Поэтому рано говорить что проблема чисто интеловская.
IO — да, но насколько я понимаю — тормозит в любой задаче, требующей переключение контекста, в т.ч. и в тех математических, если такое переключение используется.
amarao
Я ещё не закончил читать их pdf'ку, но по квалифицированным комментариям в lwn.net, насколько я понимаю, разница между amd и intel состоит в том, что в спекулятивном исполнении intel сначала делает чтение, а потом проверяет права доступа, а amd сначала проверяет права, а потом читает. Таким образом, при не-выполнении спекулятивного кода intel позволяет прогревать кеш в соответствии с «запретными» данными. А amd спекулятивно готовится к сегфолту (который не происходит).