Comments 513
Хорошо год начался
И не поспоришь…
Intel по понятным причинам предпочитает молчать
они всё-таки дают комментарии, но не торопятся
Вот их заявление — в считанные часы после статей
newsroom.intel.com/news/intel-responds-to-security-research-findings
Другое дело, то вообще-то об уязвимости было известно уже в ноябре, и именно интел сообщил разработчикам, что фикса в микрокоде не предвидится.
Врут и передёргивают в каждом абзаце.
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.
(без комментариев).
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.
(без комментариев).
но позволяет читать чужие данные, включая пароли
совершенно верно
(Все подвержены Spectre, но Meltdown — чисто интеловская проблема)
обе эти атаки — это по сути один трюк, с той лишь разницей, что при meltdown происходит переключение контекста на более привелигированный. Если AMD делает это медленнее или быстрее, то, соответственно, и алгоритм нужно адаптировать. И авторы честно об этом заявляют — что это вопрос оптимизации. Это же тайминговая задача.
Практически — да, уязвимость meltdown продемонстрирована только на интеловских ( и на AMD в специальном режиме) Но, AMD всё-таки могло бы за эти 7 месяцев от демонстрации PoC (от 1 июня 2017го — был анонс PoC в адрес чипмейкеров, не публичный анонс, публично пошло вроде как в ноябре) найти и объявить какой конкретно механизм в AMD процессорах делает неуязвимым платформу этим атакам. Ничего не предъявлено. Поэтому рано говорить что проблема чисто интеловская.
тормозит в IO
IO — да, но насколько я понимаю — тормозит в любой задаче, требующей переключение контекста, в т.ч. и в тех математических, если такое переключение используется.
Я ещё не закончил читать их pdf'ку, но по квалифицированным комментариям в lwn.net, насколько я понимаю, разница между amd и intel состоит в том, что в спекулятивном исполнении intel сначала делает чтение, а потом проверяет права доступа, а amd сначала проверяет права, а потом читает. Таким образом, при не-выполнении спекулятивного кода intel позволяет прогревать кеш в соответствии с «запретными» данными. А amd спекулятивно готовится к сегфолту (который не происходит).
«Это кривое и плохое со всех точек зрения решение, но вы жрите.»
Интел кажется совсем поехал без конкуренции.
Интел кажется совсем поехал без конкуренции.
А уязвим-то кто? Вот у меня Core i5 4-го поколения — с ним-то всё в порядке?
UPD. Чёрт, даже старичок Core2Duo уязвим??
Откуда инфа?
что-то думается, что там и пентиумы М, и даже пни 2 и 3 могут быть задеты. а возможно и нетбёрст…
Сделал тест на своем Core 2 Duo (софт от интел) пишет что да дырка есть
Как минимум с 1995-ого (источник).
Эх, вот не зря процы AMD мне всегда были более симпатичны, чем Intel )))))
Зашел увидеть этот коммент.
Да не, это от бедности нашей :)
Не обязательно. )))
Скорее всего потому, что AMD — это не Intel. Поддерживать не флагмана, а его ближайшего конкурента — мне кажется, это правильно.
Скорее всего потому, что AMD — это не Intel. Поддерживать не флагмана, а его ближайшего конкурента — мне кажется, это правильно.
Viva la revolucion! Viva la Evolucion!
Если решение продиктовано не технологией, а идеологией — нет, не правильно.
С точки зрения потребителя, имеющего долгосрочную стратегию, с позиции маркетинга — это правильное решение.
Ведь поддерживая флагмана можно получить монополию (поскольку конкурент умер, потому что его не покупали из-за того, что он не добрал каких-то N% в каком-нибудь бенче).
А относительно технологии: припой под крышкой (не все любят риск и пойдут на скальпирование), разблокированные множители из коробки без доплаты производителю процессора, долгая поддержка сокетов (а не почти каждый год по новому, не совместимому сокету), отсутствие IME… Уверен, фанаты AMD смогут привести еще что-то полезное, сам пользуюсь Intel, но за каждый успех AMD я искренне радуюсь.
Да, с Ryzen AMD вроде как внедрили аналог. Но сколько лет они сопротивлялись такому искушению)
Кстати, на некоторых материнках под Ryzen его можно отключить )
Для Интела это тоже начинают вводить.
Пофиг. Достаточно использовать другую сетевую карту и уязвимости нет.
Почему МЕ не может выйти в сеть через другую сетевую карту?
Потому что у него драйверов нет для других сетевых карт.
Драйвера в другой ОС или ThreadX в Minix 3 который уже на ARC.
Спор ради спора.
Народ пробовал, не работает. Ни AMT/ME, ни уязвимость.
Официальный ответ интела такой же:
communities.intel.com/thread/114211
Народ пробовал, не работает. Ни AMT/ME, ни уязвимость.
Официальный ответ интела такой же:
communities.intel.com/thread/114211
а теперь набираем полной грудью воздух и скажите мне, в каком месте используются драйвера в intel AMT, когда на ПК нет ОС и я ее удаленно устанавливаю?
В UEFI. Скорее всего там не будет драйвера на стороннюю сетевую карту.
Но Intel ME это не толькоценный мех, это еще и драйвер в операционной системе, которой является доверенным для любого антивируса.
Чистая спекуляция.
Что мешает получить нужные данные аппаратно, передать их драйверу intel me, тот вызовет драйвер сторонней сетевой карты и передаст по сети.
Но Intel ME это не только
Чистая спекуляция.
Что мешает получить нужные данные аппаратно, передать их драйверу intel me, тот вызовет драйвер сторонней сетевой карты и передаст по сети.
На большинстве, что обновляют. Возможность отключать добавили с последним обновлением AGESA.
К сожалению, отключить полностью нельзя, как и в случае с МЕ.
Судя по всему (http://blog.programster.org/stabilizing-ubuntu-16-04-on-ryzen) отключать нужно и многое другое
С точки зрения потребителя 10 лет поддерживал AMD (правда речь про видеокарты, а не процветания) и не имел возможности пользоваться всеми достижениями библиотек машинного обучения. Не знаю, что у меня было в голове, но сейчас-то явно видно, насколько плохое это было решение.
сам пользуюсь Intel
Об этом и речь. Хорошо, когда кто-то поддерживает конкурента, что б выбор оставался. Но самому-то разумно выбирать лучшее.
То, что делает NVidia — это типичный захват рынка, который приведёт к монокультуре и монополии, а это плохо. Intel имела такое же положение на рынке процессоров — и вот результат.
Интересный ник. Глядя на него, мне вспомнилось…
как мы с товарищем купили одновременно видеокарты в 2011 году. Он — AMD, я — nVidia. Он пошел майнить (благо у него совершенно случайно торчали провода от подъездного освещения в квартире), а я пошел ставить Linux и первые Linux игры, потому что майнинг на 560 Ti уже тогда смысла не имел (в отличие от AMD, что он купил за те же деньги). Сегодня у него квартира, машина и дача под Киевом, а у меня — как часы работающий Linux на nVidia и 230 Linux-совместимых игр в библиотеке.
Сегодня у него квартира, машина и дача под Киевом
Это всё он намайнил за 6 лет на одной видеокарте?
В 2011 году на обычной видюхе можно было майнить 1 биткоин в день. В теории, если кто-то этим тогда занялся основательно и не повёлся на несколько волн паники в разные времена — то да, можно было и намайнить на одной видюхе.
В 2011 году за цену 560 Ti можно было купить четверть тысячи биткойнов, и если не повестись на несколько волн паники в разные времена, то безо всякого майнинга (и вообще без видюхи) сейчас можно было бы купить квартиру (в Лондоне), (автопарк) машин, и дачу (на Лазурном берегу).
Можно, но это несравнимые вещи. То что вы описываете — это целенаправленная инвестиция и мало кто на такое отважился в 2011. А купить карту которая в любом случае нужна и майнить по ночам биткоины это другое. Потом достаточно было забыть о кошельке с десятком биткоином лет на 6 и однажды найти приятным бонусом $100 000.
Ну, разве вы не в курсе, как это делалось? Покупалась видеокарта, отбивалась ее стоимость, продавалась. Покупалась предтоповая. Потом еще 1. Потом еще 1. Потом выходило новое поколение, они менялись. Потом у него был ASIC, вложения в который он также отбил. И все это на фоне условно-бесплатного электричества.
Понятно, что и у меня сегодня стоит не та же видеокарта, что и 6,5 лет назад.
Я просто к чему эту историю привел — вот, у нвидии есть PhysX, CUDA-вычисления и ML, а у AMD Radeon было и есть преимущество в фарме различных монеток.
Вы понимаете, что оценка «лучше/хуже» вообще не применима без уточняющих вопросов? К примеру, под ваши цели видеокарты nVidia действительно подходили гораздо лучше.
А то, что получилось у вашего приятели подпадает под выражение «знал бы прикуп — жил бы в Сочи». И никакого отношения к качествам железа не имеет, если быть объективным.
А то, что получилось у вашего приятели подпадает под выражение «знал бы прикуп — жил бы в Сочи». И никакого отношения к качествам железа не имеет, если быть объективным.
Чушь какая-то, еще в 2013 можно было майнить на 9600 радеоне по 0.3 битка в месяц, в 2011 без проблем можно было майнить даже соло хоть на кофейной машинке. Биткоин только зарелизился в паблик.
Допустим, вы бы тоже купили AMD. У вас в квартире были провода, чтобы ВОРОВАТЬ электричество? Как-то часто разговоры о гигантских заработках на майнинге сводятся к «бесплатной» розетке, а по сути к воровству электроэнергии и/или оплате этой электроэнергии всеми жильцами дома. С тем же успехом можно гоп-стопить в подъезде, у каждого проходящего требуя по 100 рублей в день.)
Понимаете, это лишь влияет на окупаемость. Т.е. капитальные затраты (железо), операционные затраты на майнинг (электричество), операционный доход (продажа монеток). С ценой электричества, отличной от нуля, срок окупаемости растет, но с учетом невысоких цен на электричество (в сравнении с Германией/США, где тоже майнили монетки), это все равно было выгодно.
Ну и мой товарищ потом в качестве компенсации проспонсировал
работы по благоустройству, подарив приличную сумму денег их УК.
P.S.: сравнивать воровство, которое имело место быть в примере, и грабеж/разбой, ну даже не знаю...
Лишь? Хотя, в те года сложность майнига была ниже, это сейчас на большинстве карт майнинг будет в минус…
Если товарищ «компенсировал», то хотя бы не такой он падла, как выглядело из первого комментария. Хорошо, что вы уточнили, что он не совсем «сволочь со сволочной начинкой, облитый сволочизмом»(с). С другой стороны, мог бы просто из своей розетки питаться. Но это всякие глупости про облико морале.
Если товарищ «компенсировал», то хотя бы не такой он падла, как выглядело из первого комментария. Хорошо, что вы уточнили, что он не совсем «сволочь со сволочной начинкой, облитый сволочизмом»(с). С другой стороны, мог бы просто из своей розетки питаться. Но это всякие глупости про облико морале.
качестве компенсации проспонсировал
работы по благоустройству, подарив приличную сумму денег их УК.
А чем он тогда отличается от типичного депутата? Сначала обваровывает всех (используя привилегерованные условия) — наживается на этом. А потом в качестве «доброй воли» делает спортивную площадку детям.
Украл у соседей, которые оплачивали ОДН, а проспонсировал УК?
Как-то часто разговоры о гигантских заработках на майнинге сводятся к «бесплатной» розетке, а по сути к воровству электроэнергии и/или оплате этой электроэнергии всеми жильцами дома
А это неправда. Я не буду брать в расчет Европу, но например в Украине я ради интереса прошлой весной дома запустил майнинг эфирок на достаточно бывалой Radeon 7950. Чистый доход был порядка $8/месяц. С одной, достаточно прожорливой видеокарты. И это просто на эфирках по курсу примерно $50. Сколько там они стоят сейчас, $950? Вот если бы я их тогда не продал, я бы уже заработал с месяца майнинга $150. По-моему, вполне окупаемое занятие, не правда ли?
Эммм, нет. Потому что тогда — не сейчас. Ведь сейчас не по 150 долларов майнится чистыми, а те же условные 8, из-за выросшего курса. Опять же, прост окупив эфир по 50 тогда и продав сейчас по 950… Но это уже совсем оффтоп.)
Понимаете в чем разница. Купив за деньги железку, вы получаете через пару месяцев (деньги И/ИЛИ коины) и железку на выходе.
А купив за деньги коины, вы получаете на выходе коины. Без железок, без денег.
Вероятно, потом, когда-нибудь, их можно будет продать с неким наваром, а вероятно и нет.
Поэтому люди массово уже тогда майнили, а покупать массово коины не покупали.
Эммм, нет. Потому что тогда — не сейчас. Ведь сейчас не по 150 долларов майнится чистыми, а те же условные 8, из-за выросшего курса.
Если нужно подобрать формально определение процессу, то да, наверное вы правы. Если же мы говорим о «выгодности майнинга», то суть в том, что вы потратили десять долларов за электроэнергию, а на выходе через полгода получили $150. И неважно, что значительная часть этой суммы отбита за счет роста курса криптоденюжки. Вы-то ничего для этого не делали, просто майните и ждете. Тем более что вообще нет смысла рассматривать доход от майнинга в отрыве от курсового дохода, учитывая нестабильность курсов криптовалют, и что этот самый курс десять раз изменится, пока вы майните 0,1 эфирку. Это два тесно связанных процесса в одном и том же бизнесе.
Radeon 7950. Чистый доход был порядка $8/месяц.
Сейчас она почти $50 майнит. Карты все еще актуальны, хотя на них еще лайт с догами майнили.
В РФ электричество тоже дешевое и цены на него растут медленно. Например с тех пор как рубль подешевел в 2 раза у меня тариф на 40% подняли — в реальности стало еще дешевле.
Кто победил-то?
Знаете, это история с открытой концовкой, и оба случившихся варианта имеют свои плюсы и минусы. Настоящая жизнь — не черно-белый мир. Каждый может решить для себя.
Если бы я мог отыграть назад и знать, что и как будет, я бы сделал как выше уже предложили — купить 250 битков и положить их в дальний угол. "Знал бы прикуп, в Сочи жил".
Как было бы правильно: купить AMD Radeon, а на намайненное (пусть и дольше, у меня "случайно" провода от подъездного освещения в квартиру не заходили) купить для nVidia 560 Ti, и осталось бы немного битков. В запас. Хоть экономика моя была бы и хуже, чем у товарища — наличие операционных затрат, трата на стороннее железо вместо реинвестирования. Зато совесть была бы чиста и в библиотеке у меня также бы водились Linux игры, а в карманах бренчали бы [s]биткоины[/s] кэш.
Такие перспективы интересуют только большие корпорации, обычному пользователю надо лучше и быстрее прямо сейчас, а не через 20 лет.
Почему же от бедности? Это называется экономика) Я стал «фанатом» AMD после того как Intel облапошила с Hyper-threading, это стало своего рода принципом. И вот оно, вознаграждение за принципиальность)
Где можно узнать про то, что не так с hyperthreading? Помимо сегодняшнего, я из интеловских крупных хардварных багов я только про FDIV и Netburst знаю.
Подробно было тут:
«Replay: неизвестные особенности функционирования ядра Netburst»
«Replay: неизвестные особенности функционирования ядра Netburst»
https://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 переделали...
Ну, Dessloch вспоминает практически единственный случай, когда АМД со своими процами с открытыми кристалами обскакали Интел с их Пентиумом 4. Современную ситуацию с Ryzen не рассматриваю — как по мне, так еще рано анализировать, кто в этом раунде победил.
Зря или не зря, но вот жрать последствия (судя по тексту новости) будут все пользователи, которые не собирают ядра вручную. Может конечно позже появится патч который будет работать избирательней, но тут именно, что «может».
При всей любви к AMD нельзя забывать об аналогичном факапе с первым Феномом: там хоть ошибка была связана не с безопасностью, а с арифметикой, но исправление через микрокод тоже существенно снижало производительность.
Скорее всего AMD подвержена одной из двух уязвимостей.
ARM уже честно отчитался — developer.arm.com/support/security-update
Intel написала извините откровенную фуйню — newsroom.intel.com/news/intel-responds-to-security-research-findings
Осталось еще вспомнить, что внутри intel есть еще arc процессоры под управлением ThreadX или minix 3, с которыми в общем мало, что понятно. Но там видимо своя дискотека.
ARM уже честно отчитался — developer.arm.com/support/security-update
Intel написала извините откровенную фуйню — newsroom.intel.com/news/intel-responds-to-security-research-findings
Осталось еще вспомнить, что внутри intel есть еще arc процессоры под управлением ThreadX или minix 3, с которыми в общем мало, что понятно. Но там видимо своя дискотека.
На сайте с описанием уязвимости (https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html) указаны 3 варианта атаки, опирающихся на две уязвимости.
Насколько понимаю, Интел подвержен всем, и еще ничего не исправлено, АМД же подвержен одной, самой слабой, и это пофиксили еще в осенних обновлениях прошивок.
Насколько понимаю, Интел подвержен всем, и еще ничего не исправлено, АМД же подвержен одной, самой слабой, и это пофиксили еще в осенних обновлениях прошивок.
>АМД же подвержен одной, самой слабой, и это пофиксили еще в осенних обновлениях прошивок.
Spectre довольна серьезная ошибка. Мы еще с ней щей хлебнем. (из которых найдено две )
По поводу первой или ее действительно нет или не смогли подобрать алгоритмы для кеша.
Spectre довольна серьезная ошибка. Мы еще с ней щей хлебнем. (из которых найдено две )
По поводу первой или ее действительно нет или не смогли подобрать алгоритмы для кеша.
У АМД зато нашли ошибку в PSP: http://seclists.org/fulldisclosure/2018/Jan/12
AMD PSP [1] is a dedicated security processor built onto the main CPU die.… fTPM is a firmware TPM [3] implementation. It runs as a trustlet application inside the PSP. fTPM exposes a TPM 2.0 interface over MMIO to the host [4].… stack-based overflow in the
function EkCheckCurrentCert. This function is called from TPM2_CreatePrimary with user controlled data — a DER encoded [6] endorsement key (EK) certificate stored in the NV storage.… We verified that full control on the program counter is possible:
Эпично. Вот теперь вопрос почти религиозный: можно ли гарантировать то, что патч НЕ будет установлен? Т.к. многие будут готовы пожертвовать гипотетической безопасностью ради существенного прироста (точнее, сохранения того что было) скорости.
Отключается в конфиге ядра.
Я именно про осознанное отключение, инициированное пользователем. В маках или винде, насколько легко будет отключить? С линуксом-то понятно, хотя вопрос остается: будет ли эта настройка явно выведена где-то в дистрибутивах (в интерфейсе гнома, кде и т.п. синнамонов)?
Представил апплет с единственным Switch button «Security/Performance». А ещё лучше — отдельный тумблер на клавиатуре.
KPTI can partially be disabled with the «nopti» kernel boot option.en.wikipedia.org/wiki/Kernel_page-table_isolation
В тех же играх 30% сильно скажется, поэтому очень даже интересно, предусмотрят ли отключение в винде
30% там на syscall-heavy сценариях. Игры же в основном упираются в GPU, сисколов там не сильно много.
То есть обычный процесс взаимодействует с видеокартой, минуя ядро?
Для вызовов отрисовки — да — 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
а если игра на новомодных vulkan, metal и d3d12?
Учитывая, что это позволяет стороннему процессу чтение паролей и прочей секьюрной инфы в памяти, то думаю отключить будет невозможно. По крайней мере в пользовательских ОС.
Судя по коду на гите, изоляцию можно отключать.
+ pti= [X86_64]
+ Control user/kernel address space isolation:
+ on — enable
+ off — disable
+ auto — default setting
Вопрос не праздный: падение производительности на моем стареньком Core2Quad мне совсем не нужно, а мифическая уязвимость в области виртуальных машин и прочего тревожит не сильно.
Виртуальные машины тут ни при чём скорее всего. Возможно, будут и javascript эсплойты, через браузер.
Даже если так, то я готов чтобы браузер работал медленнее, а не весь комп.
Как я понял, уже есть.
sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca
sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca
Инфа секретная — почти любому Core 2 Quad уже больше 10 лет. Уточню — я предполагаю, что все Yorkfield существенно не отличались этим от QX9650 и не могли ещё содержать такого бага.
Про совет ниже — если термин «виртуальная машина Java» относится к указанным проблемам, то снесите Java со своей Винды:)
Про совет ниже — если термин «виртуальная машина Java» относится к указанным проблемам, то снесите Java со своей Винды:)
Мне кажется, народ неверно понимает причины упоминания виртуализации. Как я понял, зловред сможет получить доступ к памяти ядра процессора. И не важно, есть у вас виртуальные машины на компе или нет. Для владельцев ферм виртуальных машин опасность в том, что они не контролируют, что там запускают пользователи на арендованных мощностях, а те могут получив доступ к памяти ядра получить данные (повлиять?) других виртуальных машин или хост-системы.
Да, с такой фигней согласен. Хотя не читал конкретного описания бага в контексте виртуализации.
Действительно ли именно из виртуалки есть возможность получить доступ к памяти ядра хоста? Конечно, если скажем виртуалка сможет передать какой-то код через драйвер сетевой карты, а Вы разрешили этой виртуалке как минимум доступ к каким-то папкам на запись. В теории возможная функция для тех же хостингов или никто так не делает (максимум — создаст такой доступ через какую-то другую виртуалку, правда не знаю, какую сетевую инфраструктуру можно создать в таком случае в виртуальной среде)?
Действительно ли именно из виртуалки есть возможность получить доступ к памяти ядра хоста? Конечно, если скажем виртуалка сможет передать какой-то код через драйвер сетевой карты, а Вы разрешили этой виртуалке как минимум доступ к каким-то папкам на запись. В теории возможная функция для тех же хостингов или никто так не делает (максимум — создаст такой доступ через какую-то другую виртуалку, правда не знаю, какую сетевую инфраструктуру можно создать в таком случае в виртуальной среде)?
Т.к. многие будут готовы пожертвовать гипотетической безопасностью ради существенного прироста
Понимаете, сейчас про суть уязвимости все причастные молчат. Но когда патчи пойдут в массы, с ней ознакомятся все желающие и заинтересованные. И безопасность будет уже далеко не гипотетической, благо, непропатченных машин для распространения зловредов будет предостаточно.
Тогда почему бы не попросить всех причастных молчать и дальше? Неужели нельзя обойтись без публикации подробностей? Ведь если уязвимость настолько неочевидна, что её 10 лет не могли найти, то без публикации кода потенциальные злоумышленники ещё лет 7 провозятся как минимум. Зачем упрощать им задачу?
Как по мне, подробности уязвимости помогут исследователям. Каждая подобная хитрая уязвимость это идея другим исследователям, где им стоит искать, и о чем они могли даже не думать раньше. Прочитает человек, решит поискать в процессорах других архитектур, а там окажется что-то похожее.
en.wikipedia.org/wiki/Security_through_obscurity
Это мнимая безопасность. Информация тем и отличается, что ее дублирование происходит незаметно для оригинала.
Это мнимая безопасность. Информация тем и отличается, что ее дублирование происходит незаметно для оригинала.
Нашли одни, найдут и другие, тем более держать в секрете сложно, там небось целая орда анализом причин занималась.
А как только будут патчи, то уже ничего скрывать — по коду разберутся.
А как только будут патчи, то уже ничего скрывать — по коду разберутся.
Патамушта.
для Linux можно просто передать ядру параметр nopti, с другими ОС пока ничего не ясно.
В целом, всё не так страшно. В играх, например, просадки может не быть вовсе
www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests
В целом, всё не так страшно. В играх, например, просадки может не быть вовсе
www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests
тест не самый лучший ибо используется свежайший Coffee Lake, для которого есть смягчающий импакт фактор. Вот если бы там было что-то типа i7-2600k, который явно проиграет сильнее всего…
<sarcasm_on>
Можно уже включать режим теории заговора, и утверждать что производитель подталкивает к замене процессора?
<sarcasm_off>
i7-2600k, который явно проиграет сильнее всего…
Можно уже включать режим теории заговора, и утверждать что производитель подталкивает к замене процессора?
<sarcasm_off>
Да нет, почему-же. Процессор до сих пор держится на уровне i5-7400 в «попугаях» многоядерной производительности и вполне справляется с «офисными» задачами и почти вытягивает современные игры в паре с какой-нибудь 1070 (при этом правда подбираясь к 100% загрузке почти вплотную в супертяжёлых релизах) — просто интересно насколько более старые, но актуальные mid-highend процессоры из второго-третьего поколения получат урона относительно более свежих — в таком случае возможно и ставить патчи смысла нет, а проще будет сразу менять платформу на свежее, благо что так или иначе эти процессоры уже подходят к границе «пора менять»
i5-4570 не поддерживает, а он вышел позже.
HWiNFO64 показывает поддержку PCID в i5-4570S, скрипт от Майкрософта подтверждает:
Windows OS support for PCID optimization is enabled: True
Могу скриншот привести. Я проверял и самописным скриптом через CPUID(EAX=1) и AIDA64 — в обоих случаях результат один (у меня процессор просто i5-4570, без S)
Извиняюсь за недостоверную информацию: гипервизор меняет значения CPUID, отключая в том числе PCID — при выключенном Hyper-V результаты совпали с вашими.
На 3470, похоже, тоже поддерживается PCID.
i5-3470
мало информации.
про какие процессоры речь? все core i? пни? селероны? каких поколений/годов выпуска?
какие ОС? та же XP уже ведь того…
можно ли будет отказаться от патча? ведь если есть старенький, например, селерон, который работает почти на пределе, то такой патч забрав себе эти гипотетические 30% производительности может совсем привести к необходимости срочного апгрейда машины
про какие процессоры речь? все core i? пни? селероны? каких поколений/годов выпуска?
какие ОС? та же XP уже ведь того…
можно ли будет отказаться от патча? ведь если есть старенький, например, селерон, который работает почти на пределе, то такой патч забрав себе эти гипотетические 30% производительности может совсем привести к необходимости срочного апгрейда машины
Простите, но разве работа на пределе не является индикацией для срочного апгрейда машины?
Работа ПОЧТИ на пределе — индикация сбалансированной системы. А вот если компьютер простаивает, то была переплата за ненужные мощности. Но это если формально к вопросу подходить. А по факту, я тоже предпочитаю недогружать, чтобы кулерами не шелестели.
Есть люди, которые верят, что для процессора является нормой работа на Tjunction как минимум 8700 часов в год.
Думаю, не является, если пользователю хватает скорости/возможностей, поэтому сейчас срочный апгрейд не нужен.
может совсем привести к необходимости срочного апгрейда машины
Вы нашли самую суть и скрытый смысл данной проблемы )
Это заговор…
Это заговор…
Да ну, какой там «заговор».
В 1995 году еженедельник «Компьютерное обозрение» перепечатал откуда-то опрос представителей десятка крупнейших компьютерных фирм того времени на тему «Каким вы видите процессор 2005 года?» (не дословно)
Я, по тогдашней своей привычке, вырезал эту статью и сохранил ее в тематической папке.
Как раз в 2005 году, в связи с предстоящим ремонтом — я случайно наткнулся на эту, давно забытую папку, и снова прочитал этот прогноз.
Из тех компьютерных фирм к 2005 году осталось меньше половины. Прогнозы всех специалистов прошли мимо цели — кроме одного, сделанного представителем Интел.
Он, в 1995 году — точно описал параметры Р4 Prescott — тактовую частоту, количество транзисторов на чипе, размер кэша и применяемый техпроцесс.
(В случайные совпадения я не верю )
В интеле все-таки работают крутые профессионалы и не так уж невероятно что спец смог предположить на основе уже созданных процов, в том числе тех, что не успели выйти на рынок, а это скорее всего лет на 5 вперед линейка, параметры еще на тот момент не созданного. Круто, но не то чтобы нереально. А вот если бы он тогда уже существовал, пусть и в виде тестового образца, то спецу никто бы не дал его параметры описать.
что спец смог предположить
Я сам инженер, до известных событий 90х занимался разработкой и внедрением не менее интересных и сложных изделий, чем процессоры.
10 лет — это как раз тот срок, на который планируется разработка и внедрение чего-то реально нового в производство. При этом обычно уже известно, что это будет и как именно будет работать.
Упомянутая статья — всего лишь одно из подтверждений того, что этот процесс «на Западе» происходит точно также, как это было у нас (есть еще масса интересных косвенных сведений в издававшемся тогда журнале «В мире науки»).
Процессор с кодовым именем Willamette впервые появился в официальных планах компании Intel в октябре 1998 года, хотя его разработка и началась вскоре после завершения работ над процессором Pentium Pro, вышедшим в конце 1995 года, а название «Willamette» упоминалось в анонсах 1996 года… Предполагалось, что Willamette выйдет во второй половине 1998 года, однако, в результате многочисленных задержек анонс был перенесён на конец 2000 года. В феврале 2000 года на форуме разработчиков Intel (IDF Spring 2000) был продемонстрирован компьютер, основой которого служил инженерный образец процессора Willamette, получившего наименование «Pentium 4» (с) Вики
Я сам инженер, до известных событий 90х занимался разработкой и внедрением не менее интересных и сложных изделий, чем процессоры.
Вы занимались не процессорами, следовательно я не вижу причин почему ваш случай можно продолжить на процессоры. "Не менее сложные и интересные" — весьма слабая характеристика. И даже так ваш комментарий никак не противоречит возможности для крутого спеца реально предсказать направление разработки на 10 лет вперед.
Вы занимались не процессорами, следовательно я не вижу причин почему ваш случай можно продолжить на процессоры
Потому что процесс разработки и внедрения в производство зависит только от степени сложности выпускаемого изделия, а не от его конструкции и назначения. Этапы разработки будут одинаковыми.
Даже избыточное финансирование и широкое применение ВТ не дает существенного ускорения, так как в реале все зависит от человека (коллектива), а его возможности ограничены.
возможности для крутого спеца реально предсказать направление разработки на 10 лет вперед.
Вы читали вторую цитату в предыдущем сообщении?
Там все написано прямым текстом — никакого «предсказывания» не было, человек поделился реальными планами Интел (в 1995 это еще случалось )
Относительно процессоров, вы упускаете один важный момент — стоимость разработки и начала выпуска катастрофически превышает затраты на фактическое производство. Чтобы просто окупится, не говоря уже о прибыли, необходимо продать товар в огромных количествах, а это занимает значительное время. В ином случае новые процессоры бы каждые полгода появлялись, если не чаще.
Ждем первых эксплойтов
Немного оффтоп.
Раньше не задумывался, но как вообще возможен доступ одного процесса в область памяти другого (или ядра) при наличии виртуальной памяти и независимых адресных пространств? Это касается не только этой уязвимости, но даже, к примеру, дебаггеров и того же ArtMany?
Что значит «независимых»? Физическая память одна. Мэпинг адресов и права прописаны в дескрипторах MMU, никто не мешает (в кольце 0) создать для разных процессов дескрипторы, адресующие одну и ту же (или с перекрытием) область.
Попробуйте хакнуть ArtMoney процесс своего антивируса (хотя бы окна GUI).
Ну по поводу например 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
Специально для этого сделаные.
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
Специально для этого сделаные.
Через 50 лет:
Из-за уязвимости в чипах Intel, вживляемых в мозг, можно получить доступ к мыслям человека.
В некотором царстве, в некотором государстве, к тому времени у всех будут «правильные» чипы с таким функционалом «by design».
Из-за закрытия уязвимости в чипах Intel, вживляемых в мозг, мы снизили вам производительность работы мозга на 30%. Не волнуйтесь, вы всегда можете взять ипотеку на новый чип.
Вполне возможно, что уже 100 Васей продали, перед тем как её нашли добрые ребята
Современные процы настолько сложные, что баги в них просто невозможно отловить полностью, ни вручную, ни автоматикой. То ли еще будет.
Очень верно замечено. Когда в процессоре сотни миллионов логических элементов, вероятность наличия одной или нескольких уязвимостей в нём очень близка к единице. Обнаружение критических уязвимостей в существующих процессорах — лишь вопрос времени и удачи (в теорверовском смысле).
Возможно что условный хакер Вася продавал эту уязвимость месяц-другой до обнаружения.
Не факт, что у красных нет уязвимостей. Просто они намного менее популярны, вот и не ищут дыры в их процах так интенсивно.
то-есть ситуация как с линуксом и вирусами?
SPECTRE вообще все текущие CPU подвержены.
то-есть ситуация как с линуксом и вирусами?
Нет, это проблема дизайна 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 и прекратятся эпидемии. Всего лишь нужно не просто сделать технологии безопасности, их нужно сделать такими же удобными, как в других ОС.
многие не отключают в Федоре и других дистрибутивах SELinuxСправедливости ради в Федоре, если не прилетели правила, то приложение будет в unconfined запускаться. Ну и теперь еще firefox в песочнице не запустить.
А вообще, все правильно…
Что делает пользователь линуксов, когда обнаруживает, что stable-версия приложения отстала лет на 5? Переходит на ~, после чего ему приходится перевести на ~ пару библиотек, а затем и пол-системы, потому как зависимости. Оттуда остается лишь один шаг до ** и установки напрямую.
Это уже почти стандарт — запись в свою инсталляционную директорию. А вот линуксовые приложения пишут куда попало, лишь бы хватало прав.
Многие сидят под root-ом, что это доказывает-то?
Добавим сверху альтернативные репозитории, немодерируемые помойки типа сборника плазмоидов, отсутствие хоть какой бы то ни было ответственности и получим полную картину.
говноприложение, если юзеру повезёт, для своей работы требует прав на запись в свою папку
Это уже почти стандарт — запись в свою инсталляционную директорию. А вот линуксовые приложения пишут куда попало, лишь бы хватало прав.
многие отключают даже примитивный UAC
Многие сидят под root-ом, что это доказывает-то?
Linux логиниться в десктоп энвайромент рутом просто неудобноНе замечал каких-либо сложностей.
Добавим сверху альтернативные репозитории, немодерируемые помойки типа сборника плазмоидов, отсутствие хоть какой бы то ни было ответственности и получим полную картину.
Кто например? Думаю, единицы
— Во второй Мировой погибло 20 миллионов советских граждан
— Кто например? Думаю, единицы.
В каком формате вы представляете ответ на свой вопрос? Я с завидной регулярностью вижу, как люди или сидят под рутом, или у них sudo не требует пароля.
На Raspbian sudo без пароля прямо по умолчанию. В других дистрибутивах отключение запроса пароля для sudo — одна строчка, даже проще чем выключить UAC.
Работа под рутом — тоже не проблема.
И объясняется это точно так же как и отключение UAC — нежеланием сталкиваться с какими бы то ни было подтверждениями.
Я вот не вполне понимаю, почему одни и те же люди зачастую упорно доказывают, что UAC с его диалоговым окном, кстати, показывающим подписано приложение или нет — это ужас-ужас-ужас, а точно такое же окно sudo — «никому не мешает». И уж совсем я не понимаю, почему система, в которой все завязано на одну сущность с абсолютными правами (root) считается более безопасной, чем система, где права разделены между разными сущностями (System, TrustedInstaller, Administrator и т.д.)
А уж тот печальный факт, что в части дистрибутивов нет даже ArmorApp и любое приложение может читать данные других приложений без уведомлений и подтверждений…
Работа под рутом — тоже не проблема.
И объясняется это точно так же как и отключение UAC — нежеланием сталкиваться с какими бы то ни было подтверждениями.
Я вот не вполне понимаю, почему одни и те же люди зачастую упорно доказывают, что UAC с его диалоговым окном, кстати, показывающим подписано приложение или нет — это ужас-ужас-ужас, а точно такое же окно sudo — «никому не мешает». И уж совсем я не понимаю, почему система, в которой все завязано на одну сущность с абсолютными правами (root) считается более безопасной, чем система, где права разделены между разными сущностями (System, TrustedInstaller, Administrator и т.д.)
А уж тот печальный факт, что в части дистрибутивов нет даже ArmorApp и любое приложение может читать данные других приложений без уведомлений и подтверждений…
На Raspbian sudo без пароля прямо по умолчанию.
Там по-умолчанию логинятся в KDE/Gnome/XFCE под рутом? При чём тут консоль?
В других дистрибутивах отключение запроса пароля для sudo — одна строчка, даже проще чем выключить UAC.
Это сделано для серверов, для того, что бы можно было запускать автоматически без ввода пароля какой-либо скрипт, причём чаще даже не под рутом, а под специфическим юзером. На десктопе типичный юзер просто поленится это отключать, а для серверов права можно выдать именно на отдельный скрипт.
Если специально постараться, можно, конечно, и систему сломать с помощью rm -rf /*
Но ведь это специально нужно что-то делать! А В Windows опасные и десктруктивные юзерские и разработческие паттерны приняты по-умолчанию.
Я вот не вполне понимаю, почему одни и те же люди зачастую упорно доказывают, что UAC с его диалоговым окном, кстати, показывающим подписано приложение или нет — это ужас-ужас-ужас, а точно такое же окно sudo — «никому не мешает». И уж совсем я не понимаю, почему система, в которой все завязано на одну сущность с абсолютными правами (root) считается более безопасной, чем система, где права разделены между разными сущностями (System, TrustedInstaller, Administrator и т.д.)
во-первых, не один юзер, а множество. Считается довольно дурным тоном запускать демоны под рутом: обычно демоны работают под своими собственными юзерами, а во-вторых, мандатный контроль, который большинство юзеров Убунты не отключает(Apprmor прекрасно работает), а на моём PC и ноутбуке включён и SELinux, а в Windows MAC фактически нет: его сделали для какой-нибудь сертификации, и не то что бы его хоть кто-то включал, никто и никогда не писал профилей для приложений для Windows MAC. Его просто не существует.
Это не так. Все рекомендации по написанию программ, начиная минимум с висты, предписывают вполне безопасные практики написания программ, а механизмы перенаправления позволяют работать старым программам (и кривым новым) без администраторских прав.
Вот именно: формально всё есть, а фактически нет. По тому, что никаких рычагов воздействия на разработчиков нет, они будут делать так, как привыкли, какая пагубная традиция уже сложилась.
Эта проблема (вместе с большей частью эпидемий) уйдёт, только когда Windows Store, а не гугл-поиск, станет основным способом дистрибьюции софта под Windows. В Windows Store можно будет следить за качеством софта. Это прекрасно работает в Apple Store, в PlayStore (ну, может, чуть хуже, но трояны обычно оперативно удаляют), в линуксовых репозиториях
Опять неверно. Даже если отбросить права доступа, то Mandatory Integrity Control настроен для многих системных процессов и файлов, и по умолчанию настроен для всех процессов в средний уровень.
Это бесполезно, пока нет профилей под популярные приложения и сервисы, которые могут быть векторами атаки, увы :(
Вот когда юзер вместо поиска гугла за приложением под Windows будет ходить в PlayStore, и когда для значимой части популярных приложений в Windows Store будут профили для MAC'а, тогда и антивирусы не будут нужны, как в других ОС, и эпидемии тоже закончатся.
Эта проблема (вместе с большей частью эпидемий) уйдёт, только когда Windows Store… станет основным способом дистрибьюции софта под Windows.
Тогда винда окончательно превратится из ОС общего назначения в очередную частную песочницу. Впрочем, как показывает опыт, "массовому потребителю" обычно это и надо. Хоть и печально.
Никто не говорит «запретить юзеру инсталлить софт абы откуда». Посмотрите на любого представителя семейства Linux: есть официальные репозитории, но никто не мешает установить пакет, скачанный вручную, или же вообще собрать софт из исходников.
или можно использовать репозиторий от коммюнити, которому доверяешь
Во-первых, одно дело линукс из "свободного" софта, а другое дело — что-то проприетарное. Во втором случае гораздо выше вероятность вставки разной мощности палок в колёса тем кто ставит мимо официального репозитория.
Во-вторых, даже если вышеописанный пессимистичный сценарий не реализуется, то факт "windows store — основной способ распространения софта" уже сам по себе означает, что система так или иначе ориентирована на него, а остальное работает — ну просто работает, но без стремления со стороны авторов ОС делать что-то полезное для таких.
Тогда можно будет окончательно попрощаться с Windows, ибо никаких преимуществ у этой ОС не останется.
Т.е. Вы считаете, что отсутствие адекватного репозитория софта — преимущество?
Там, где нужно, эти профили уже давно есть. Все современные браузеры используют эти и многие другие механизмы безопасности ОС. Все встроенные программы и утилиты от МС так же используют уровни целостности.
А действительно нужно, чтобы Вася, наваявший очередной Hello-word-app, обязан был предоставить ОС и пользователю действительный список требуемых привилегий в рантайме. И вот как раз централизованный, официальный репозиторий нужен, чтобы убедиться, что скачанный дистрибутив
современного браузераявляется действительно дистрибутивом современного браузера, а не продуктом жизнедеятельности Васи.
Т.е. Вы считаете, что отсутствие адекватного репозитория софта — преимущество?
Угу. Мне ситуация напоминает ситуацию в MS-Dos. Операционная система тогда не поддерживала видео и звук, каждая игра это писала самостоятельно.
Сейчас каждый разработчик самостоятельно пишет инсталлятор для своего софта. Так каши не сваришь.
Сейчас каждый разработчик самостоятельно пишет инсталлятор для своего софта.
А то и библиотеки рантайма vc++ за собой таскает.
Сейчас каждый разработчик самостоятельно пишет инсталлятор для своего софта.И зачем бы это делать, если есть типовые обертки-инсталляторы еще со времен W95?
И зачем бы это делать, если есть типовые обертки-инсталляторы еще со времен W95?
Это должна делать операционная система. То, что в Windows этим традиционно занимаются разработчики прикладных приложений, как в MS-Dos сами реализовывали поддержку звука и 3D ускорения, это анахронизм, который, может быть, главная причина постоянных эпидемий на Windows-платформе
Это должна делать операционная система
Обсуждаемое утверждение: «Сейчас каждый разработчик самостоятельно пишет инсталлятор для своего софта»
Это очевидно не так.
Если же вы хотите поговорить про преимущества интеграции инсталляторов в систему, то рассмотрите ее на примере поддержки portage в Ubuntu или apt в Gentoo.
Обсуждаемое утверждение: «Сейчас каждый разработчик самостоятельно пишет инсталлятор для своего софта»
Это очевидно не так.
Взять готовый фреймворк и использовать практически равно «самостоятельно написать». Если Вы не согласны, то тогда все, кто не пишет машинный код, или хотя бы не на ассемблере, не разработчики.
Главное, что инсталлятор мантайнится разработчиком самостоятельно, и он его технический долг
Ровно как поддержка 3D ускорения и звука на системном уровне в играх в 90х тоже была техническим долгом разработчика.
Если же вы хотите поговорить про преимущества интеграции инсталляторов в систему, то рассмотрите ее на примере поддержки portage в Ubuntu или apt в Gentoo.
Зачем?
А как должно быть иначе? Скрипты для управления процессом инсталляции это технический долг разработчика приложения и никого другого. Собственно, иначе невозможно. В фреймворках на винде это какой-нить скрипт или проект инсталлятора. Для debian пакетов это описание и набор скриптов. Что вы хотите иначе здесь увидеть?
В винде действительно есть msi, и он чрезвычайно популярен. Ваш вопрос решен. Но в любом случае находится тот, кто желает сделать свой велосипед. За неимением жестких ограничений иначе не будет.
В винде действительно есть msi, и он чрезвычайно популярен. Ваш вопрос решен. Но в любом случае находится тот, кто желает сделать свой велосипед. За неимением жестких ограничений иначе не будет.
А как должно быть иначе? Скрипты для управления процессом инсталляции это технический долг разработчика приложения и никого другого. Собственно, иначе невозможно. В фреймворках на винде это какой-нить скрипт или проект инсталлятора. Для debian пакетов это описание и набор скриптов. Что вы хотите иначе здесь увидеть?
Нет, это технический долг мантайнера — есть такая профессия :)
Вам изложили анти-паттерны, а вы доказываете, что их использование — это нормально?
Что делает пользователь линуксов, когда обнаруживает, что 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 из «левого» репозитория и официальный тарболл, и соберу пакетик несколькими несложными командами.
В KDE или Gnome? Вы много знаете таких мазохистов? Ведь всё будет глючить, падать, отваливаться или работать странным образом :(RHEL и Centos еще и сопротивляться будут. Да и большинство дестоп-дистрибутивов сейчас даже не спрашивают пароль для рута при установке.
Если мне нужно что-то, чего нет в официальных репах федоры и трёх самых популярных репозиториях от коммьюнити, возьму спек src.rpm из «левого» репозитория и официальный тарболл, и соберу пакетик несколькими несложными командами.На самом деле я еще не столкнулся с проблемой, что мне чего-то не хватает в fedora и rpmfusion. В генту приходилось один или два оверлея подключать, но с ней долго жить невозможно, в конечном итоге тебе надоедает повышать энтропию вселенной сборкой какого-нибудь хромиума и ты съезжаешь на что-то более удобное. Хотя по скорости с ней никто не сравнится.
А по работе без проблем пересобираю пакеты, когда нужно было отключить зависимости или добавить поддержку библиотеки, которой нет в стандартном пакете.
бинарники в 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.
Увы-увы, в некоторых дистрибутивах СПО головного мозга доходит до того, что в базовых репозиториях нет проприетарного софта типа Chrome (а иногда и Chromium), Java или Flash Player — сейчас это уже не так страшно, а вот пару лет назад…
Если нет в оффициальной репе, будет в комьюнити, которая заслуживает доверия, как софтина, так и библиотеки нужные библиотеки. Сейчас даже быстрее чем для win все найдется.
Гентушники смотрят на вас со скепсисом. Достаточно не обновляться пару месяцев, чтобы выяснить, что мейнтейнерам захотелось сделать очередную перестановочку и разгребать конфликты придется вручную.За год общения была проблема только раз. Именно с Перлом, но из-за рассинхрона репозиториев, в течении суток решилась.
Разумеется, Gentoo — не для слабых духом, но все же не надо кривить душой говоря, что все проблемы в прошлом. А уж если и железо хоть немного нестандартное, то… что ни версия ядра — то какой-нибудь праздник. То mtp2sas отвалится, то ath9k просто перестанет работать потому что… потому что! То кернел-паник из-за l2tp.Не уверен, что я делал не так. Все работало отлично, ничего не слетало, до сих пор считаю Генту самым быстрым десктопом. Вот только сборка хромиума и еще пары пакетов, которая занимала несколько часов, — это меня пересилило. Ушел на Федору.
зы а вообще начинается линукс-срач
будет в комьюнити, которая заслуживает доверияЧем это в итоге-то отличается от установки софта в винде из «заслуживающих доверия» крупных репозиториев софта или от известных компаний?
Все работало отлично, ничего не слетало
У меня за последние 15 лет ни разу винда не слетала и, в целом, «все работало». У ребенка последние пять лет тоже была винда и линукс и тоже все как-то работало (потому что нет административных прав и не будет).
Но что в винде, что в линуксе, достаточно сделать лишь шаг в сторону от стандартных запросов и проблемы начинают сыпаться как из рога изобилия.
Например, уже упомянутая выше проблема с mtp2sas — я вот такой странный человек, что у меня на домашнем компьтере аппаратный RAID5. Ну там, знаете, надежность, производительность и вот это все. И для меня было сюрпризом, когда после очередного обновления init.d внезапно localmount стал запускаться до появления рейда в /dev. Решение было чудовищным — добавил sleep 15 и все заработало. А через пару месяцев так же тихо баг исправили.
Или вот актуальная проблема — есть китайская беспроводная мышка. Под иксами (любыми) она двигается с задержкой в полсекунды. Под виндой — работает нормально. Почему? Я не нашел решения.
Чтобы меня не обвиняли в однобокости припомню проблемы W10 и CH341 — популярнейшим китайским UART-чипом: первый год после выхода W10 драйвер для CH341 просто не работал и единственная рекомендация на форумах была «используйте W7». А как-то я захотел сделать нормальный мост на W10 Pro, с DHCP и роутингом. Промучавшись три дня, перелопатив тонны документации и перепробовав в том числе кучу стороннего софта я махнул рукой и за десять минут сделал то же самое на линуксовой машине. С другой стороны, я помню как мучился с L2TP (accel-ppp) — он насмерть вешал линуксовую машину время от времени…
В общем, я это к тому, что пока вам нужен от системы в основном браузер и видеопроигрыватель, то выбор OS в целом не принципиален — линукс тоже без особых усилий справляется с подобными задачами. Но когда дело доходит до специфических задач, то вылезают тысячи нюансов и проблем. Везде. И универсальных решений нет.
Чем это в итоге-то отличается от установки софта в винде из «заслуживающих доверия» крупных репозиториев софта или от известных компаний?Зависит от этих самых неизвестных производителей софта. Если они нормальные, то у них в винде инсталляция будет нормально происходить, в репе, типа rpmfusion, есть хоть какой-то контроль сообщества, и велика вероятность отбраковки корявого приложения. Но shit happens, ничего не поделаешь…
Но что в винде, что в линуксе, достаточно сделать лишь шаг в сторону от стандартных запросов и проблемы начинают сыпаться как из рога изобилия.В силу перечисленных sHaggY_caT причин, в винде сделать этот шаг проще. Если следуете минимальным правилам, не утанавливать подозрительный софт, не работать под рутом и т.д., везде будет хорошо.
И для меня было сюрпризом, когда после очередного обновления init.d внезапно localmount стал запускаться до появления рейда в /dev. Решение было чудовищным — добавил sleep 15 и все заработало.
chkconfig не пробовали прописать с нужными приоритетами на start/stop? Ну или depend() если был OpenRC.
В общем, я это к тому, что пока вам нужен от системы в основном браузер и видеопроигрыватель, то выбор OS в целом не принципиален — линукс тоже без особых усилий справляется с подобными задачами. Но когда дело доходит до специфических задач, то вылезают тысячи нюансов и проблем.
И универсальных решений нет.
Все хорошо везде, пока не нужно строить костыли. И это, в принципе, относится к обоим. Я не могу быть категоричным в этом вопросе. Меня полностью устраивает Linux для работы, у меня нет никаких проблем ни в играх(кроме отсутствия нормально видео карты) ни с проигрыванием media. Windows, еще отлична для enterprise и замены пока особо не видно, хотя я знаком с компанией, которая имеет пару тысяч продуктовых магазинов и использует SUSE, к сожалению уже не помню какую версию версию точно, открытую или enterprise.
Гхм, я все же возражу насчет игр, поскольку игры и продукты Adobe для меня являются основной причиной использовать Windows.
Все-таки Wine кое-как работает с DX9, но не с DX11/12/Vulkan. Портированные же на Linux игры зачастую работают хуже, чем под Вайном да и не так уж их и много. У меня большие надежды на gpu passthrough в будущем, но конкретно на моей конфигурации железа он не работает.
Все-таки Wine кое-как работает с DX9, но не с DX11/12/Vulkan. Портированные же на Linux игры зачастую работают хуже, чем под Вайном да и не так уж их и много. У меня большие надежды на gpu passthrough в будущем, но конкретно на моей конфигурации железа он не работает.
Вводишь в любом поисковике ключевую фразу «XXXXX errata», где XXXXX — название любого процессора (включая всякие микроконтроллеры).
И узнаешь много интересного про устройство XXXXX.
И узнаешь много интересного про устройство XXXXX.
После всего утекшего от АНБ не исключено, что это просто закладка.
А как обстоят дела в BSD системах? Нужен ли им аналогичный патч?
Сложилось впечатление что BSD уже работали в том режиме, на который сейчас котят пропатчить Linux и Windows. Или я все-таки перепутал операционки? Ведь точно уже есть такая для которой патч не требуется.
В некоторых источниках пишут что баг архитектурный — в упреждающем выполнении кода без каких-либо проверок
Стойте, вы про т.н. спекулятивное выполнение, когда выполняются обе ветви if, параллельно, а потом отбрасывается ненужная? И если такая проверка — это if процес_имеет_доступ_к_памяти { читать_из_памяти } else { поднять_исключение }, то мы сможем прочитать из любой памяти (тут важный нюанс, очевидно, интеловские процы спекулятивно прочитанные таким образом данные не стирают и мы можем получить к ним доступ). Кстати, записать в память таким образом не получится, потому что запись в память вызывает сброс конвейера и спекулятивное выполнение не происходит (что соответствует этой дыре — память ядра можно только читать).
Там спекулятивный выполнятор запрашивает кусок доступной юзерспейсу памяти в L1-кэш в зависимости от результата выполнения инструкции, породившей исключение доступа. А наличие памяти в L1-кэше легко проверяется по задержкам доступа. Такие дела.
Точные детали уязвимости неизвестны, но на основе обсуждения патча «Do not enable PTI on AMD processors» (https://lkml.org/lkml/2017/12/27/2) предполагают, что речь именно о спекулятивном выполнении. Оно явно упоминается в обсуждении того, что процессоры AMD не подвержены уязвимости.
Позапускал код, приведенный в конце spectreattack.com/spectre.pdf. На начальном этапе код заставляет процессор загрузить в кэш один из 256 кусков памяти, в зависимости от значения байта. Затем проверяется время доступа ко всем 256 кускам, и номер куска, который считывается быстрее остальных, и является искомым значением.
Теоретически, подобные уязвимости могут быть и в «спец. процессорах, которые ну уж совсем точно без закладок» (нувыпонели) или, например, в асиках?
BSD не подвержена, насколько видно в релизах патчей
Ан нет, врали патчи
lists.freebsd.org/pipermail/freebsd-security/2018-January/009651.html
lists.freebsd.org/pipermail/freebsd-security/2018-January/009651.html
Может быть эта ошибка даст повод руководству intel хотя бы задуматься о возвращении к двухгодичному релиз циклу.
Во времена когда все, даже Java, переходят на суть ли не полугодичный? Intel уже замедлились в том плане, что от схемы tic-tac перешли на tic-tac-tac.
Ты путаешь твёрдое с мягким. ;)
Формально релизный цикл уменьшился в два раза, фактически увеличился в полтора. Ведь внутри одного поколения они почти ничего не меняют.
Вот это «почти ничего не меняют» и является основным источником ошибок.
Последние громкие ошибки существовали годами вроде, нет? Что вот эта дыра (особенно spectre, которой подвержен даже AMD), что дыра в IME. как ни странно, но возникли они как раз не во время оптимизации (которая происходит на tack), а во время создания новой архитектуры (tick).
Но их не нашли, потому что «зачем всё проверять, мы же совсем чуть-чуть поменяли, если что в следующем процессоре исправим, через год же всего выходит»
Их не нашли потому что это невозможно сделать целенаправленно. Так же как ты не можешь найти все баги в софте (начиная с какого-то уровня сложности) даже если целиком его писал сам — всё предусмотреть невозможно. А процессоры, так же как и софт, делаются не одним человеком, а большими командами. Я думаю, что в Intel серьёзно относятся к безопасности и надёжности (на этом месте можно спросить у @shipilev, он там рядом варился) и гонка за скоростью ради качества, думаю, достаточно ограничена.
Всё можно проверить на 100% и отладить до конца. Вопрос времени. Но возвращаюсь к моему первому ответу: софт можно легко исправить, поэтому на тестировании экономят, железо — нет, но почему-то на тестировании тоже экономят.
Всё можно проверить на 100% и отладить до конца.Не все и не всегда, и тем более в очень сложных системах.
Всегда найдется человек более умный или изобретательный и придумает тест-кейс, который еще не внедрили, что и сделали исследователи нашедшие данную уязвимость.
«Целое больше, чем сумма его частей»
Вы можете отладить часть системы, каждую отдельную часть системы, систему целиком, систему с некоторой внешней средой, но в итоге проверить абсолютно все вы не сможете. И даже если сможете, всегда будут незадокументированные и неочевидные взаимодействия. Это бессмысленно. Баги есть, будут всегда и их не искоренить. Можно лишь оставить те, вероятность обнаружения которых довольно низка.
Вы можете отладить часть системы, каждую отдельную часть системы, систему целиком, систему с некоторой внешней средой, но в итоге проверить абсолютно все вы не сможете. И даже если сможете, всегда будут незадокументированные и неочевидные взаимодействия. Это бессмысленно. Баги есть, будут всегда и их не искоренить. Можно лишь оставить те, вероятность обнаружения которых довольно низка.
Железо обычно правится исправлениями микрокода (и интел регулярно выпускает обновления). А вот тут вот такое вот что не повезло. Гипотетически ты прав — проверить можно вообще всё. Надо просто прогнать все возможные комбинации параметров и комбинации комбинаций. То есть запустить весь возможный софт в случае процессоров. Но это настолько долго и дорого, что легче называть это «невозможно».
Это не просто слишком дорого. Если взять все возможные комбинации входных параметров и проверить что нигде ничего не ломается (что само по себе не просто и неизвестно возможно ли, но пусть будет возможно), то я сильно подозреваю что с текущими вычислительными мощностями тепловая смерть вселенной наступит раньше. Так что это реально невозможно практически.
Вам не кажется что вы другими словами повторили то, что написал я? :)
Всего возможного софта пока что не написано, так что на настоящий момент такая проверка невозможна.
Однако то что сказал я показывает фальсифицируемость гипотезы о том, что можно проверить что-то на предмет 100%-надёжности, что в общем-то делает эту гипотезу как минимум наукообразной :)
Всего возможного софта пока что не написано, так что на настоящий момент такая проверка невозможна.
Однако то что сказал я показывает фальсифицируемость гипотезы о том, что можно проверить что-то на предмет 100%-надёжности, что в общем-то делает эту гипотезу как минимум наукообразной :)
Мда… Десять! Десять маза фака лет нас могли поиметь по железу и скорее всего имели и вдруг, совершенно неожиданно, заметили что что-то не так.
К счастью, последние модели процессоров Intel с технологией PCID (идентификаторы контекста процесса), возможно, позволяют уменьшить падение производительности
Устав бороться за прирост производительности новых процессоров, решили понизить производительность старых?
Или кто-то вскрыл аппаратный бэкдор специально заложенный производителем а-ля Intel Management Engine? Кстати, то что уязвимы модели процессоров за последние 10 лет, неплохо коррелирует с внедрением IME.
ИМХО есть еще один вариант — так Интел хочет увеличить отрыв будущих процессоров(которые только разрабатываются) от текущих поколений. Что бы стимулировать переходить на новые модели. Не секрет что вот уже лет 7 мы имеем очень малый прирост быстродействия у Интел. Поэтому покупатели не торопятся обновляться.
Хотя это больше касается десктопного сегмента, а тут под угрозой больше серверные системы.
Хотя это больше касается десктопного сегмента, а тут под угрозой больше серверные системы.
Уязвимость то реальная (после публикации всей информации её сможет проверить любой желающий) и появилась не меньше чем лет 10 назад. Едва ли кто-то будет планировать такую многоходовочку «заложим уязвимость сейчас, а потом через 10 лет сольём её, чтобы выпустить процессоры без неё и поднять продажи»:
Во-первых, уязвимость могут найти раньше времени. Во-вторых, до выхода новых процессоров велик риск, что покупатели уйдут к конкурентам, у которых этой уязвимости нет. В ближайшее время от этой новости может выиграть только AMD.
Во-первых, уязвимость могут найти раньше времени. Во-вторых, до выхода новых процессоров велик риск, что покупатели уйдут к конкурентам, у которых этой уязвимости нет. В ближайшее время от этой новости может выиграть только AMD.
Прошло только 3 дня нового, 2018 года и… какие замечательные новости!
Причём самое печальное не то, что косяк нашли. Косяков не делает тот, кто ничего не делает вообще. Печально то, что наверняка об этом косяке кое-кому было хорошо известно какое-то время, но, по вполне понятным причинам, особо это никто не стремился исправлять.
Мало технодробностей. Как нашли, как именно эксплуатируется, какое железо затронуто?
Может это всё этот… заговор? ) Интел решил массово всех подтолкнуть к будущим апгрейдам железа в котором этих косяков нетно есть другие.
Причём самое печальное не то, что косяк нашли. Косяков не делает тот, кто ничего не делает вообще. Печально то, что наверняка об этом косяке кое-кому было хорошо известно какое-то время, но, по вполне понятным причинам, особо это никто не стремился исправлять.
Мало технодробностей. Как нашли, как именно эксплуатируется, какое железо затронуто?
Может это всё этот… заговор? ) Интел решил массово всех подтолкнуть к будущим апгрейдам железа в котором этих косяков нет
Первая публикация "по мотивам" была 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 @dgruss
[paranoic mode on] Может, это под впечатлением от Black mirror s4ep05, но почему мне кажется, что подобный подход — обмен надежности на удобства — может плохо кончится? Сколько еще таких дыр в железе и софте, которые напиханы или будут напиханы в ближайшем будущем в боевых роботов, в системы жизнеобеспечения, в коммуналку и в кучу других вещей, на которые опирается нынешняя цивилизация? [paranoic mode off]
Но ведь это наоборот обмен удобства на надёжность.
«Приятная» новость для линуксоидов —
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.— если у вас АМД, вам всё равно впаривают этот патч.
А логичнее было бы при загрузке определять модель процессора (это в любом случае делается, потому что в ядре есть куча других work-around для других багов) и применять опцию (раз её можно менять параметром ядра — значит поведение можно менять без перекомпиляции) только если процессор от Intel. Хардкодить в конфигах параметры, которые легко и быстро определять при загрузке — плохой путь. Процессор может и смениться (если это, например, LiveUSB) между перезагрузками.
Насколько понимаю, ответственные решили так не маньячить и упростить все для АМД:
patchwork.kernel.org/patch/10133447
В сущности, там проверка типа «для всех 86» заменяется на «для всех Интелов».
patchwork.kernel.org/patch/10133447
В сущности, там проверка типа «для всех 86» заменяется на «для всех Интелов».
Судя по этому патчу, в исправленных версиях ядра будут проверять на AMD
Ох, жестоко (
Судя по патчу, добавляется защита на доступ из юзерспейса(ring 3) — видимо TLB кеш позволяет заглянуть куда не следует. Так что баг касается и домашних компьютеров, но судя по тексту статьи позволяет еще и добраться до гипервизора.
Пока нет подробностей можно надеяться на лучшее и эта «фича» не будет работать например при выключенной виртуализации(хотябы «домашние» компы не просядут).
Пока нет подробностей можно надеяться на лучшее и эта «фича» не будет работать например при выключенной виртуализации(хотябы «домашние» компы не просядут).
Уже давно на хабре была статья про то, как из JavaScript определить где физически размещены данные. Если при выделении памяти, всегда затирать её нулями, то вроде бы такая уязвимость не так и страшна.
Если же аппаратная ошибка в механизме виртуальной памяти, то единственный вариант защиты — это интерпретация машинного кода. В этом случае падение скорости на 30% это минимум.
Если погуглить фразу «KAISER patches», то там говорится о "...KAISER, a kernel isolation technique to close hardware side channels on kernel address information.", то есть рандомизация размещения в памяти.
Замедлять компьютеры на процессорах AMD это конечно интересное решение Линуса Торвальдса.
Если же аппаратная ошибка в механизме виртуальной памяти, то единственный вариант защиты — это интерпретация машинного кода. В этом случае падение скорости на 30% это минимум.
Если погуглить фразу «KAISER patches», то там говорится о "...KAISER, a kernel isolation technique to close hardware side channels on kernel address information.", то есть рандомизация размещения в памяти.
Замедлять компьютеры на процессорах AMD это конечно интересное решение Линуса Торвальдса.
А можно пруф?
Иначе зачем например openssl при освобождении забивает еёнулями рандомными значениями? Как раз чтобы другому процессу ОС случайно не отдала блок с важными данными. Да и в Windows неспроста присутствует функция RtlSecureZeroMemory.
Иначе зачем например openssl при освобождении забивает её
Возможно, зависит от языка программирования, но менеджер памяти ничего сам не затирает, т.к. на это тратится время. Далее говорю только за С/С++.
Проверяли вы, скорее всего, в debug-режиме, а в нём как раз затирается, для удобства отладки. А в релизе ничего не затирается ни при выделении памяти, ни при освобождении. Поэтому, при необходимости, обнуление выполняется вручную, но оптимизирующий компилятор может эти затиранния удалить, если не считает их важными для работы алгоритма. Выше уже написали о функции RtlSecureZeroMemory, которую компилятору не разрешается удалять, как раз для того, чтобы гарантировано обнулить память.
Проверяли вы, скорее всего, в debug-режиме, а в нём как раз затирается, для удобства отладки. А в релизе ничего не затирается ни при выделении памяти, ни при освобождении. Поэтому, при необходимости, обнуление выполняется вручную, но оптимизирующий компилятор может эти затиранния удалить, если не считает их важными для работы алгоритма. Выше уже написали о функции RtlSecureZeroMemory, которую компилятору не разрешается удалять, как раз для того, чтобы гарантировано обнулить память.
В принципе, не важно, в каком виде память получается при выделении. Важно, в каком виде память остаётся после использования. Если после удаления объекта память не была обнулена/заполнена мусором, то достаточно вызова ReadProcessMemory, чтобы прочитать данные, которые в блоке памяти были записаны. Как я понял, из-за ошибки не проверяется, есть ли право чтения памяти по указанному адресу, поэтому можно прочитать любой блок памяти, даже тот, которым пользуется ядро. В нормальной ситуации был бы сегментфолт или другое исключение, но не в этот раз.
венда обнуляет память, которую ей возвращают проги. (может и при выделении, если специально попросят, например HEAP_ZERO_MEMORY). но когда Си-шная прога вызывает free(), этот кусок памяти не обязательно сразу отдается венде.
размер обнуленных страниц памяти показывает process explorer.
размер обнуленных страниц памяти показывает process explorer.
Хотя поискал, действительно начиная с Windows Vista(?) выделенные страницы обнулены.
Вызываю функцию HeapAlloc без флага HEAP_ZERO_MEMORY, страницы тоже будут обнулены?
Память будет обнулённой при вызове HeapCreate.
Это при условии, что мы заранее указываем размер создаваемой кучи. А если не указывать, то куча куча может расти, и каждое выделение памяти из неё не будет обнуляться.
Только что проверил. Вызвал функцию HeapAlloc без флага HEAP_ZERO_MEMORY, выделив 154000 байт. Получил не нули, а мусор. Я туда не записывал, только читал. Что это за данные? Эти данные от предыдущих программ? То есть это могут быть логины и пароли?
1. Скомпилировал без библиотек времени выполнения, получил файл 2048 байт.
2. Создал кучу с нуля через HeapCreate. Там не могут быть данные библиотек времени выполнения.
3. «Структуры самой кучи» — разве не должны быть защищены от записи? А то нарушу их, записав туда что‐нибудь, а потом система покажет крах.
Там всё равно какие‐то данные, а не нули.
2. Создал кучу с нуля через HeapCreate. Там не могут быть данные библиотек времени выполнения.
3. «Структуры самой кучи» — разве не должны быть защищены от записи? А то нарушу их, записав туда что‐нибудь, а потом система покажет крах.
Там всё равно какие‐то данные, а не нули.
Выложил сюда исходники и скомпилированный файл
www.freebasic.su/res/Heap.zip
Компилятор: FreeBASIC 1.0.5 версии.
make.cmd компилирует в 32‐битный файл, make64.cmd — в 64‐битный.
В файле компиляции поправить путь к компилятору, если не установлен в %ProgramFiles%.
www.freebasic.su/res/Heap.zip
Компилятор: FreeBASIC 1.0.5 версии.
make.cmd компилирует в 32‐битный файл, make64.cmd — в 64‐битный.
В файле компиляции поправить путь к компилятору, если не установлен в %ProgramFiles%.
Система выделяет память пользовательскому процессу вызовом
VirtualAlloc[Ex].
malloc etc — это уже надстройка (система кучи) со своими правилами, которые тоже нужно понимать.
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 — это уже надстройка (система кучи) со своими правилами, которые тоже нужно понимать.
Не может ли эта уязвимость быть связана с IME — ведь ей как раз десяток лет?
Это могло бы объяснить, почему она так долго оставалась незамеченной…
Это могло бы объяснить, почему она так долго оставалась незамеченной…
А 29 ноября CEO Intel слил все свои акции.
Совпадение?
Совпадение?
А я еще сомневался брать ли Threadripper. -30% к производительности на процессорах Intel это однозначное да.
Желаю потерять им побольше процентов рынка в пользу AMD
— Как продавать больше новых процессоров?
— Давайте дискредитируем все старые за последние 10 лет!
— Ты чудовище! Какое хочешь повышение?
— Давайте дискредитируем все старые за последние 10 лет!
— Ты чудовище! Какое хочешь повышение?
А макось уязвима? В громком названии её не вижу. Это просто потому, что они пока никак не отреагировали, или они-таки не подвержены в силу тех или иных причин?
Это не идеальное решение проблемы, но грядущие патчи для Windows, Linux и macOS будут использовать именно этот подход.
Да, но в названии числятся только две операционки. И название-то, шокирующее и наводящее на определённые размыщления. ТС писал с Мака? :)
Просто уязвимость мака — это несерьезно. Винда — огромный процент в юзер-сегменте, Линукс — серверный, а Мак — игрушка с грошами на фоне остальных цифр.
macOS пропатчили еще в декабре, насколько я понимаю support.apple.com/en-us/HT208331
некоторые подробности всё-таки выплыли наружу благодаря Python Sweetness и The Register
Странно, а по первой ссылке слово «Intel» вообще не упоминается, более того, написано «security bug impacting apparently all contemporary CPU architectures that implement virtual memory». Не трахнули ли несчастного журналиста ещё раз?
Объясните, пожалуйста, а если я ставлю патч сначала на хостовую машину, потом на виртуальную, я получаю падение производительности до 60%? Или на виртуальные машины оно так влиять не будет?
До 49%. Если уж следовать вашей логике.
30% — это среднее по больнице. На некоторых задачах можно и по-более отхватить, согласно Фороникс. А может и вовсе не увидите разницы, как мне кажется.
Нет, до 30% — это до 30%. В таком случае «среднее по больнице» — это 15%. Среднее между 30 и 0.
В исходном тексте не совсем корректные данные. В худшем случае падение более чем в два раза lwn.net/Articles/742522
А тем временеим CEO Intel за месяц до этого продал акций на 11 миллионов
www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
Тут другое интересно. Получается, в VPS эту штуку придётся держать включенной на каждой виртуалке? Гостевые OS с nokpi гонять не получится?
Зачем? Основная проблема-то — уязвимость хоста. Остальное всё-так ближе к проблемам клиента. Дальше всё зависит от ваших отношений с клиентами и обязательств перед ниим. Если их безопасность находится в сфере ваших интересов — тогда да, им тоже надо порекомендовать поставит патч.
Эм… Тут все крутые, но я скорее с позиции клиента рассматриваю. :) Раз уязвимость в процессоре, а виртуализация — аппаратная, то патч придётся ставить не только хостеру, но и на гостя. И держать его включенным. Получая, возможно, двойной штраф…
если виртуализация не полная, а что-то типа docker, то ядро общее
Тогда да, учитывая что клиентская виртуалка может словить малварь — конечно там тоже должна быть заплатка в большинстве случаев.
Двойного штрафа, насколько я понимаю, не будет — основное замедление из-за инвалидации процессорного кэша, а не из-за инструкций, которые эту инвалидацию делают. Могу ошибаться.
Интересно, двинет ли это рынок процессоров в объятия AMD?
Рынок б.у. процев — да.
Новых — не сильно. Увеличение количества новых процев произойдет не скоро (измеряется месяцами), т.к. заказы не так просто разместить. А Интел может уже через пару недель выкатит хардварный апдейт.
Новых — не сильно. Увеличение количества новых процев произойдет не скоро (измеряется месяцами), т.к. заказы не так просто разместить. А Интел может уже через пару недель выкатит хардварный апдейт.
Хардварный апдейт, КМК, потребует полной переработки масок. Я так понимаю, это не степпинг по мелочи поправить, это очень-очень дорого. Голосую за то, что восьмое поколение останется без апдейта, а если маски уже создали для девятого поколения, то не факт, что и оно его получит.
ящик пандоры открыт?
А не могли бы вы объяснить, что именно произошло на скриншоте? Первая команда — компиляция, понятно. Затем запуск бинарника, и?..
Как я понял при его участии в феврале была опубликована инфа про обход ASLR через js. Если верить публикации обход сработал на 22 разных процессорах, в атаке насколько я понял использовалось особенности работы кеша процессора и TLB, видимо капнул дальше.
Видимо началась новая эпоха замедлений. Эпл и Интел стали первопроходцами. Интересно, какие будут причины придумываться.
А вот интересно, а как насчёт судебных исков из-за падения производительности на 15%-30%?
Фольксваген за несчастный газовый тест на миллиарды засудили, а тут что? Забыть и простить?
Стандарты выполнимы. Иначе засудили бы не только VW. И засудили их за мошенничество.
Фольксваген за несчастный газовый тест на миллиарды засудили, а тут что? Забыть и простить?
Фольксваген нарушил интересы государства, а Интел — всего лишь интересы простых смертных. Увы, ничего им не будет.
Репутационные потери никто не отменял. Потери капитализации. Вообще, они всё грамотно делают, если что, всегда есть пункт под "*" о производительности.
Ну продажи могут просесть, цены придётся немного скидывать на старые поколения, если AMD не повысят.
Некоторые большие корпорации (и гос. компании/органы) могли поиметь из-за этого проблем (и не факт, что их не было). Сейчас, как минимум замедление виртуализации, а это некислый такой кусок бизнеса Intel и VPS площадок. Вообще, оправдатели AMD лукавят, протравливая свои «выстрелившие» удачные платформы.
Ну продажи могут просесть, цены придётся немного скидывать на старые поколения, если AMD не повысят.
Интел — всего лишь интересы простых смертных
Некоторые большие корпорации (и гос. компании/органы) могли поиметь из-за этого проблем (и не факт, что их не было). Сейчас, как минимум замедление виртуализации, а это некислый такой кусок бизнеса Intel и VPS площадок. Вообще, оправдатели AMD лукавят, протравливая свои «выстрелившие» удачные платформы.
новые серверные чипы EPYC от AMD, а также их десктопные процессоры Ryzen Pro имеют технологию шифрования защищённой памяти, дающую дополнительную защиту от атак подобного рода.а для других, как я понял всё это доступно, только уже
«Архитектура AMD не позволяет получить доступ к данным при отсутствии соответствующих привилегий»т.е. с соответствующими привилегиями не факт, что невозможно.
т.е. с соответствующими привилегиями не факт, что невозможно.А почему поток с соответствующими привилегиями не должен иметь доступа к данным?
Да, это я понимаю. Если человек работает под root/админской учёткой или процесс запускается с повышенными правами, или использует другую уязвимость, повышающую права, то проц AMD не обезопасит от этого. Хотя, если уж всё так, то тогда конкретно эта дырка будет уже не нужна. Т.е., допустим, многие сервера работают под рутом, многие виртуалки так же. И всё. Просто как бы не началась истерия — интел говно, покупайте AMD, они неуязвимы. «И вирусов там нет» (с).
это не уязвимость, это цру попросило сделать, а инфа утекла или ктото случайно нашел эту дыру
инфа 146% ?
Ну достаточно почитать wikiliks, чтобы понять, что они активно сотрудничают как с производителями (в том числе материнских плат, процессоров, жёстких дисков), так и с хакерами, выкупая 0-day раньше всех.
Так что по сути неважно, по их ли инициативе это появилось или вследствии ошибки, важно то, что они этим как минимум пользовались с ноября, а возможно и годами раньше.
Так что по сути неважно, по их ли инициативе это появилось или вследствии ошибки, важно то, что они этим как минимум пользовались с ноября, а возможно и годами раньше.
В АМД такого нет. Так что похоже на то, что ЦРУ ничего не просила, похоже на оптимизацию из разряда предкалькуляции. Видимо весь прогресс Интела на этой баге и висел.
«чистая» производительность без сисколов падать не будет, те интел в производительности на ядро все равно быстрей и баг тут не причем.
в АМД нет или еще не нашли? почему вы думаете что дыры должны быть в одном месте? (кривая ухмылка)
к тому же бага в каком наборе инструкций? если это интел-специфик то в амд его и не будет
к тому же бага в каком наборе инструкций? если это интел-специфик то в амд его и не будет
Минуточку:
Зачем это делать если об уязвимости АМД процессоров ничего не известно?
P.S сижу на AMD a10
Также сообщается, что патч для Linux будет по умолчанию включать kpti и на компьютерах с процессорами AMD, вызывая соответствующее падение производительности.
Зачем это делать если об уязвимости АМД процессоров ничего не известно?
P.S сижу на AMD a10
Представитель 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);
to funnybanana:
то было первое решение «лишь бы залатать». уже принят новый патч patchwork.kernel.org/patch/10133447
//промахнулся немного веткой…
то было первое решение «лишь бы залатать». уже принят новый патч patchwork.kernel.org/patch/10133447
//промахнулся немного веткой…
Уже фигурируют страшные цифры -63% twitter.com/grsecurity/status/948170302286172160
Пока что в единственно показанном PoC на скриншоте в твиттере видно чтение, а что с записью? Ведь если запись недоступна, то все не так страшно?
Пишут, что postgresql с этим фиксом проваливается на 17-23%. Жесть, конечно.
Пруф: www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3.anarazel.de
Пруф: www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3.anarazel.de
Note 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.
Все-таки хочется посмотреть насколько все плохо на реальных БД: там очень многое зависит от производительности диска и сети.
Только блин купил мать под 8е поколение.
Теперь остаётся ждать хардварной заплатки, либо снижения цен на старшие модели процессоров.
Теперь остаётся ждать хардварной заплатки, либо снижения цен на старшие модели процессоров.
Google считает что AMD тоже
security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel
Похоже, что в Intel спохватились и дали ответ в обход снятия эмбарго. Но он какой-то невнятный: «Баг — не баг, а эксплоиты не corrupt, modify or delete data». А то, что из юзерспейса можно почитать kernelspace — это по их мнению не critical.
да мелочь то какая, прочитать ssh ключи соседней машины. Правда, где тут критичность
из своего юзерспейса в соседний не пролезешь, только в гипервизор, но иногда и этого достаточно
ошибся, можно пролезть: с точки зрения бажного cpu — все равно, какие данные использовать для спекулятивного исполнения в предсказателе переходов — память ядра или память соседнего процесса
А как текущий процесс попадёт в память соседнего процесса, если в таблице страниц памяти сидит только память текущего процесса и ядра?
Может! Например, в Линуксе для удобства в память ядра отображена вся физическая память. А одна из разновидностей уязвимости атакует через данные предсказания веток, чтобы другой процесс при исполнении работает за другое время — а это и замеряется, атака по сайд-каналу же.
в Линуксе для удобства в память ядра отображена вся физическая память
А если ее больше, чем address space за вычетом служебных зон? Скажем, 4 гига на 32 битной платформе?
А если память соседнего процесса выгружена к своп?
Видимо, это касается только 64-битных систем, где нет никакой проблемы отобразить всю физическую память в логическое адресное пространство.
А если память соседнего процесса выгружена к своп?
Наверное, зависит от того, происходит ли page fault с подгрузкой страницы в память при спекулятивном выполнении команд.
На 32битных системах мапят, как я знаю, отрезок, сколько влезет. Его постоянно переключать не очень удобно, вот на 64 битах и решили мапать всё.
Этот текст писали юристы с определенной целью. Было бы странно оценивать его с технической точки зрения.
Владельцам гипервизоров остаётся страдать и плакать.
meltdownattack.com — еще детали и публикации исследований.
twitter.com/brainsmoke/status/948561799875502080
Насколько я понял, кому-то удалось успешно провести атаку на практике. Так что «NOT OBSERVED ACTIVE DEPLOYMENT» — это временно.
Насколько я понял, кому-то удалось успешно провести атаку на практике. Так что «NOT OBSERVED ACTIVE DEPLOYMENT» — это временно.
Уже выложили https://spectreattack.com/spectre.pdf
Как я понял это баг не совсем в конкретной реализации, а в самой идее предсказания ветвлений и предварительной подготовки к выполнению будущих инструкций, считая чтение операцией, не меняющей состояние (а она давно не такая из-за кеща). Если там всё по-честному проверять — предсказание ветвлений будет иметь гораздо меньше смысла. Если нет — получается вот такой read-only доступ куда не следует.
И эти заплатки с изоляцией системной памяти от чего-то защитят, но всё равно могут оставить дыру в эксплуатации особенностей исполнения ядерного кода (в нём то ядерная память доступна и могут непреднамеренно быть конструкции, использующиеся в эксплойте с входными данными от юзера — когда его писали никто про такое не думал, да и даже зная о такой "особенности" сложно это предусмотреть везде).
Но не всё так плохо. Получить доступ на чтение к ядерной памяти тут относительно легко, а вот к памяти соседнего процесса — намного сложнее, если вообще возможно (как описанным в статье способом так и тем вторым, что останется после этих заплаток). А важные данные типа паролей/ключей хранятся как раз обычно в памяти процессов, а не в ядре.
А, упустил деталь
тут 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-бит проце.
На 32-битном ядре почти гигабайт физической памяти замаплен точно так же. И нет, это не нововведение.
Ну, гигабайт — далеко не вся память. И опять же это может зависеть от ОС. Замапленная память ядра — понятно зачем нужно, чтобы не переключать карту памяти для большинства системных вызовов, и если её убрать — действительно понизится быстродействие. И поэтому скорее всего так будет сделано по умолчанию во всех вменяемых современных ОС (до того, как привлекли внимание к обсуждаемой особености процов). Замапаленная просто рандомная (или вообще вся) физическая память — просто небольшое удобство и на быстродействие почти не влияет.
Azure уже написал и обновляет виртуалки: 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.
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.
Интересно, можно как-нибудь сделать чтобы root процессы в host машине не тормозились этим патчем. Ибо руту всё равно можно всё и нечего его ограничивать. Тогда хоть будет возможность запустить какие-то тяжёлые задачи под рутом, что лучше чем ничего.
А что делать владельцам старых линуксовых ядер?) Будут ли бэкпорты в 3.x ветки?
Версий процессоров без уязвимости нужно будет ждать пару лет?
Бери АМД
googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html?m=1
АМД тоже подвержен этой уязвимости ( Spectre )
АМД тоже подвержен этой уязвимости ( Spectre )
Исходя из заголовка речь идет об уязвимости Meltdown, устранение которой программно как раз и снижает производительность, а ей процессоры AMD не подвержены.
В случае со Spectre, которая касается всех процессоров, то ее снижающий производительность KPTI не устраняет. Над вариантами решения проблемы данной уязвимости работа все еще идёт и не ясно чем все закончится.
В случае со Spectre, которая касается всех процессоров, то ее снижающий производительность KPTI не устраняет. Над вариантами решения проблемы данной уязвимости работа все еще идёт и не ясно чем все закончится.
По вашей логиге, возможность намеренного повреждения шланга к вакуумному усилителю тормозов авто — это брак, и все машины должны быть отозваны.
Скорее это наличие в машине центрального замка, сигнализации, бронестекла, видеорегистратора и при это форточки для проветривания которая никак не закрывается и находится в мёртвой зоне камеры.
Без действия третьей стороны все работает и нет никаких проблем. Функциональность не снижается, повреждений данных нет. Вы же работаете с продуктом по тех.документации.
Атака — это действие третьей стороны, которое описать или предугадать невозможно.
Атака — это действие третьей стороны, которое описать или предугадать невозможно.
Я купил меганавороченную систему безопасности, однако она открывается зубочисткой. Но взлом системы безопасности — это действие третьей стороны. поэтому все нормально. Так что ли?
Это таки брак — как минимум в том месте, где костыль жрет производительность (и не важно, 1% или 50%). Ну и это слишком опасный прецедент, чтобы оставлять корпорации безнаказанными — завтра они выпустят еще какое-нить баганутое поделие, а потом еще и еще — потому что ответственности ноль.
Это таки брак — как минимум в том месте, где костыль жрет производительность (и не важно, 1% или 50%). Ну и это слишком опасный прецедент, чтобы оставлять корпорации безнаказанными — завтра они выпустят еще какое-нить баганутое поделие, а потом еще и еще — потому что ответственности ноль.
Еще раз.
Вы не купили систему безопасности. Вы купили вычислительный модуль, который производит для вас вычисления. И в данном случае, проблем с этим нет — никаких, все вычисления он проводит в штатном режиме и его функциональность не нарушена. Обнаружили уязвимость в изоляции памяти ядра, но это проблема решается одной переменной в конфиге ядра линукса, к примеру. Где тут брак? Вы просто расплатитесь производительностью за безопасность своих личных или бизнес данных. И поверьте, на том же azure, aws, gcp крутятся сервисы компаний, для которых падение производительности на 5% исчисляться восьмизначными суммами долларов в год.
Возвращаясь к автомобилям. Вы купили автомобиль, у него есть замок и ключ и какой-никакой иммобилайзер, но вы ставите дополнительную сигнальную систему, на которую нужно потратить деньги и которая добавляет точек отказа системы.
Вы не купили систему безопасности. Вы купили вычислительный модуль, который производит для вас вычисления. И в данном случае, проблем с этим нет — никаких, все вычисления он проводит в штатном режиме и его функциональность не нарушена. Обнаружили уязвимость в изоляции памяти ядра, но это проблема решается одной переменной в конфиге ядра линукса, к примеру. Где тут брак? Вы просто расплатитесь производительностью за безопасность своих личных или бизнес данных. И поверьте, на том же azure, aws, gcp крутятся сервисы компаний, для которых падение производительности на 5% исчисляться восьмизначными суммами долларов в год.
Возвращаясь к автомобилям. Вы купили автомобиль, у него есть замок и ключ и какой-никакой иммобилайзер, но вы ставите дополнительную сигнальную систему, на которую нужно потратить деньги и которая добавляет точек отказа системы.
Я не хочу расплачиваться своей производительностью за чужие баги. Я купил процессор с заявленными характеристиками ( в частности никто не заявлял. что он дырявый) и с заявленным быстродействием. И получил в итоге дыру и падение быстродействия, и мне еще говорят, что все нормально, так и должно быть.
«Перечитывал пейджер, много думал.»
Процессор не только уязвим, он в своем кэше так же портит данные!
Не в физической памяти конечно, а процесс может получить неверные данные.
2) Не обязательно таймер, можно просто хранить 1 число и сравнивать значения, это сработает для случаев кроме того, когда считываемое значение равно хранимому числу.
Процессор не только уязвим, он в своем кэше так же портит данные!
Не в физической памяти конечно, а процесс может получить неверные данные.
2) Не обязательно таймер, можно просто хранить 1 число и сравнивать значения, это сработает для случаев кроме того, когда считываемое значение равно хранимому числу.
Как вы не поймете, от багов никто не застрахован, и даже при улучшении методологий тестирования, с сегодняшними темпами усложнения систем и перехода на более высокие уровни абстракций при написании программных продуктов, тенденция в раскрытии критических уязвимостей подобно этой будет усиливаться. Это естественный процесс, которому тяжело, что-то противопоставить, всегда найдется более умный, смекалистый, с нестандартным мышлением, который сможет создать условия и окружение для компрометации данных. Это не всегда будет приводить к таким масштабным последствиям, но думаю, что данная уязвимость открыла новую эпоху и нас ждет еще много чего интересного. c'est la vie…
Смешно читать такие или около такие рассуждения ибо уязвимость то боянистая, лет шесть уже как модули на её основе имеются в продаже, пора бы и честь знать…
И это не баг, вот уж чего обывателю никак не понять!
Это новый контекст использования :-)
И дело не в умении и смекалистости, дело в постановке задач, которые у каждого свои.
И это не баг, вот уж чего обывателю никак не понять!
Это новый контекст использования :-)
И дело не в умении и смекалистости, дело в постановке задач, которые у каждого свои.
Ну так поделитесь ссылкой на аукцион, а мы посмотрим.
А то как-то выходит, что 6 лет эксплойт в свободной продаже, но при этом никто и не слыхал про него. Это как? Я еще понимаю, если его спецслужбы используют, но тогда о какой свободной продаже может идти речь. А если другая сторона использует, то мы бы наверное чаще читали новости об уведенных кошельках или потерянных через swift суммах.
Мне вот тяжело понять, какая была «постановка задачи», что он всплыл только сейчас…
А то как-то выходит, что 6 лет эксплойт в свободной продаже, но при этом никто и не слыхал про него. Это как? Я еще понимаю, если его спецслужбы используют, но тогда о какой свободной продаже может идти речь. А если другая сторона использует, то мы бы наверное чаще читали новости об уведенных кошельках или потерянных через swift суммах.
Мне вот тяжело понять, какая была «постановка задачи», что он всплыл только сейчас…
Интелу тоже за шесть лет было никак не понять? Ждали, пока на них ведро навоза выплеснут? А подумаешь, репутация, штрафы, рыночная доля, это же всё просто слова, да?
Если что, Интел отзывала процессоры по гораздо менее важной причине: ru.wikipedia.org/wiki/Ошибка_Pentium_FDIV
Не отзывала, а предлагала обмен всем желающим, ибо в реальности, эта проблема касалась очень узкого круга пользователей. Сколько конкретно пользователей воспользовались услугой замены — неизвестно. Заявленные потери Интел учитывали в основном маркетинговые проблемы, а не саму замену процессоров.
В данном же случае, проблема касается всех и каждого.
В данном же случае, проблема касается всех и каждого.
Где сказано что отзывала?
Они не будут их отзывать.
Это все процессоры, которые они успели выпустить.
Это все процессоры, которые они успели выпустить.
meltdownattack.com
Which 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).
Which 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.
Тут новость что придумывают патч, который не так сильно скажется на производительности www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Retpoline-Patches
Да в принципе, пока что логично поставить те патчи, что есть, а потом уже с спокойной душой дождаться новых патчей, которые не будут так сильно бить по производительности — пускай некоторое время посидишь с замедленным компом, зато за сохранность данных банковской карты можно не беспокоиться.
Это от spectre. А тормозит систему Meltdown. Сейчас их смешали в кучу, но это разные уязвимости, разные патчи и разные последствия.
Spectre не так страшен и от него уже и так есть защита (отключение/эмуляция таймеров, дополнительный уровень гипервизора, шлюзы и т.п.) — вопрос в том, какой путь лучше.
А с Meltdown все плохо — сброс кэша при перезагрузке таблиц страниц).
Кстати, есть мнение, что рекламируемая PCID совсем не панацея. Там тэги не для всех видов данных и все равно частично кэш сбрасывается.
MS Выложило вроде как апдейт
www.catalog.update.microsoft.com/Search.aspx?q=KB4056898 Windows 8.1
www.catalog.update.microsoft.com/Search.aspx?q=KB4056897 Windows 7
www.catalog.update.microsoft.com/Search.aspx?q=KB4056898 Windows 8.1
www.catalog.update.microsoft.com/Search.aspx?q=KB4056897 Windows 7
Установил обновления, уж не знаю оно это или нет, но никаких существенных отличий в работе не заметил.
- Обновления системы безопасности для графического компонента Microsoft, Windows Graphics, ядра Windows и сервера Windows SMB.
MS cкорее бы, так и написали, что обновление в связи с вышеуказанными уязвимостями, по примеру MS17-010. А это на вид, обычное обновление безопасности.
Так и есть. В смысле описания. Вот то самое обновление KB4056894. Это прилетело для Intel системы с дискреткой Nvidia. На ноут с AMD APU ничего ещё не прилетало.
Оба ноута на Win7x64
Оба ноута на Win7x64
предвижу массовые возвраты в магазины и коллективные иски, я вот не собираюсь копаться с патчами и терпень просадки производительности, компьютеру нет 6 месяцев, пусть intel выпускает официальный пресс релиз на основании которого организуют массовый отзыв процессоров, что делать с материнками под процессоры, которые все уязвимы тоже не понятно
А никто не думает что уязвимость была заложена в интересах третьей стороны? Не страдаю теориями заговоров, но вероятность имеется и слишком уж долго уязвимость оставалась ненайденной.
Если бы делали закладку, она была бы более юзабельной в плане поиска нужных данных.
Оставалась ненайденной, пока искать не начали. Да и слишком просто её использовать кому угодно после обнаружения, инфраструктура на процессорах интела не только в странах потенциального противника есть.
DirtyCOW тоже заложена в интересах третьей стороны?
Тогда уж процент от цены процессора, интел не отвечает за всю остальную мишуру на вашем ноуте.
Да-да… наверное ребята, проектировавшие клапан тоже так заявили «Несите клапан, поменяем! А с потерей самолета и родственниками пассажиров сами разбирайтесь!».
Так и производителей лобового стекла для этих Боингов можно обвинить в аварии. Не знали они, что ли, что перед установкой стекла нужно ознакомиться с полным описанием каждой детали самолета?
Нда, красота, прям в риалтайме…
Почему мы это читаем не в блоге интел? Серьезная же проблема.
блииииин!!!
Что-то я не пойму. Уязвимость нельзя закрыть обновлением микрокода — но будет патч, который уменьшит производительность. Надо патчить каждую программу(это из каментов) — но будет выпущено ядро с такой функцией. Это же все — взаимоисключающие утверждения.
Сначала обновляем антивирус, Windows Update проверяет флаг в реестре перед установкой чтобы не упасть в BSOD. Обновляемый статус антивирусных продуктов.
Затем устанавливаем обновление Windows, через Update или вручную.
Используем скрипт Powershell от Microsoft, убеждаемся что CVE-2017-5754(Meltdown) закрыт.
Обновляем браузеры, на Firefox утром прилетело обновление от Spectre.
Проверяем сайт производителя на наличие обновления BIOS, устанавливаем если оно есть.
Вновь запускаем скрипт от Майкрософта, убеждаемся что CVE-2017-5715 (Spectre) закрыт.
Nvidia написала об обновлениях драйверов для устранения этой уязвимости, пока непонятно, но стоит проверять и их сайт.
После этого можно слегка расслабиться.
Затем устанавливаем обновление Windows, через Update или вручную.
Используем скрипт Powershell от Microsoft, убеждаемся что CVE-2017-5754(Meltdown) закрыт.
Обновляем браузеры, на Firefox утром прилетело обновление от Spectre.
Проверяем сайт производителя на наличие обновления BIOS, устанавливаем если оно есть.
Вновь запускаем скрипт от Майкрософта, убеждаемся что CVE-2017-5715 (Spectre) закрыт.
Nvidia написала об обновлениях драйверов для устранения этой уязвимости, пока непонятно, но стоит проверять и их сайт.
После этого можно слегка расслабиться.
Хм. Так и Вы будете смеяться, но ещё в прошлом веке, Intel для по-настоящему защищённых операционных систем, а не всяких там Linux/Windows, реализовала «Time Stamp Disable (bit 2 of CR4)». Вероятно по заказу АНБ. Они что-то ещё тогда знали ;)
С тех появилось некоторое количество отладочных регистров и счётчиков производительности, но они тоже все отключаемые. А без них, ни meltdown, ни spectre, ни многое и многое иное, не пройдут ;)
Для замера времени без 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.
Для диванных экспертов сделали первые бенчмарки.
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 даже чуть повысился.
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 даже чуть повысился.
Это мало кому интересно. Основной рынок это сервера. И там все довольно плохо.
У меня на 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. Если интересно, могу показать вывод скрипта до патча, после патча и после отключения защиты.
Пробовал отключить защиту с помощью ключей регистра (требуется перезагрузка!), описанных в: https://support.microsoft.com/en-gb/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution. Защита (см. Powershell скрипт, указанный в конце указанной страницы), отключается, но быстродействие не восстанавливается :(
P.S. Если интересно, могу показать вывод скрипта до патча, после патча и после отключения защиты.
Я не диванные эксперты читали, в каких условиях падение ожидается и почему? Эти тесты никаким образом не касаются ожидаемого замедления, которое на реальном софте тестами уже подтвердили неоднократно.
Как я понял, замедляется только работа с syscalls.
В бенчмарках в моём комментарии видно проседание на процентов так 10, для реальности надо прибавить ещё само время работы серверов + сетевого стека.
Сам гугл так же выпустил статью про то, что много спекулятивных статей и на их серверах «незначительное» изменение производительности.
security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
В бенчмарках в моём комментарии видно проседание на процентов так 10, для реальности надо прибавить ещё само время работы серверов + сетевого стека.
Сам гугл так же выпустил статью про то, что много спекулятивных статей и на их серверах «незначительное» изменение производительности.
security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
Кажется, рано SPARC похоронили.
Как я понял это касается только датацентров, которые предоставляют доступ к виртуалкам? Так ведь это же замечательно, Xeon'ы E5 V3 скоро будут скидывать за бесценок!
Интересно, почему никто из диванных аналитиков до сих пор не предположил наличие связи между стремительным ростом альткойнов (на фоне стабилизировавшегося биткойна), существенная часть которых майнится на процессорах, и временем обнаружения/раскрытия дыры в процессорах, спешно сделанное исправление которой «на некоторых задачах» даёт потерю производительности до 30%?
Уязвимость в ЦП Intel: затронуты Windows и Linux, закрытие уязвимости приведёт к падению производительности до 30%