The OpenNET Project / Index page

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



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

"Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от opennews on 10-Май-18, 09:48 
Раскрыта (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-05/), 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

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

Оглавление

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


1. "Неверная трактовка документации Intel привела к уязвимости в..."  +60 +/
Сообщение от Anonymous Coward on 10-Май-18, 09:48 
> OpenBSD и NetBSD не подвержены уязвимости.

Срочно в новости: авторы OpenBSD и NetBSD умеют читать!

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

5. "Неверная трактовка документации Intel привела к уязвимости в..."  +3 +/
Сообщение от Смузихлеб on 10-Май-18, 09:54 
Может очень ленивые в отличии от фронтендеров?
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

49. "Неверная трактовка документации Intel привела к уязвимости в..."  –2 +/
Сообщение от anonymous (??) on 10-Май-18, 13:17 
Еще в AMD умеют читать
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

83. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от Anonymuos on 10-Май-18, 21:29 
> Еще в AMD умеют читать
>Проблема проявляется на 64-разрядных процессорах x86 (AMD и Intel)

Разве?

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

90. "Неверная трактовка документации Intel привела к уязвимости в..."  +3 +/
Сообщение от Вареник on 11-Май-18, 02:33 
AMD совместим с Intel. Все нормально.
Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

56. "Неверная трактовка документации Intel привела к уязвимости в..."  +5 +/
Сообщение от Аноним (??) on 10-Май-18, 14:54 
Видимо, при реализации архитектуры AMD64 они, как ни странно,пользовались документацией от AMD....
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

96. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 11-Май-18, 08:53 
> OpenBSD и NetBSD не подвержены уязвимости.

А где ссылка на пруф?

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

2. "Неверная трактовка документации привела к уязвимости в больш..."  +6 +/
Сообщение от iCat (ok) on 10-Май-18, 09:49 
Вот это номер...
Получается, что формальное следование формулярам приводит к опсным последствиям.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Неверная трактовка документации привела к уязвимости в больш..."  +2 +/
Сообщение от Смузихлеб on 10-Май-18, 09:55 
> Вот это номер...
> Получается, что формальное следование формулярам приводит к опсным последствиям.

В RFC те же грабли, даже неточности в BGP.

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

4. "Неверная трактовка документации Intel привела к уязвимости в..."  –4 +/
Сообщение от rscx64_ on 10-Май-18, 09:52 
почему ядро фрибсд даже менее защищено чем линукс?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Неверная трактовка документации Intel привела к уязвимости в..."  +15 +/
Сообщение от Baz on 10-Май-18, 10:03 
потому, что их любимое занятие - патчить KDE #шутка
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "Неверная трактовка документации Intel привела к уязвимости в..."  +4 +/
Сообщение от ваш К.О. on 10-Май-18, 10:12 
потому что обработка прерываний устроена по разному, линуксу случайно повезло.

("зато я раком не болею..." в смысле, зато performance hit от наличия кода для pti у них околонулевой. [кода, а не самого pti] Тоже потому, что механизмы передачи управления ядру устроены совершенно иначе.)

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

113. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от недобрый on 15-Май-18, 19:32 
> зато performance hit от наличия кода для pti у них околонулевой

Нет.

> механизмы передачи управления ядру устроены совершенно иначе

Нет.

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

101. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 12-Май-18, 14:57 
>  почему ядро фрибсд даже менее защищено чем линукс?

Потому что нет никаких предпосылок для этого.

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

10. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от ваш К.О. on 10-Май-18, 10:20 
из занятного: joyent заявил что не подвержен проблеме (а значит и все, что illumos-based, тоже)
oracle жует сопли (то есть, вполне возможно что vbox уязвим, и патчей у них нет)

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

11. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 10:22 
Дыры Intel SGX подоспели https://tches.iacr.org/index.php/TCHES/article/view/879
Привет Intel с его Asylo...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Адекват (ok) on 10-Май-18, 10:37 
так погнал малеха.
А на x32 ОС эта проблема тоже будет ? или нужна x64 ОС, чтобы бага сработала ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Неверная трактовка документации Intel привела к уязвимости в..."  +7 +/
Сообщение от F on 10-Май-18, 10:40 
(Здесь ролик про Гитлера в бункере, который устраивает разнос разработчикам процов и доки)
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "Неверная трактовка документации Intel привела к уязвимости в..."  –1 +/
Сообщение от Аноним (??) on 10-Май-18, 10:44 
> OpenBSD... не подверж... уязвимости.

OpenBSD многие годы меня очень радует. Только для домашнего использования не всегда удобна и под рукой всегда держишь какой-нибудь Дебиан для узкоспециализированных задач.

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

33. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от Аноним (??) on 10-Май-18, 12:19 
Узкоспециализированных это каких? Смысл тогда держать 2 системы если постоянно нужны "узкоспециализированные" задачи?
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

39. "Неверная трактовка документации Intel привела к уязвимости в..."  +6 +/
Сообщение от Anon999 (ok) on 10-Май-18, 12:55 
Винда для узкоспециализирываных задач.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

45. "Неверная трактовка документации Intel привела к уязвимости в..."  –1 +/
Сообщение от Ку on 10-Май-18, 13:08 
1)Нет нормального прикладного десктопного софта + мало пакетов в целом.
2)Иксы, на глаз видно, как медленней работают.
3)UFS работает гораздо медленней ext4.
4)Виртуализации все еще нет.
5)Апдейты каждые полгода вручную.
.. ит.п.

Система простая и самобытная, но, увы!, на десктоп полноценный не тянет.
Сама система обновлялась бы с репов, а вся прикладуха типа flatpack или snap, было бы круто.

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

51. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 13:38 
> а вся прикладуха типа flatpack или
> snap, было бы круто.

Лучше не надо. А то куда мне валить, после того как у меня будет пол-системы в flatpack и занимать это дело будет гигов 100. Он же так и не научился шарить либы? Ну и накой он нужен?


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

92. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от Аноним (??) on 11-Май-18, 05:39 
Абсолютно согласен. Должны быть такие загончики, как OpenBSD, для любителей.
Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

102. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 12-Май-18, 15:01 
> Лучше не надо. А то куда мне валить, после того как у
> меня будет пол-системы в flatpack и занимать это дело будет гигов
> 100. Он же так и не научился шарить либы? Ну и накой он нужен?

Чтобы показать что сделать МАЗДАЙ можно даже из OpenBSD. Его, в принципе, из чего угодно можно сделать - достаточно притащить over 9000 библиотек, за которые никто не отвечает. И получится маздай, даже если это формально и не винда.

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

62. "Неверная трактовка документации Intel привела к уязвимости в..."  +2 +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Май-18, 17:13 
> 1)Нет нормального прикладного десктопного софта + мало пакетов в целом.

На вкус и цвет. MS Office и Adobe Photoshop не взлетят, это да.

> 2)Иксы, на глаз видно, как медленней работают.

Зависит от видеочипа. С NVIDIA точно будет плохо.

> 3)UFS работает гораздо медленней ext4.

Softupdates можно включить.

> 4)Виртуализации все еще нет.

/me с недоумением смотрит на то как в работающем под vmm(4) CentOS что-то собирает buildroot.

Хотя расти есть куда, конечно.

> 5)Апдейты каждые полгода вручную.

Механизм autoinstall позволяет делать это вообще ничего не предпринимая. Файлы ответов заботливо генерируются инсталлятором уже не первый релиз.

> .. ит.п.
> Система простая и самобытная, но, увы!, на десктоп полноценный не тянет.
> Сама система обновлялась бы с репов, а вся прикладуха типа flatpack или
> snap, было бы круто.

Тогда это было бы не OpenBSD, где каждый узел чётко связан с другими, а трудносопровождаемая каша в модном духе devops.

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

74. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Ку on 10-Май-18, 19:34 
Благодарю за адекватные ответы, серьезно.

Видяха Intel, ноут 12 года. Читал, что Иксы патченые у них, мбыть из-за этого.

У Softupdates есть свои минусы, да и пишут, что в основном влияет на скорость создания\удаления файлов. Однако я наблюдал, что приложения стартуют гораздо медленней. В целом было видно, что производительность упала по сравнению с пингвином. Может, действительно, что-то можно было подркутить, но я не осилил.

По мне так лучше когда в репах только все системное. ОС это чугунная неубиваемая сковорода, а прикладуха, то что на ней жаришь. И здесь мне больше импанируют более контейнеры. Установил, не надо - снес, + не нужно ждать обновления в репах. Чтобы однажды установленная ОС работала до смерти железа и оставалась всегда возможность запускать свежую прикладуху.

Поэтому сижу на убунте ЛТС, свежий софт + 5 лет можно не париться с обновлением. Роллинг страдает тем, что может однажды прибить систему, ибо постоянно перелопачивается все и вся. Поэтому на рабочей машине он противопоказан.

Как обновить безопасно Опенка? Если умрет при апдейте, есть возможность откатиться?

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

75. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Май-18, 20:17 
> Благодарю за адекватные ответы, серьезно.
> Видяха 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, установите на скорую руку набор любимых пакетов, поправьте какие-нибудь конфиги по вкусу, а затем обновите по штатному алгоритму (выше). Многих этот процесс приятно удивляет, если только отсутствие русификации вас не смущает. :)

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

80. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Ку on 10-Май-18, 21:12 
Спасибо за инфу.

Какие конкретно задачи вы решаете на Опенке и как давно?
Что еще используете и для чего?

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

85. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Май-18, 21:44 
> Спасибо за инфу.
> Какие конкретно задачи вы решаете на Опенке и как давно?

Если не считать моего личного ноутбука, являющегося основным компом для всего подряд (от разработки до ютубных котиков) уже лет... уже почти пятнадцать?! — фигасе время-то жизни пролетело... Так вот, если не считать периодически меняющийся ноутбук, то на базе опёнка у меня в отделе разработки, где работаю большую часть времени, развёрнута большая часть инфраструктуры: Java-based бизнес-ПО, wiki, мониторинг и т.д. В качестве платформы виртуализации (большая часть сервисов на виртуалках) используется VMware.

> Что еще используете и для чего?

Помимо опёнка у нас ряд сервисов завязан на Windows Server, плюс зоопарк на стендах (в основном специфические вещи на базе Linux). На ноутбуке держу родную винду на особые случаи (скажем, давеча столкнулся с необходимостью прошивать одну железку, а программа прошивки есть только под Windows).

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

87. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Ку on 10-Май-18, 22:20 
Джаву вращаете на Опенке?
А откуда такая политика, в чем профит?
Спрашиваю, т.к. сам на ней разрабатываю уже лет 12.

В принципе внутри можно что угодно использовать, но вот заказчики не поймут такого выбора.
Убунта ЛТС, ну центос, не более.

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

89. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Май-18, 22:56 
> Джаву вращаете на Опенке?
> А откуда такая политика, в чем профит?

Политика простая: зоопарк обслуживать сложнее, чем однородную среду. Раньше, например, Java-приложения бегали под CentOS; после нескольких смертей файловых систем (ext4 и ext3) на ровном месте мне это надоело, и они тоже переехали на OpenBSD.

> Спрашиваю, т.к. сам на ней разрабатываю уже лет 12.

Сочувствую, мне тоже иногда приходится. :) Кстати, IDEA работает, но не слишком резво — в основном из-за отсутствия нативных библиотек. Это вопрос решаемый, конечно, но мне оно пока что не настолько надо, чтобы переделать порт под полный сборочный цикл, ну и не только мне, видимо. А так — собрать и потыкать проекты можно.

> В принципе внутри можно что угодно использовать, но вот заказчики не поймут
> такого выбора.
> Убунта ЛТС, ну центос, не более.

Если главное, чтобы LTS было, то есть конторы, готовые поддерживать OpenBSD и после официальных сроков устаревания релизов. Любой каприз за ваши деньги, как говорится. :)

А так — да, философия OpenBSD включает в себя предпочтение эволюции скачкообразному развитию. Не хочу разводить флуд на тему что правильнее. :)

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

104. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 12-Май-18, 22:42 
> Помимо опёнка у нас ряд сервисов завязан на Windows Server,

И ты, Брут?

> На ноутбуке держу родную винду на особые случаи

...таки даже ты дуалбутчик?

>  а программа прошивки есть только под Windows).

А я таки перелил древний телефон из вайна в порядке научного эксперимента.

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

112. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от PereresusNeVlezaetBuggy (ok) on 12-Май-18, 23:49 
>> Помимо опёнка у нас ряд сервисов завязан на Windows Server,
> И ты, Брут?
>> На ноутбуке держу родную винду на особые случаи
> ...таки даже ты дуалбутчик?
>>  а программа прошивки есть только под Windows).
> А я таки перелил древний телефон из вайна в порядке научного эксперимента.

Иногда бывают вещи посерьёзнее (да и поинтереснее) древних телефонов. И, кстати, да, под OpenBSD wine отсутствует.

А вообще смешно смотрятся комментарии «и ты, Брут» вместе с рассказом об использовании wine. ;)

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

99. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от имя on 11-Май-18, 20:46 
> Виртуализации все еще нет.

Тео, мягко говоря, совсем не в восторге от неё: https://marc.info/?l=openbsd-misc&m=119318909016582

Так что расчитывать на неё я бы не советовал.

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

103. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 12-Май-18, 15:04 
А он уже прекратил вымогать деньги за электричество на свой парк серверов? А то прикольно умничать за чужой счет. А многие другие себе такое пижонство позволить не могут, вот и любят виртуализацию :)
Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

16. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 10:48 
>64-разрядных процессорах AMD
>Intel 64

как это понимать?

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

36. "Неверная трактовка документации Intel привела к уязвимости в..."  +12 +/
Сообщение от Аноним (??) on 10-Май-18, 12:30 
Путаница с этим связана с 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.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

38. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от Аноним (??) on 10-Май-18, 12:46 
>> Intel опомнилась, перелицензировала у AMD расширения себе, ...

У AMD и Intel заключен договор о "вечном" взаимном разрешении на использование вновь изобретаемых процессорных инструкций. В споре с IA-32 и AMD64 речь идет о торговых марках.

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

48. "Неверная трактовка документации Intel привела к уязвимости в..."  +3 +/
Сообщение от Аноним (??) on 10-Май-18, 13:15 
Ну не все в моем рассказе наверное правда," я художник я так вижу". В частности про S3TC, это оказывается Microsoft для DirectX лицензировала метод сжатия и назвала его DXTC, наверное она тогда все вкусности в свой api тащила, потому как вокруг конкуренты в лице OGL и проприетарых Glide и MeTaL. Кстати только в прошлом году на S3TC истекли патенты (20 лет) и буквально несколько месяцев назад это древнее сжатие текстур стало доступно в mesa, хотя уже есть свободные и более эффективные алгоритмы сжатия текстур, но вроде для старых игр нужно.
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

54. "Неверная трактовка документации Intel привела к уязвимости в..."  –1 +/
Сообщение от пох on 10-Май-18, 14:15 
> В общем Intel решила создать новую ISA IA-64, потеряв обратную совместимость
> с x86. Из этого ничего не вышло, рынок не поддержал, старый

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

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

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

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

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

70. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 18:34 
> В общем, закон рынка - из всех возможных решений всегда побеждает технически наиболее уродливое.

Ну я не эксперт, но какой может быть ISA у VLIW процессора? Наверное сложная, как я понимаю там инструкции формируются в бандлы, который затем исполняются разом, причем в бандле инструкции должны быть разные, т.е. нужно проявить сноровку с жонглированием последовательностями исполняемых инструкций для полной утилизации вычислительной мощности. Эльбрус вот ругают за это, AMD в своих GPU отказались от VLIW.

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

78. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от пох on 10-Май-18, 20:50 
ну а в чем проблема? У интела параллельность инструкций - аж с 486, хоть ему до настоящего vliw как до китая раком.
Ну да, разные. Ну да, вручную это оптимизировать - удел сильно долбанутых. В принципе, и не предназначалось для подбора вручную. (ну да, и компиляторы были - то еще гуано. И ничего, никак на продажи не повлияло, пипл все схавал и добавки просил ;-)

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

81. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 21:15 
Ничего хорошего от IA-64 не случилось бы, почитал статьи о тех годах, многие пишут что intel сделал несовместимую архитектуру чтоб убрать конкрецию с AMD, это был венодр лок, они бы не лицензировали IA-64. Даже сейчас когда вдруг появляется информация что кто-то готов сделать x86 транслятор для серверных ARM, intel начинает в прессе заявлять про свою интеллектуальную собственность на x86.
Даже если x86 плох, то сейчас уже есть OpenSpark и risc-v, глядишь скоро можно будет купить в свободной продаже.
Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

88. "Неверная трактовка документации Intel привела к уязвимости в..."  –1 +/
Сообщение от anomymous on 10-Май-18, 22:32 
Закон рынка: теоретики идут лесом. Их "правильные прямые" поделки в итоге либо не взлетают, либо оказываются нерентабельны, либо ещё чего. Отличный пример "ещё чего" от теоретиков - IPv6.
Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

105. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 12-Май-18, 22:47 
> Отличный пример "ещё чего" от теоретиков - IPv6.

А что с ним не так? У меня его есть и он работает. В отличие от итаников. Учитывая что IP4 айпишники настолько что даже на хостингах с ними уже туговато, а на домашних конекциях все чаще NAT - вариантов немного. Нравится, не нравится, жри моя красавица.

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

17. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от tensor on 10-Май-18, 10:52 
> Проблема проявляется на 64-разрядных процессорах x86 (AMD и Intel)

Может, всё же intel x86 и IA-32?

> A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures SDM

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

47. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от fi (ok) on 10-Май-18, 13:15 
Действительно какая-то фигня про AMD написано, в самом CVE-2018-8897 только Intel
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

20. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 11:02 
> Причиной возникновения уязвимости является недостаточно ясная трактовка в официальной документации

Дреппер же ясно сказал: если можно понимать двояко, значит оба варианта верны!

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

25. "Неверная трактовка документации Intel привела к уязвимости в..."  +6 +/
Сообщение от КО on 10-Май-18, 11:20 
Хорошо если двояко, только двояко - это до изменения регистра или после.
А предположение, что исключение срабатывает не в сбойной инструкции, а в следующей (и предварительно установив как нив в чем не бывало контекст этой следующей инструкции) это уже за гранью добра и зла.
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

27. "Неверная трактовка документации Intel привела к уязвимости в..."  +6 +/
Сообщение от cat666 email(ok) on 10-Май-18, 11:32 
Со стороны выглядит как - "Мы не виноваты, это вы нас не правильно поняли..."
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "Неверная трактовка документации Intel привела к уязвимости в..."  +6 +/
Сообщение от пох on 10-Май-18, 11:39 
по сути да, очередной типичный design flaw интела, кое-как прикрытый фиговым листком документации.

то есть a) сперва ниасилили вовремя остановить исполнение кода в отладчике b) коряво и расплывчато (индус же переводил с китайского) описали, так что при случае удалось выдать баг за фичу.
Виноваты, конечно же, разработчики ОС, не владеющие астральными методами познания.

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

30. "Неверная трактовка документации Intel привела к уязвимости в..."  –2 +/
Сообщение от A.Stahl (ok) on 10-Май-18, 11:39 
А со стороны Интела это выглядит так: "Эти придурки не удосужились проверить результат, даже при не совсем однозначной документации"
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

65. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от Crazy Alex (ok) on 10-Май-18, 17:27 
Если так много "придурков" (обычно вполне компетентных) не удосужилось - видать, всё же не в них дело
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

93. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 11-Май-18, 05:50 
так себе аргументик, про миллиард мух
Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

98. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от КО on 11-Май-18, 15:25 
Это выглядит как,
Оказывается надо было перебрать все комбинации команд, чтобы выяснить, что оказывается можно установить точку останова из отладчика работающего в ring3 на код в ring0 и отладчик вуаля в ring0.
Всего-то в одной (хотя и не гарантированно, что в одной, просто до других видать еще очумелые ручки не добрались) комбинации из 100500.
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

28. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от Аноним (??) on 10-Май-18, 11:38 
>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.

МС забил. Ну ок.

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

32. "Неверная трактовка документации Intel привела к уязвимости в..."  +5 +/
Сообщение от Аноним (??) on 10-Май-18, 11:42 
По-моему это бэкдор.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

37. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от ПДК on 10-Май-18, 12:36 
В документации?
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

41. "Неверная трактовка документации Intel привела к уязвимости в..."  +5 +/
Сообщение от Аноним (??) on 10-Май-18, 12:58 
Почему бы и нет? Новый уровень. Никто и не заподозрит.
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

76. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от Тыгра on 10-Май-18, 20:20 
Чорд, это тогда самый старый бэкдор у интела - эту особенность mov ss я помню ещё кажется на 286 процах.
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

82. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 21:24 
В микроархитектуре. Ни один здравомыслящий человек не подумает, что добронамеренные и здравомыслящие разработчики процессора могли допустить такое и что в документации правда написана и что можно реально из юзермода свою функцию выполнить в кернелмоде, если разрабы не озаботились активным противодействием этому. Отсюда и уязвимости - нормальные разработчики ОС прочитали документацию, покрутили у виска, подумали что в документации ошибка и запилили в соответствии со своими представлениями, паранойные же проверили, выложили кирпичей и запилили противодействие, засрав свой код.
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

40. "Неверная трактовка док..."  –8 +/
Сообщение от Аноним (??) on 10-Май-18, 12:55 
NetBSD not affected. Собственно вот почему безопасники предпочитают бсд в качестве дешевых firewall, и для хостинга php страничек. А не пургеникс ваш. Удел линукса - это смартфоны и китайские планшеты!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "Неверная трактовка док..."  +1 +/
Сообщение от анон on 10-Май-18, 13:03 
еще суперкомпьютеры и сетевое оборудование ну и еще немного серверов
Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

106. "Неверная трактовка док..."  +/
Сообщение от Аноним (??) on 12-Май-18, 22:49 
> еще суперкомпьютеры и сетевое оборудование ну и еще немного серверов

И прочие ракеты у элонмаска и какие там еще ПЛК управляющие поездами. Фигня, это ж не тостер с бсд.

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

46. "Неверная трактовка док..."  +/
Сообщение от Аноним (??) on 10-Май-18, 13:11 
На самом деле NetBSD (в отличие от других BSD) неплох, тк он мне больше всех похож на классический Unix. Если бы все было так же хорошо с поддержкой железа, как в линуксе, то использовал бы только его.
Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

66. "Неверная трактовка док..."  +/
Сообщение от Crazy Alex (ok) on 10-Май-18, 17:31 
Так себе аргумент - со времён "классического Unix" поменялось примерно всё, начиная со скоростей и заканчивая разными USB-устройствами и лэптопами. И модель пользования тоже поменялась радикально. Хотя всякие убунты с федорами да гномокеды я и сам не выдерживаю - это уже виндомакось какая-то - хрен угадаешь, что когда оно сотворит. Но подозреваю, что баланс всё же не там, где NetBSD.

Ну и BSD-лицензия - это отдельное зло.

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

42. "Неверная трактовка документации Intel привела к уязвимости в..."  +2 +/
Сообщение от Клыкастый (ok) on 10-Май-18, 13:00 
>  OpenBSD и NetBSD не подвержены уязвимости.

а говорили - masturbating monkeys... а оно вона как...

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

94. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 11-Май-18, 05:53 
>Для решения проблемы в контексте ядра следовало очистить значение регистра DR6, определить обработчик #DB в стиле обработчика NMI или подменить стек при помощи IST (Interrupt Stack Table).

т.е. в опенке и нетбсд так было сделано изначально? Или они просто не использовали сабжевую функциоанльность процессора?

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

107. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 12-Май-18, 22:51 
> а говорили - masturbating monkeys... а оно вона как...

А что, не так говорили? Управление проектом штука сложная и многогранная. И глядя как Тео вымогал $$$ на электричество...

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

44. "Неверная трактовка документации Intel привела к уязвимости в..."  –2 +/
Сообщение от Аноним (??) on 10-Май-18, 13:08 
[Параноик мод он]
Я, конечно, понимаю, что интеловцы косячат, но зашкаливающее количество уязвимостей, которые в последнее время раскрываются чуть ли не каждый день, наводит на мысли о развернутой кампании по дискредитации интела. Уверен, если покопаться в амдшных процах, и не такое всплыть может, но все сосредоточены именно на интеле.
Да, я знаю, что на опеннете принято люто-бешено ненавидеть все интеловское, но все же странно, не?
[Параноик мод офф]
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

50. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 13:27 
Мысль правильная, вывод неправильный. Это говорит не о попытках дискредитировать, а о зашкаливающем количестве бэкдоров для спецслужб.
Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

52. "Неверная трактовка документации Intel привела к уязвимости в..."  –1 +/
Сообщение от пох on 10-Май-18, 14:05 
> Уверен, если покопаться в амдшных процах, и не такое всплыть может

эта проблема не специфична для интеловских. У amd никогда не было собственной полноценной документации (или она не для всех, что в общем одно и то же)

просто вы до сих пор не научились различать архитектуру и компанию.

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

58. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 15:06 
> эта проблема не специфична для интеловских.

Да, проблема бэкдоров для спецслужб действительно не характерна для како-либо компании. Деньги то не пахнут.

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

64. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 17:26 
у спецслужб, семей, любовниц, агентуры какое-то особое оборудование без бэкдоров? или это контроль за спецслужбами?
Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

77. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 20:28 
Им то какая разница? Сами себя будут взламывать? Они работают на дядю Рокфеллера (утрирую), который им платит за слитые данные. Собственно и всё.
Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

84. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 21:29 
> Им то какая разница? Сами себя будут взламывать?

Внезапно да. Больше некому. Уверен что для НОАК и ФСБ эта байда тоже была полной неожиданностью. Пространство поиска огромно, либо ты знаешь, где искать, либо ты наткнулся случайно, либо ты никогда этого не найдёшь. У всего мира ушло >20 лет чтобы это найти. А у спецслужб контингент меньше, чем системных программистов во всём мире.

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

95. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 11-Май-18, 07:25 
Ну смотри. То есть сидит такой хакер в АНБ идёт домой и взламывает свой компьютер? Зачем? Или его кто-то взламывает? Опять же - зачем? Он у всех на виду. Да и наверняка работа и личная жизнь отделена и никто не знает кто он на самом деле, так что для иностранных спецслужб он тоже малоинтересен. Не понимаю логики, потрудись объяснить.
Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

97. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 11-Май-18, 10:34 
Поясняю. Об этой байде скорее всего знали только те, для кого она была предназначена. А остальные до сегодняшнего момента не знали. Поэтому свои особо критические системы они укрепили, а некритические оставили как есть, риск их временной компрометации не перевешивает вред от раскрытия инфы об уязвимости шпионам других государств внутри анб.
Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

108. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 12-Май-18, 22:54 
> Ну смотри. То есть сидит такой хакер в АНБ идёт домой и
> взламывает свой компьютер? Зачем? Или его кто-то взламывает?

Внезапно свои же, для проверки что он играет честно, например. А еще бывают двойные, тройные и какие там еще агенты, которых кто только не перевербовал 5 раз подряд. Откуда я узнал? Бл, я ге супершпион, это тупо в википедии написано.

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

67. "Неверная трактовка документации Intel привела к уязвимости в..."  +3 +/
Сообщение от Crazy Alex (ok) on 10-Май-18, 17:33 
Это нахывается "мода". кинулись ковырять интел - наковыряли, разумеется. Возьмутся за AMD или ARM/Qualcomm - и там будет то же самое. Процессоры делаются совсем на грани человеческих возможностей - и технологических, и интеллектуальных. То, что там будет куча багов - ожидаемо.
Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

55. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 14:17 
25-й кадр, в смысле 65-й бит в процессоре или 66-й уже, или что это?...
Уже не хочется покупать, ни интел, ни амд.
Слышал, что есть какие-то другие процессоры, но они пока-что доступны только для организаций. Кто нибудь знает, когда они будут выпускаться для частных потребителей?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

57. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от КО on 10-Май-18, 15:01 
Уже недолго... Там 82 бита в регистрах регистрового файла (80 бит под long double + 2 бита тегов), скоро будет доступен проц с 130 битными регистрами.
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

61. "Неверная трактовка документации Intel привела к уязвимости в..."  +2 +/
Сообщение от Аноне on 10-Май-18, 16:06 
Эльбрус. Недавно вроде новость была про снижение цены и розницу, не помню...
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

68. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от Аноним (??) on 10-Май-18, 17:41 
> Эльбрус. Недавно вроде новость была про снижение цены и розницу, не помню...

Хорошая попытка, МЦСТ, но нет, ваши процессоры никому не нужны.

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

73. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от pavlinux (ok) on 10-Май-18, 19:07 
>> Эльбрус. Недавно вроде новость была про снижение цены и розницу, не помню...
> Хорошая попытка, МЦСТ, но нет, ваши процессоры никому не нужны.

На картинках-то хоть видел?

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

79. "Неверная трактовка документации Intel привела к уязвимости в..."  –2 +/
Сообщение от пох on 10-Май-18, 20:52 
>> Хорошая попытка, МЦСТ, но нет, ваши процессоры никому не нужны.
> На картинках-то хоть видел?

ну я увидел, и чо? "собирает собственное ядро за 3.2 часа". Прекрасно.

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

100. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от pavlinux (ok) on 12-Май-18, 04:25 
>>> Хорошая попытка, МЦСТ, но нет, ваши процессоры никому не нужны.
>> На картинках-то хоть видел?
> ну я увидел, и чо? "собирает собственное ядро за 3.2 часа". Прекрасно.

Что там в ядре навключал?  А то у меня 16-ядерный Opteron убунтушное ядро часов 5 собирает.

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

110. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 12-Май-18, 22:57 
> Что там в ядре навключал?  А то у меня 16-ядерный Opteron
> убунтушное ядро часов 5 собирает.

А чего так медленно то? FX 8-ядерный и то менее чем за 2 часа со всеми модулями чистую сборку обмолачивает.

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

109. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 12-Май-18, 22:55 
> Эльбрус. Недавно вроде новость была про снижение цены и розницу, не помню...

Как там с открытым компилером дела? NDA при покупке по прежнему надо?

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

60. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 15:48 
У Intel скоро будет как с талмудом - документация и трактовка, превосходящая по объёму документацию.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

69. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от IZh. on 10-Май-18, 18:18 
Ссылка на коммит: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

72. "Неверная трактовка документации Intel привела к уязвимости в..."  +2 +/
Сообщение от pavlinux (ok) on 10-Май-18, 19:05 
100500 раз надо говорить майнтейнерам-пингвинам: Удаляйте (отключайте полностью) наxep отладочный функционал из ядра.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

111. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 12-Май-18, 23:01 
> 100500 раз надо говорить майнтейнерам-пингвинам: Удаляйте (отключайте полностью) наxep
> отладочный функционал из ядра.

Угу, грохни себе из ядра все вплоть до symbols. И еще ASLR вруби. А потом когда что-то фигакнется, получишь в рыло какой-нибудь error 5 at address 0x80316282 - и удачи тебе понять что это за гамно вообще произошло. Ну примерно как в openwrt. Ядро конечно становится меньше, но дебажить - затрашешься.

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

86. "Неверная трактовка документации Intel привела к уязвимости в..."  +/
Сообщение от Аноним (??) on 10-Май-18, 22:03 
Ну это же интел, они вечно косячат
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

91. "Неверная трактовка документации Intel привела к уязвимости в..."  +1 +/
Сообщение от Аноним (??) on 11-Май-18, 03:14 
> Разработчики многих операционных систем полагали, что попадание инструкции MOV SS в точку останова приводит к генерации исключения #DB сразу после завершения MOV SS, но на деле исключение откладывается

Вот так новости... все кто отлаживал в DOS интерактивным отладчиком об этом знают, при нажатии “step" на mov ss указатель выполнения перескочит две инструкции потому что изменение сегмента стека блокирует прерывание

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

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

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


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