Раскрыта (http://openwall.com/lists/oss-security/2018/05/08/4) информация об уязвимости (https://everdox.net/popss.pdf) CVE-2018-8897 (https://security-tracker.debian.org/tracker/CVE-2018-8897), которая вызвана неверной интерпретацией описания поведения инструкций MOV SS/POP SS в документации и может привести к получению доступа к закрытым областям памяти, вызова отказа в обслуживании или повышения привилегий в системе. Проблема проявляется на 64-разрядных процессорах x86 (AMD и Intel) в большинстве операционных систем и гипервизоров, включая Linux, FreeBSD, Windows, macOS, Xen, KVM и VMware.
Причиной возникновения уязвимости является недостаточно ясная трактовка в официальной документации (https://software.intel.com/en-us/articles/intel-sdm) ("System Programming Guide of the Intel 64 and IA-32") поведения MOV SS/POP SS при возникновении отладочных исключений (#DB (https://xem.github.io/minix86/manual/intel-x86-and-64-manual.... На системах x86 стек представлен комбинацией из сегмента стека (SS) и указателя позиции в стеке (SP), которые всегда должны быть синхронизированы для корректного выполнения операций. Для блокирования рассинхронизации инструкции, выполняющие манипуляции с сегментом стека, содержат специальный обработчик для обеспечения согласованности с изменением указателя стека.
Разработчики полагали, что попадание инструкции MOV SS в точку останова приводит к генерации исключения #DB сразу после завершения MOV SS, но на деле исключение откладывается до границы следующей инструкции и вызывается только после выполнения инструкции, идущей следом за MOV SS. Если следом за MOV SS выполняется одна из инструкций, приводящих к переключению контекста и передаче управления операционной системе (SYSCALL, SYSENTER, INT $N, INT3, INTO), например, осуществляется системный вызов, то обработчик исключения #DB вызывается уже в контексте ядра, а не в контексте пользователя. Для решения проблемы в контексте ядра следовало очистить значение регистра DR6 (https://en.wikipedia.org/wiki/X86_debug_register#DR6_-_Debug... определить обработчик #DB в стиле обработчика NMI или подменить стек при помощи IST (Interrupt Stack Table).
Уязвимость позволяет непривилегированному пользователю инициировать ситуацию при которой можно получить контроль за указателем стека и указателем GSBASE в обработчике прерываний, вызванного в контексте ядра, что позволит получить доступ к структурам ядра и повлиять на ход выполнения низкоуровневых функций операционной системы (прототип эксплоита (https://marc.info/?l=linux-kernel&m=152580052406931) для Linux, вызывающего крах ядра). Например, атакующий может настроить отладочный регистр для срабатывания точки останова при доступе к данным в вершине стека, после чего выполнить инструкцию 'pop %ss; int 3'. Данная инструкция приведёт к возникновению исключения DB#, но оно будет вызвано только после выполнения 'int 3' и переходу в контекст ядра (исключение на адрес в пространстве пользователя возникнет в контексте ядра).
Работа по формированию обновлений для устранения уязвимости велась согласованно с назначением эмбарго, поэтому проблема была устранена в большинстве систем ещё до публичного анонса. Подверженность (https://www.kb.cert.org/vuls/id/631579) уязвимости различных систем:
- Linux: уязвимость может привести только к краху ядра, возможность атаки по повышению привилегий исключена (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-8897) (в Linux используется IST (https://www.kernel.org/doc/Documentation/x86/kernel-stacks), но один слот для #BP и #DB, что позволяет совершить DoS). Обновления пакетов с ядром выпущены для Debian (https://security-tracker.debian.org/tracker/CVE-2018-8897), RHEL (https://access.redhat.com/errata/RHSA-2018:1318), Fedora, openSUSE (https://lists.opensuse.org/opensuse-security-announce/2018-0... SUSE (https://www.suse.com/security/cve/CVE-2018-8897/) и Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2.... Исправления включены в свежие выпуски поддерживаемых веток ядра Linux (https://www.kernel.org/);- Системы виртуализации на базе KVM (CVE-2018-1087 (http://openwall.com/lists/oss-security/2018/05/08/5)): непривилегированный пользователь гостевой системы может использовать уязвимость для поднятия своих привилегий внутри гостевой системы (
прототип эксплоита (https://lkml.kernel.org/r/67e08b69817171da8026e0eb3af0214b06...- Гипервизор Xen (XSA-260 (http://seclists.org/oss-sec/2018/q2/91)): пользователь гостевой системы, работающей в режиме паравиртуализации (PV), может поднять свои привилегии до уровня гипервизора (ring0);
- FreeBSD (https://www.freebsd.org/security/advisories/FreeBSD-SA-18:06...: уязвимость устранена в ветках stable/11, 11.2-PRERELEASE, releng/11.1, 11.1-RELEASE-p10, stable/10, 10.4-STABLE, releng/10.4, 10.4-RELEASE-p9. В ходе атаки можно получить доступ к содержимому памяти ядра, потенциально поднять свои привилегии или вызвать крах ядра;
- DragonFly BSD (https://www.dragonflydigest.com/2018/05/09/21231.html): исправление уязвимости включено в ядро DragonFly_RELEASE_5_2;- Windows (https://portal.msrc.microsoft.com/en-US/security-guidance/ad...: уязвимость можно использовать для повышения привилегий и получения полного контроля за системой;
- macOS (https://support.apple.com/en-us/HT208742): локальный пользователь может поднять свои привилегии в системе и выполнить код с правами ядра;
- OpenBSD и NetBSD не подвержены уязвимости.Описание в документации Intel (https://software.intel.com/en-us/articles/intel-sdm), которое было неверно истолковано разработчиками:
URL: http://openwall.com/lists/oss-security/2018/05/08/4
Новость: https://www.opennet.ru/opennews/art.shtml?num=48569
> OpenBSD и NetBSD не подвержены уязвимости.Срочно в новости: авторы OpenBSD и NetBSD умеют читать!
Может очень ленивые в отличии от фронтендеров?
Еще в AMD умеют читать
> Еще в AMD умеют читать
>Проблема проявляется на 64-разрядных процессорах x86 (AMD и Intel)Разве?
AMD совместим с Intel. Все нормально.
Видимо, при реализации архитектуры AMD64 они, как ни странно,пользовались документацией от AMD....
> OpenBSD и NetBSD не подвержены уязвимости.А где ссылка на пруф?
Вот это номер...
Получается, что формальное следование формулярам приводит к опсным последствиям.
> Вот это номер...
> Получается, что формальное следование формулярам приводит к опсным последствиям.В RFC те же грабли, даже неточности в BGP.
почему ядро фрибсд даже менее защищено чем линукс?
потому, что их любимое занятие - патчить KDE #шутка
потому что обработка прерываний устроена по разному, линуксу случайно повезло.("зато я раком не болею..." в смысле, зато performance hit от наличия кода для pti у них околонулевой. [кода, а не самого pti] Тоже потому, что механизмы передачи управления ядру устроены совершенно иначе.)
> зато performance hit от наличия кода для pti у них околонулевойНет.
> механизмы передачи управления ядру устроены совершенно иначе
Нет.
> почему ядро фрибсд даже менее защищено чем линукс?Потому что нет никаких предпосылок для этого.
из занятного: joyent заявил что не подвержен проблеме (а значит и все, что illumos-based, тоже)
oracle жует сопли (то есть, вполне возможно что vbox уязвим, и патчей у них нет)
Дыры Intel SGX подоспели https://tches.iacr.org/index.php/TCHES/article/view/879
Привет Intel с его Asylo...
так погнал малеха.
А на x32 ОС эта проблема тоже будет ? или нужна x64 ОС, чтобы бага сработала ?
(Здесь ролик про Гитлера в бункере, который устраивает разнос разработчикам процов и доки)
> OpenBSD... не подверж... уязвимости.OpenBSD многие годы меня очень радует. Только для домашнего использования не всегда удобна и под рукой всегда держишь какой-нибудь Дебиан для узкоспециализированных задач.
Узкоспециализированных это каких? Смысл тогда держать 2 системы если постоянно нужны "узкоспециализированные" задачи?
Винда для узкоспециализирываных задач.
1)Нет нормального прикладного десктопного софта + мало пакетов в целом.
2)Иксы, на глаз видно, как медленней работают.
3)UFS работает гораздо медленней ext4.
4)Виртуализации все еще нет.
5)Апдейты каждые полгода вручную.
.. ит.п.Система простая и самобытная, но, увы!, на десктоп полноценный не тянет.
Сама система обновлялась бы с репов, а вся прикладуха типа flatpack или snap, было бы круто.
> а вся прикладуха типа flatpack или
> snap, было бы круто.Лучше не надо. А то куда мне валить, после того как у меня будет пол-системы в flatpack и занимать это дело будет гигов 100. Он же так и не научился шарить либы? Ну и накой он нужен?
Абсолютно согласен. Должны быть такие загончики, как OpenBSD, для любителей.
> Лучше не надо. А то куда мне валить, после того как у
> меня будет пол-системы в flatpack и занимать это дело будет гигов
> 100. Он же так и не научился шарить либы? Ну и накой он нужен?Чтобы показать что сделать МАЗДАЙ можно даже из OpenBSD. Его, в принципе, из чего угодно можно сделать - достаточно притащить over 9000 библиотек, за которые никто не отвечает. И получится маздай, даже если это формально и не винда.
> 1)Нет нормального прикладного десктопного софта + мало пакетов в целом.На вкус и цвет. MS Office и Adobe Photoshop не взлетят, это да.
> 2)Иксы, на глаз видно, как медленней работают.
Зависит от видеочипа. С NVIDIA точно будет плохо.
> 3)UFS работает гораздо медленней ext4.
Softupdates можно включить.
> 4)Виртуализации все еще нет.
/me с недоумением смотрит на то как в работающем под vmm(4) CentOS что-то собирает buildroot.
Хотя расти есть куда, конечно.
> 5)Апдейты каждые полгода вручную.
Механизм autoinstall позволяет делать это вообще ничего не предпринимая. Файлы ответов заботливо генерируются инсталлятором уже не первый релиз.
> .. ит.п.
> Система простая и самобытная, но, увы!, на десктоп полноценный не тянет.
> Сама система обновлялась бы с репов, а вся прикладуха типа flatpack или
> snap, было бы круто.Тогда это было бы не OpenBSD, где каждый узел чётко связан с другими, а трудносопровождаемая каша в модном духе devops.
Благодарю за адекватные ответы, серьезно.Видяха Intel, ноут 12 года. Читал, что Иксы патченые у них, мбыть из-за этого.
У Softupdates есть свои минусы, да и пишут, что в основном влияет на скорость создания\удаления файлов. Однако я наблюдал, что приложения стартуют гораздо медленней. В целом было видно, что производительность упала по сравнению с пингвином. Может, действительно, что-то можно было подркутить, но я не осилил.
По мне так лучше когда в репах только все системное. ОС это чугунная неубиваемая сковорода, а прикладуха, то что на ней жаришь. И здесь мне больше импанируют более контейнеры. Установил, не надо - снес, + не нужно ждать обновления в репах. Чтобы однажды установленная ОС работала до смерти железа и оставалась всегда возможность запускать свежую прикладуху.
Поэтому сижу на убунте ЛТС, свежий софт + 5 лет можно не париться с обновлением. Роллинг страдает тем, что может однажды прибить систему, ибо постоянно перелопачивается все и вся. Поэтому на рабочей машине он противопоказан.
Как обновить безопасно Опенка? Если умрет при апдейте, есть возможность откатиться?
> Благодарю за адекватные ответы, серьезно.
> Видяха Intel, ноут 12 года. Читал, что Иксы патченые у них, мбыть
> из-за этого.Тогда сложно сказать. Я на Intel'е по жизни сижу, тормоза отмечал только в каком-то из прошлых релизов. Но, может, это я уже просто привык. :)
> У Softupdates есть свои минусы, да и пишут, что в основном влияет
> на скорость создания\удаления файлов.Да. По сути, softupdates ускоряет процедуры, связанные с изменением метаданных ФС.
> Однако я наблюдал, что приложения стартуют гораздо медленней.
> В целом было видно, что производительность упала по сравнению с
> пингвином. Может, действительно, что-то можно было подркутить, но я не осилил.Скорее всего, это не ФС виновата, а ld.so: в OpenBSD он включает ряд ориентированных на повышение безопасности мер, которые действительно могут замедлять запуск приложений с большим количеством библиотек. Возможно, там есть простор для разумных оптимизаций, мне трудно сказать.
>[оверквотинг удален]
> чугунная неубиваемая сковорода, а прикладуха, то что на ней жаришь. И
> здесь мне больше импанируют более контейнеры. Установил, не надо - снес,
> + не нужно ждать обновления в репах. Чтобы однажды установленная ОС
> работала до смерти железа и оставалась всегда возможность запускать свежую прикладуху.
>
> Поэтому сижу на убунте ЛТС, свежий софт + 5 лет можно не
> париться с обновлением. Роллинг страдает тем, что может однажды прибить систему,
> ибо постоянно перелопачивается все и вся. Поэтому на рабочей машине он
> противопоказан.
> Как обновить безопасно Опенка?Я помню только один переезд, который был действительно серьёзным и требовал специальной процедуры — это когда time_t меняли на 64-битный. В остальных случаях штатный алгоритм не меняется уже много лет:
* обновили базовую систему инсталлятором;
* по необходимости подправили файлы в /etc (здесь помогает sysmerge: большую часть работы эта утилита делает сама, требуя внимания только при возникновении неустранимых конфликтов);
* прогнали pkg_add -u.Всё, система обновлена. Если делать всё это полностью вручную, то при наличии достаточно быстрого подключения к Сети и SSD на всё про всё на десктопе с кучей приложений уходит не больше 30 минут, из которых большую часть времени занимает скачивание и установка новых пакетов.
Также практически всегда гарантируется, что базовое окружение версии N будет достаточно работоспособно с ядром N+1, чтобы произвести обновление системы без инсталлятора. Но для десктопа это малоактуально, ИМХО, проще всё же прогнать инсталлятор.
> Если умрет при апдейте, есть возможность откатиться?
А почему он должен умереть? Здесь базовая система обновляется одномоментно, таким образом гарантируется её целостность. Если вдруг, скажем, вы обновились с 6.2 до 6.3 и ядро перестало загружаться (лучше ничего нафантазировать не смог), и UKC не помогает, то просто накатите поверх быстренько, не обновляя пакеты, обратно 6.2.
Пакетный менеджер работает сам по себе довольно надёжно, но главное — никогда не поставит систему раком. Просто потому что он не трогает базовую систему.
Я уже вижу как вы скептически хмыкаете. :) Могу лишь напоследок сказать, что одна из причин, за которые я не люблю Linux'ы, — это как раз ад с обновлением системы, так что... Просто попробуйте. Поставьте 6.2, установите на скорую руку набор любимых пакетов, поправьте какие-нибудь конфиги по вкусу, а затем обновите по штатному алгоритму (выше). Многих этот процесс приятно удивляет, если только отсутствие русификации вас не смущает. :)
Спасибо за инфу.Какие конкретно задачи вы решаете на Опенке и как давно?
Что еще используете и для чего?
> Спасибо за инфу.
> Какие конкретно задачи вы решаете на Опенке и как давно?Если не считать моего личного ноутбука, являющегося основным компом для всего подряд (от разработки до ютубных котиков) уже лет... уже почти пятнадцать?! — фигасе время-то жизни пролетело... Так вот, если не считать периодически меняющийся ноутбук, то на базе опёнка у меня в отделе разработки, где работаю большую часть времени, развёрнута большая часть инфраструктуры: Java-based бизнес-ПО, wiki, мониторинг и т.д. В качестве платформы виртуализации (большая часть сервисов на виртуалках) используется VMware.
> Что еще используете и для чего?
Помимо опёнка у нас ряд сервисов завязан на Windows Server, плюс зоопарк на стендах (в основном специфические вещи на базе Linux). На ноутбуке держу родную винду на особые случаи (скажем, давеча столкнулся с необходимостью прошивать одну железку, а программа прошивки есть только под Windows).
Джаву вращаете на Опенке?
А откуда такая политика, в чем профит?
Спрашиваю, т.к. сам на ней разрабатываю уже лет 12.В принципе внутри можно что угодно использовать, но вот заказчики не поймут такого выбора.
Убунта ЛТС, ну центос, не более.
> Джаву вращаете на Опенке?
> А откуда такая политика, в чем профит?Политика простая: зоопарк обслуживать сложнее, чем однородную среду. Раньше, например, Java-приложения бегали под CentOS; после нескольких смертей файловых систем (ext4 и ext3) на ровном месте мне это надоело, и они тоже переехали на OpenBSD.
> Спрашиваю, т.к. сам на ней разрабатываю уже лет 12.
Сочувствую, мне тоже иногда приходится. :) Кстати, IDEA работает, но не слишком резво — в основном из-за отсутствия нативных библиотек. Это вопрос решаемый, конечно, но мне оно пока что не настолько надо, чтобы переделать порт под полный сборочный цикл, ну и не только мне, видимо. А так — собрать и потыкать проекты можно.
> В принципе внутри можно что угодно использовать, но вот заказчики не поймут
> такого выбора.
> Убунта ЛТС, ну центос, не более.Если главное, чтобы LTS было, то есть конторы, готовые поддерживать OpenBSD и после официальных сроков устаревания релизов. Любой каприз за ваши деньги, как говорится. :)
А так — да, философия OpenBSD включает в себя предпочтение эволюции скачкообразному развитию. Не хочу разводить флуд на тему что правильнее. :)
> Помимо опёнка у нас ряд сервисов завязан на Windows Server,И ты, Брут?
> На ноутбуке держу родную винду на особые случаи
...таки даже ты дуалбутчик?
> а программа прошивки есть только под Windows).
А я таки перелил древний телефон из вайна в порядке научного эксперимента.
>> Помимо опёнка у нас ряд сервисов завязан на Windows Server,
> И ты, Брут?
>> На ноутбуке держу родную винду на особые случаи
> ...таки даже ты дуалбутчик?
>> а программа прошивки есть только под Windows).
> А я таки перелил древний телефон из вайна в порядке научного эксперимента.Иногда бывают вещи посерьёзнее (да и поинтереснее) древних телефонов. И, кстати, да, под OpenBSD wine отсутствует.
А вообще смешно смотрятся комментарии «и ты, Брут» вместе с рассказом об использовании wine. ;)
> Виртуализации все еще нет.Тео, мягко говоря, совсем не в восторге от неё: https://marc.info/?l=openbsd-misc&m=119318909016582
Так что расчитывать на неё я бы не советовал.
А он уже прекратил вымогать деньги за электричество на свой парк серверов? А то прикольно умничать за чужой счет. А многие другие себе такое пижонство позволить не могут, вот и любят виртуализацию :)
>64-разрядных процессорах AMD
>Intel 64как это понимать?
Путаница с этим связана с Itanium. В начале 2000-х годов Intel решила сделать переход на x64 революционным, на новую архитектуру, думаю из-за того что у нее утекла лицензия на ISA х86
сторонней компании - AMD. Тогда на рынке было тесно, у intel был неудачный pentium4, а тут эта AMD с её Атлонами и Дюронами. В общем Intel решила создать новую ISA IA-64, потеряв обратную совместимость с x86. Из этого ничего не вышло, рынок не поддержал, старый софт без исходников, тормоза с трансляцией x86, да еще вендорлок. А в это время AMD сделала расширение ISA x86 известное как amd64, с сохранением обратной совместимости. Intel опомнилась, перелицензировала у AMD расширения себе, не забыв переименовать в EM64T, ну чтоб не было упоминовений об AMD в названиях её чипов. Так часто делают вендоры, когда-то Nvidia лицензирована S3TC у S3, переименовав технологию в DXTC, опять же престиж марки :) Теперь многие пугаются когда видят в названии дистрибутива суффикс amd64 (debian, gentoo...), вопрошая "а у меня intel, где скачать для моего процессора?!", не понимая что это общее название для расширенной ISA x86.
>> Intel опомнилась, перелицензировала у AMD расширения себе, ...У AMD и Intel заключен договор о "вечном" взаимном разрешении на использование вновь изобретаемых процессорных инструкций. В споре с IA-32 и AMD64 речь идет о торговых марках.
Ну не все в моем рассказе наверное правда," я художник я так вижу". В частности про S3TC, это оказывается Microsoft для DirectX лицензировала метод сжатия и назвала его DXTC, наверное она тогда все вкусности в свой api тащила, потому как вокруг конкуренты в лице OGL и проприетарых Glide и MeTaL. Кстати только в прошлом году на S3TC истекли патенты (20 лет) и буквально несколько месяцев назад это древнее сжатие текстур стало доступно в mesa, хотя уже есть свободные и более эффективные алгоритмы сжатия текстур, но вроде для старых игр нужно.
> В общем Intel решила создать новую ISA IA-64, потеряв обратную совместимость
> с x86. Из этого ничего не вышло, рынок не поддержал, старыйнаоборот, сохранив, но кривым полу-софтовым способом. Поэтому "рынок" в лице не особенно разбирающихся в технике топтопов решил ничего не делать, "оно же совместимо", а потом пошли жалобы что "что-то оно в разы медленнее чем на i86, за в разы больше денег". Кто бы мог подумать, ну правда.
И тут amd воспользовалась моментом, сделав кривое-косое, но позволяющее ничего не менять, решеньице, не имеющее явных проблем с производительностью.
топ-топы получили возможность еще лет десять рассказывать, что 64 бита дорого и ненужно, и кормить
меньше индусско-подданных. А те, кому уже было совсем тесно в 32 - возможность кое-как работать.В общем, закон рынка - из всех возможных решений всегда побеждает технически наиболее уродливое.
> В общем, закон рынка - из всех возможных решений всегда побеждает технически наиболее уродливое.Ну я не эксперт, но какой может быть ISA у VLIW процессора? Наверное сложная, как я понимаю там инструкции формируются в бандлы, который затем исполняются разом, причем в бандле инструкции должны быть разные, т.е. нужно проявить сноровку с жонглированием последовательностями исполняемых инструкций для полной утилизации вычислительной мощности. Эльбрус вот ругают за это, AMD в своих GPU отказались от VLIW.
ну а в чем проблема? У интела параллельность инструкций - аж с 486, хоть ему до настоящего vliw как до китая раком.
Ну да, разные. Ну да, вручную это оптимизировать - удел сильно долбанутых. В принципе, и не предназначалось для подбора вручную. (ну да, и компиляторы были - то еще гуано. И ничего, никак на продажи не повлияло, пипл все схавал и добавки просил ;-)
Ничего хорошего от IA-64 не случилось бы, почитал статьи о тех годах, многие пишут что intel сделал несовместимую архитектуру чтоб убрать конкрецию с AMD, это был венодр лок, они бы не лицензировали IA-64. Даже сейчас когда вдруг появляется информация что кто-то готов сделать x86 транслятор для серверных ARM, intel начинает в прессе заявлять про свою интеллектуальную собственность на x86.
Даже если x86 плох, то сейчас уже есть OpenSpark и risc-v, глядишь скоро можно будет купить в свободной продаже.
Закон рынка: теоретики идут лесом. Их "правильные прямые" поделки в итоге либо не взлетают, либо оказываются нерентабельны, либо ещё чего. Отличный пример "ещё чего" от теоретиков - IPv6.
> Отличный пример "ещё чего" от теоретиков - IPv6.А что с ним не так? У меня его есть и он работает. В отличие от итаников. Учитывая что IP4 айпишники настолько что даже на хостингах с ними уже туговато, а на домашних конекциях все чаще NAT - вариантов немного. Нравится, не нравится, жри моя красавица.
> Проблема проявляется на 64-разрядных процессорах x86 (AMD и Intel)Может, всё же intel x86 и IA-32?
> A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures SDM
Действительно какая-то фигня про AMD написано, в самом CVE-2018-8897 только Intel
> Причиной возникновения уязвимости является недостаточно ясная трактовка в официальной документацииДреппер же ясно сказал: если можно понимать двояко, значит оба варианта верны!
Хорошо если двояко, только двояко - это до изменения регистра или после.
А предположение, что исключение срабатывает не в сбойной инструкции, а в следующей (и предварительно установив как нив в чем не бывало контекст этой следующей инструкции) это уже за гранью добра и зла.
Со стороны выглядит как - "Мы не виноваты, это вы нас не правильно поняли..."
по сути да, очередной типичный design flaw интела, кое-как прикрытый фиговым листком документации.то есть a) сперва ниасилили вовремя остановить исполнение кода в отладчике b) коряво и расплывчато (индус же переводил с китайского) описали, так что при случае удалось выдать баг за фичу.
Виноваты, конечно же, разработчики ОС, не владеющие астральными методами познания.
А со стороны Интела это выглядит так: "Эти придурки не удосужились проверить результат, даже при не совсем однозначной документации"
Если так много "придурков" (обычно вполне компетентных) не удосужилось - видать, всё же не в них дело
так себе аргументик, про миллиард мух
Это выглядит как,
Оказывается надо было перебрать все комбинации команд, чтобы выяснить, что оказывается можно установить точку останова из отладчика работающего в ring3 на код в ring0 и отладчик вуаля в ring0.
Всего-то в одной (хотя и не гарантированно, что в одной, просто до других видать еще очумелые ручки не добрались) комбинации из 100500.
>The issue was fixed upstream on March 23, with Linux "stable" branches was fixed shortly thereafter. Therefore the following kernels (or higher) contain the patch: 4.15.14, 4.14.31, 4.9.91, 4.4.125. The older 4.1, 3.16, and 3.2 branches are also affected.МС забил. Ну ок.
По-моему это бэкдор.
В документации?
Почему бы и нет? Новый уровень. Никто и не заподозрит.
Чорд, это тогда самый старый бэкдор у интела - эту особенность mov ss я помню ещё кажется на 286 процах.
В микроархитектуре. Ни один здравомыслящий человек не подумает, что добронамеренные и здравомыслящие разработчики процессора могли допустить такое и что в документации правда написана и что можно реально из юзермода свою функцию выполнить в кернелмоде, если разрабы не озаботились активным противодействием этому. Отсюда и уязвимости - нормальные разработчики ОС прочитали документацию, покрутили у виска, подумали что в документации ошибка и запилили в соответствии со своими представлениями, паранойные же проверили, выложили кирпичей и запилили противодействие, засрав свой код.
NetBSD not affected. Собственно вот почему безопасники предпочитают бсд в качестве дешевых firewall, и для хостинга php страничек. А не пургеникс ваш. Удел линукса - это смартфоны и китайские планшеты!
еще суперкомпьютеры и сетевое оборудование ну и еще немного серверов
> еще суперкомпьютеры и сетевое оборудование ну и еще немного серверовИ прочие ракеты у элонмаска и какие там еще ПЛК управляющие поездами. Фигня, это ж не тостер с бсд.
На самом деле NetBSD (в отличие от других BSD) неплох, тк он мне больше всех похож на классический Unix. Если бы все было так же хорошо с поддержкой железа, как в линуксе, то использовал бы только его.
Так себе аргумент - со времён "классического Unix" поменялось примерно всё, начиная со скоростей и заканчивая разными USB-устройствами и лэптопами. И модель пользования тоже поменялась радикально. Хотя всякие убунты с федорами да гномокеды я и сам не выдерживаю - это уже виндомакось какая-то - хрен угадаешь, что когда оно сотворит. Но подозреваю, что баланс всё же не там, где NetBSD.Ну и BSD-лицензия - это отдельное зло.
> OpenBSD и NetBSD не подвержены уязвимости.а говорили - masturbating monkeys... а оно вона как...
>Для решения проблемы в контексте ядра следовало очистить значение регистра DR6, определить обработчик #DB в стиле обработчика NMI или подменить стек при помощи IST (Interrupt Stack Table).т.е. в опенке и нетбсд так было сделано изначально? Или они просто не использовали сабжевую функциоанльность процессора?
> а говорили - masturbating monkeys... а оно вона как...А что, не так говорили? Управление проектом штука сложная и многогранная. И глядя как Тео вымогал $$$ на электричество...
[Параноик мод он]
Я, конечно, понимаю, что интеловцы косячат, но зашкаливающее количество уязвимостей, которые в последнее время раскрываются чуть ли не каждый день, наводит на мысли о развернутой кампании по дискредитации интела. Уверен, если покопаться в амдшных процах, и не такое всплыть может, но все сосредоточены именно на интеле.
Да, я знаю, что на опеннете принято люто-бешено ненавидеть все интеловское, но все же странно, не?
[Параноик мод офф]
Мысль правильная, вывод неправильный. Это говорит не о попытках дискредитировать, а о зашкаливающем количестве бэкдоров для спецслужб.
> Уверен, если покопаться в амдшных процах, и не такое всплыть можетэта проблема не специфична для интеловских. У amd никогда не было собственной полноценной документации (или она не для всех, что в общем одно и то же)
просто вы до сих пор не научились различать архитектуру и компанию.
> эта проблема не специфична для интеловских.Да, проблема бэкдоров для спецслужб действительно не характерна для како-либо компании. Деньги то не пахнут.
у спецслужб, семей, любовниц, агентуры какое-то особое оборудование без бэкдоров? или это контроль за спецслужбами?
Им то какая разница? Сами себя будут взламывать? Они работают на дядю Рокфеллера (утрирую), который им платит за слитые данные. Собственно и всё.
> Им то какая разница? Сами себя будут взламывать?Внезапно да. Больше некому. Уверен что для НОАК и ФСБ эта байда тоже была полной неожиданностью. Пространство поиска огромно, либо ты знаешь, где искать, либо ты наткнулся случайно, либо ты никогда этого не найдёшь. У всего мира ушло >20 лет чтобы это найти. А у спецслужб контингент меньше, чем системных программистов во всём мире.
Ну смотри. То есть сидит такой хакер в АНБ идёт домой и взламывает свой компьютер? Зачем? Или его кто-то взламывает? Опять же - зачем? Он у всех на виду. Да и наверняка работа и личная жизнь отделена и никто не знает кто он на самом деле, так что для иностранных спецслужб он тоже малоинтересен. Не понимаю логики, потрудись объяснить.
Поясняю. Об этой байде скорее всего знали только те, для кого она была предназначена. А остальные до сегодняшнего момента не знали. Поэтому свои особо критические системы они укрепили, а некритические оставили как есть, риск их временной компрометации не перевешивает вред от раскрытия инфы об уязвимости шпионам других государств внутри анб.
> Ну смотри. То есть сидит такой хакер в АНБ идёт домой и
> взламывает свой компьютер? Зачем? Или его кто-то взламывает?Внезапно свои же, для проверки что он играет честно, например. А еще бывают двойные, тройные и какие там еще агенты, которых кто только не перевербовал 5 раз подряд. Откуда я узнал? Бл, я ге супершпион, это тупо в википедии написано.
Это нахывается "мода". кинулись ковырять интел - наковыряли, разумеется. Возьмутся за AMD или ARM/Qualcomm - и там будет то же самое. Процессоры делаются совсем на грани человеческих возможностей - и технологических, и интеллектуальных. То, что там будет куча багов - ожидаемо.
25-й кадр, в смысле 65-й бит в процессоре или 66-й уже, или что это?...
Уже не хочется покупать, ни интел, ни амд.
Слышал, что есть какие-то другие процессоры, но они пока-что доступны только для организаций. Кто нибудь знает, когда они будут выпускаться для частных потребителей?
Уже недолго... Там 82 бита в регистрах регистрового файла (80 бит под long double + 2 бита тегов), скоро будет доступен проц с 130 битными регистрами.
Эльбрус. Недавно вроде новость была про снижение цены и розницу, не помню...
> Эльбрус. Недавно вроде новость была про снижение цены и розницу, не помню...Хорошая попытка, МЦСТ, но нет, ваши процессоры никому не нужны.
>> Эльбрус. Недавно вроде новость была про снижение цены и розницу, не помню...
> Хорошая попытка, МЦСТ, но нет, ваши процессоры никому не нужны.На картинках-то хоть видел?
>> Хорошая попытка, МЦСТ, но нет, ваши процессоры никому не нужны.
> На картинках-то хоть видел?ну я увидел, и чо? "собирает собственное ядро за 3.2 часа". Прекрасно.
>>> Хорошая попытка, МЦСТ, но нет, ваши процессоры никому не нужны.
>> На картинках-то хоть видел?
> ну я увидел, и чо? "собирает собственное ядро за 3.2 часа". Прекрасно.Что там в ядре навключал? А то у меня 16-ядерный Opteron убунтушное ядро часов 5 собирает.
> Что там в ядре навключал? А то у меня 16-ядерный Opteron
> убунтушное ядро часов 5 собирает.А чего так медленно то? FX 8-ядерный и то менее чем за 2 часа со всеми модулями чистую сборку обмолачивает.
>> Что там в ядре навключал? А то у меня 16-ядерный Opteron
>> убунтушное ядро часов 5 собирает.
> А чего так медленно то? FX 8-ядерный и то менее чем за
> 2 часа со всеми модулями чистую сборку обмолачивает.Ядро убунту, дистрибутивное, со всеми плюшками, ....
> Эльбрус. Недавно вроде новость была про снижение цены и розницу, не помню...Как там с открытым компилером дела? NDA при покупке по прежнему надо?
У Intel скоро будет как с талмудом - документация и трактовка, превосходящая по объёму документацию.
Ссылка на коммит: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
100500 раз надо говорить майнтейнерам-пингвинам: Удаляйте (отключайте полностью) наxep отладочный функционал из ядра.
> 100500 раз надо говорить майнтейнерам-пингвинам: Удаляйте (отключайте полностью) наxep
> отладочный функционал из ядра.Угу, грохни себе из ядра все вплоть до symbols. И еще ASLR вруби. А потом когда что-то фигакнется, получишь в рыло какой-нибудь error 5 at address 0x80316282 - и удачи тебе понять что это за гамно вообще произошло. Ну примерно как в openwrt. Ядро конечно становится меньше, но дебажить - затрашешься.
Ну это же интел, они вечно косячат
> Разработчики многих операционных систем полагали, что попадание инструкции MOV SS в точку останова приводит к генерации исключения #DB сразу после завершения MOV SS, но на деле исключение откладываетсяВот так новости... все кто отлаживал в DOS интерактивным отладчиком об этом знают, при нажатии “step" на mov ss указатель выполнения перескочит две инструкции потому что изменение сегмента стека блокирует прерывание