forum.opennet.ru - "Неверная трактовка документации Intel привела к уязвимости в..." (97)

"Неверная трактовка документации Intel привела к уязвимости в..."

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

"Неверная трактовка документации Intel привела к уязвимости в..."	+/–
Сообщение от opennews (?), 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.dev/opennews/art.shtml?num=48569
Ответить \| Правка \| Cообщить модератору

Оглавление

Неверная трактовка документации Intel привела к уязвимости в..., Anonymous Coward (?), 09:48 , 10-Май-18, (1) +62

Неверная трактовка документации Intel привела к уязвимости в..., Смузихлеб (?), 09:54 , 10-Май-18, (5) +3
Неверная трактовка документации Intel привела к уязвимости в..., anonymous (??), 13:17 , 10-Май-18, (49) –2

Неверная трактовка документации Intel привела к уязвимости в..., Anonymuos (?), 21:29 , 10-Май-18, (83) +1

Неверная трактовка документации Intel привела к уязвимости в..., Вареник (?), 02:33 , 11-Май-18, (90) +3

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 14:54 , 10-Май-18, (56) +5
Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 08:53 , 11-Май-18, (96)

Неверная трактовка документации привела к уязвимости в больш..., iCat (ok), 09:49 , 10-Май-18, (2) +6

Неверная трактовка документации привела к уязвимости в больш..., Смузихлеб (?), 09:55 , 10-Май-18, (6) +2

Неверная трактовка документации Intel привела к уязвимости в..., rscx64_ (?), 09:52 , 10-Май-18, (4) –4

Неверная трактовка документации Intel привела к уязвимости в..., Baz (?), 10:03 , 10-Май-18, (7) +15
Неверная трактовка документации Intel привела к уязвимости в..., ваш К.О. (?), 10:12 , 10-Май-18, (9) +4

Неверная трактовка документации Intel привела к уязвимости в..., недобрый (?), 19:32 , 15-Май-18, (113) –1

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 14:57 , 12-Май-18, (101)

Неверная трактовка документации Intel привела к уязвимости в..., ваш К.О. (?), 10:20 , 10-Май-18, (10)
Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 10:22 , 10-Май-18, (11)
Неверная трактовка документации Intel привела к уязвимости в..., Адекват (ok), 10:37 , 10-Май-18, (13)

Неверная трактовка документации Intel привела к уязвимости в..., F (?), 10:40 , 10-Май-18, (14) +7

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 10:44 , 10-Май-18, (15) –1

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 12:19 , 10-Май-18, (33) +1
Неверная трактовка документации Intel привела к уязвимости в..., Anon999 (ok), 12:55 , 10-Май-18, (39) +6
Неверная трактовка документации Intel привела к уязвимости в..., Ку (?), 13:08 , 10-Май-18, (45)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 13:38 , 10-Май-18, (51)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 05:39 , 11-Май-18, (92) +1
Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 15:01 , 12-Май-18, (102)

Неверная трактовка документации Intel привела к уязвимости в..., PereresusNeVlezaetBuggy (ok), 17:13 , 10-Май-18, (62) +3

Неверная трактовка документации Intel привела к уязвимости в..., Ку (?), 19:34 , 10-Май-18, (74)

Неверная трактовка документации Intel привела к уязвимости в..., PereresusNeVlezaetBuggy (ok), 20:17 , 10-Май-18, (75) +1

Неверная трактовка документации Intel привела к уязвимости в..., Ку (?), 21:12 , 10-Май-18, (80)

Неверная трактовка документации Intel привела к уязвимости в..., PereresusNeVlezaetBuggy (ok), 21:44 , 10-Май-18, (85) +1

Неверная трактовка документации Intel привела к уязвимости в..., Ку (?), 22:20 , 10-Май-18, (87)

Неверная трактовка документации Intel привела к уязвимости в..., PereresusNeVlezaetBuggy (ok), 22:56 , 10-Май-18, (89) +1

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 22:42 , 12-Май-18, (104) –1

Неверная трактовка документации Intel привела к уязвимости в..., PereresusNeVlezaetBuggy (ok), 23:49 , 12-Май-18, (112) +1

Неверная трактовка документации Intel привела к уязвимости в..., имя (?), 20:46 , 11-Май-18, (99)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 15:04 , 12-Май-18, (103)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 10:48 , 10-Май-18, (16)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 12:30 , 10-Май-18, (36) +12

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 12:46 , 10-Май-18, (38) +1

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 13:15 , 10-Май-18, (48) +3

Неверная трактовка документации Intel привела к уязвимости в..., пох (?), 14:15 , 10-Май-18, (54) –1

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 18:34 , 10-Май-18, (70)

Неверная трактовка документации Intel привела к уязвимости в..., пох (?), 20:50 , 10-Май-18, (78)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 21:15 , 10-Май-18, (81)

Неверная трактовка документации Intel привела к уязвимости в..., anomymous (?), 22:32 , 10-Май-18, (88) –1

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 22:47 , 12-Май-18, (105)

Неверная трактовка документации Intel привела к уязвимости в..., tensor (?), 10:52 , 10-Май-18, (17) +1

Неверная трактовка документации Intel привела к уязвимости в..., fi (ok), 13:15 , 10-Май-18, (47) +1

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 11:02 , 10-Май-18, (20)

Неверная трактовка документации Intel привела к уязвимости в..., КО (?), 11:20 , 10-Май-18, (25) +6

Неверная трактовка документации Intel привела к уязвимости в..., cat666 (ok), 11:32 , 10-Май-18, (27) +6

Неверная трактовка документации Intel привела к уязвимости в..., пох (?), 11:39 , 10-Май-18, (29) +6
Неверная трактовка документации Intel привела к уязвимости в..., A.Stahl (ok), 11:39 , 10-Май-18, (30) –2

Неверная трактовка документации Intel привела к уязвимости в..., Crazy Alex (ok), 17:27 , 10-Май-18, (65) +1

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 05:50 , 11-Май-18, (93)

Неверная трактовка документации Intel привела к уязвимости в..., КО (?), 15:25 , 11-Май-18, (98)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 11:38 , 10-Май-18, (28) +1
Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 11:42 , 10-Май-18, (32) +5

Неверная трактовка документации Intel привела к уязвимости в..., ПДК (?), 12:36 , 10-Май-18, (37)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 12:58 , 10-Май-18, (41) +5

Неверная трактовка документации Intel привела к уязвимости в..., Тыгра (?), 20:20 , 10-Май-18, (76) +1

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 21:24 , 10-Май-18, (82)

Неверная трактовка док..., Аноним (-), 12:55 , 10-Май-18, (40) –8

Неверная трактовка док..., анон (?), 13:03 , 10-Май-18, (43) +2

Неверная трактовка док..., Аноним (-), 22:49 , 12-Май-18, (106) +1

Неверная трактовка док..., Аноним (-), 13:11 , 10-Май-18, (46)

Неверная трактовка док..., Crazy Alex (ok), 17:31 , 10-Май-18, (66)

Неверная трактовка документации Intel привела к уязвимости в..., Клыкастый (ok), 13:00 , 10-Май-18, (42) +3

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 05:53 , 11-Май-18, (94)
Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 22:51 , 12-Май-18, (107) –1

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 13:08 , 10-Май-18, (44) –2

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 13:27 , 10-Май-18, (50)
Неверная трактовка документации Intel привела к уязвимости в..., пох (?), 14:05 , 10-Май-18, (52) –1

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 15:06 , 10-Май-18, (58)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 17:26 , 10-Май-18, (64)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 20:28 , 10-Май-18, (77)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 21:29 , 10-Май-18, (84)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 07:25 , 11-Май-18, (95)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 10:34 , 11-Май-18, (97)
Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 22:54 , 12-Май-18, (108)

Неверная трактовка документации Intel привела к уязвимости в..., Crazy Alex (ok), 17:33 , 10-Май-18, (67) +3

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 14:17 , 10-Май-18, (55)

Неверная трактовка документации Intel привела к уязвимости в..., КО (?), 15:01 , 10-Май-18, (57)
Неверная трактовка документации Intel привела к уязвимости в..., Аноне (?), 16:06 , 10-Май-18, (61) +2

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 17:41 , 10-Май-18, (68) +1

Неверная трактовка документации Intel привела к уязвимости в..., pavlinux (ok), 19:07 , 10-Май-18, (73)

Неверная трактовка документации Intel привела к уязвимости в..., пох (?), 20:52 , 10-Май-18, (79) –2

Неверная трактовка документации Intel привела к уязвимости в..., pavlinux (ok), 04:25 , 12-Май-18, (100)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 22:57 , 12-Май-18, (110)

Неверная трактовка документации Intel привела к уязвимости в..., pavlinux (ok), 16:48 , 07-Июл-18, (114)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 22:55 , 12-Май-18, (109)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 15:48 , 10-Май-18, (60)
Неверная трактовка документации Intel привела к уязвимости в..., IZh. (?), 18:18 , 10-Май-18, (69) +1
Неверная трактовка документации Intel привела к уязвимости в..., pavlinux (ok), 19:05 , 10-Май-18, (72) +2

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 23:01 , 12-Май-18, (111)

Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 22:03 , 10-Май-18, (86)
Неверная трактовка документации Intel привела к уязвимости в..., Аноним (-), 03:14 , 11-Май-18, (91) +1

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

1. "Неверная трактовка документации Intel привела к уязвимости в..." +62 +/–

Сообщение от Anonymous Coward (?), 10-Май-18, 09:48

> OpenBSD и NetBSD не подвержены уязвимости.
Срочно в новости: авторы OpenBSD и NetBSD умеют читать!

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

5. "Неверная трактовка документации Intel привела к уязвимости в..." +3 +/–

Сообщение от Смузихлеб (?), 10-Май-18, 09:54

Может очень ленивые в отличии от фронтендеров?

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

49. "Неверная трактовка документации Intel привела к уязвимости в..." –2 +/–

Сообщение от anonymous (??), 10-Май-18, 13:17

Еще в AMD умеют читать

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

83. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от Anonymuos (?), 10-Май-18, 21:29

> Еще в AMD умеют читать
>Проблема проявляется на 64-разрядных процессорах x86 (AMD и Intel)
Разве?

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

90. "Неверная трактовка документации Intel привела к уязвимости в..." +3 +/–

Сообщение от Вареник (?), 11-Май-18, 02:33

AMD совместим с Intel. Все нормально.

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

56. "Неверная трактовка документации Intel привела к уязвимости в..." +5 +/–

Сообщение от Аноним (-), 10-Май-18, 14:54

Видимо, при реализации архитектуры AMD64 они, как ни странно,пользовались документацией от AMD....

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

96. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 11-Май-18, 08:53

> OpenBSD и NetBSD не подвержены уязвимости.
А где ссылка на пруф?

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

2. "Неверная трактовка документации привела к уязвимости в больш..." +6 +/–

Сообщение от iCat (ok), 10-Май-18, 09:49

Вот это номер...
Получается, что формальное следование формулярам приводит к опсным последствиям.

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

6. "Неверная трактовка документации привела к уязвимости в больш..." +2 +/–

Сообщение от Смузихлеб (?), 10-Май-18, 09:55

> Вот это номер...
> Получается, что формальное следование формулярам приводит к опсным последствиям.
В RFC те же грабли, даже неточности в BGP.

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

4. "Неверная трактовка документации Intel привела к уязвимости в..." –4 +/–

Сообщение от rscx64_ (?), 10-Май-18, 09:52

почему ядро фрибсд даже менее защищено чем линукс?

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

7. "Неверная трактовка документации Intel привела к уязвимости в..." +15 +/–

Сообщение от Baz (?), 10-Май-18, 10:03

потому, что их любимое занятие - патчить KDE #шутка

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

9. "Неверная трактовка документации Intel привела к уязвимости в..." +4 +/–

Сообщение от ваш К.О. (?), 10-Май-18, 10:12

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

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

113. "Неверная трактовка документации Intel привела к уязвимости в..." –1 +/–

Сообщение от недобрый (?), 15-Май-18, 19:32

> зато performance hit от наличия кода для pti у них околонулевой
Нет.
> механизмы передачи управления ядру устроены совершенно иначе
Нет.

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

101. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 12-Май-18, 14:57

>  почему ядро фрибсд даже менее защищено чем линукс?
Потому что нет никаких предпосылок для этого.

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

10. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от ваш К.О. (?), 10-Май-18, 10:20

из занятного: joyent заявил что не подвержен проблеме (а значит и все, что illumos-based, тоже)
oracle жует сопли (то есть, вполне возможно что vbox уязвим, и патчей у них нет)

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

11. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 10:22

Дыры Intel SGX подоспели https://tches.iacr.org/index.php/TCHES/article/view/879
Привет Intel с его Asylo...

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

13. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Адекват (ok), 10-Май-18, 10:37

так погнал малеха.
А на x32 ОС эта проблема тоже будет ? или нужна x64 ОС, чтобы бага сработала ?

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

14. "Неверная трактовка документации Intel привела к уязвимости в..." +7 +/–

Сообщение от F (?), 10-Май-18, 10:40

(Здесь ролик про Гитлера в бункере, который устраивает разнос разработчикам процов и доки)

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

15. "Неверная трактовка документации Intel привела к уязвимости в..." –1 +/–

Сообщение от Аноним (-), 10-Май-18, 10:44

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

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

33. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от Аноним (-), 10-Май-18, 12:19

Узкоспециализированных это каких? Смысл тогда держать 2 системы если постоянно нужны "узкоспециализированные" задачи?

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

39. "Неверная трактовка документации Intel привела к уязвимости в..." +6 +/–

Сообщение от Anon999 (ok), 10-Май-18, 12:55

Винда для узкоспециализирываных задач.

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

45. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Ку (?), 10-Май-18, 13:08

1)Нет нормального прикладного десктопного софта + мало пакетов в целом.
2)Иксы, на глаз видно, как медленней работают.
3)UFS работает гораздо медленней ext4.
4)Виртуализации все еще нет.
5)Апдейты каждые полгода вручную.
.. ит.п.
Система простая и самобытная, но, увы!, на десктоп полноценный не тянет.
Сама система обновлялась бы с репов, а вся прикладуха типа flatpack или snap, было бы круто.

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

51. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 13:38

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

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

92. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от Аноним (-), 11-Май-18, 05:39

Абсолютно согласен. Должны быть такие загончики, как OpenBSD, для любителей.

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

102. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 12-Май-18, 15:01

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

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

62. "Неверная трактовка документации Intel привела к уязвимости в..." +3 +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 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 привела к уязвимости в..." +/–

Сообщение от Ку (?), 10-Май-18, 19:34

Благодарю за адекватные ответы, серьезно.
Видяха Intel, ноут 12 года. Читал, что Иксы патченые у них, мбыть из-за этого.
У Softupdates есть свои минусы, да и пишут, что в основном влияет на скорость создания\удаления файлов. Однако я наблюдал, что приложения стартуют гораздо медленней. В целом было видно, что производительность упала по сравнению с пингвином. Может, действительно, что-то можно было подркутить, но я не осилил.
По мне так лучше когда в репах только все системное. ОС это чугунная неубиваемая сковорода, а прикладуха, то что на ней жаришь. И здесь мне больше импанируют более контейнеры. Установил, не надо - снес, + не нужно ждать обновления в репах. Чтобы однажды установленная ОС работала до смерти железа и оставалась всегда возможность запускать свежую прикладуху.
Поэтому сижу на убунте ЛТС, свежий софт + 5 лет можно не париться с обновлением. Роллинг страдает тем, что может однажды прибить систему, ибо постоянно перелопачивается все и вся. Поэтому на рабочей машине он противопоказан.
Как обновить безопасно Опенка? Если умрет при апдейте, есть возможность откатиться?

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

75. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 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 привела к уязвимости в..." +/–

Сообщение от Ку (?), 10-Май-18, 21:12

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

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

85. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 10-Май-18, 21:44

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

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

87. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Ку (?), 10-Май-18, 22:20

Джаву вращаете на Опенке?
А откуда такая политика, в чем профит?
Спрашиваю, т.к. сам на ней разрабатываю уже лет 12.
В принципе внутри можно что угодно использовать, но вот заказчики не поймут такого выбора.
Убунта ЛТС, ну центос, не более.

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

89. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 10-Май-18, 22:56

> Джаву вращаете на Опенке?
> А откуда такая политика, в чем профит?
Политика простая: зоопарк обслуживать сложнее, чем однородную среду. Раньше, например, Java-приложения бегали под CentOS; после нескольких смертей файловых систем (ext4 и ext3) на ровном месте мне это надоело, и они тоже переехали на OpenBSD.
> Спрашиваю, т.к. сам на ней разрабатываю уже лет 12.
Сочувствую, мне тоже иногда приходится. :) Кстати, IDEA работает, но не слишком резво — в основном из-за отсутствия нативных библиотек. Это вопрос решаемый, конечно, но мне оно пока что не настолько надо, чтобы переделать порт под полный сборочный цикл, ну и не только мне, видимо. А так — собрать и потыкать проекты можно.
> В принципе внутри можно что угодно использовать, но вот заказчики не поймут
> такого выбора.
> Убунта ЛТС, ну центос, не более.
Если главное, чтобы LTS было, то есть конторы, готовые поддерживать OpenBSD и после официальных сроков устаревания релизов. Любой каприз за ваши деньги, как говорится. :)
А так — да, философия OpenBSD включает в себя предпочтение эволюции скачкообразному развитию. Не хочу разводить флуд на тему что правильнее. :)

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

104. "Неверная трактовка документации Intel привела к уязвимости в..." –1 +/–

Сообщение от Аноним (-), 12-Май-18, 22:42

> Помимо опёнка у нас ряд сервисов завязан на Windows Server,
И ты, Брут?
> На ноутбуке держу родную винду на особые случаи
...таки даже ты дуалбутчик?
>  а программа прошивки есть только под Windows).
А я таки перелил древний телефон из вайна в порядке научного эксперимента.

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

112. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 12-Май-18, 23:49

>> Помимо опёнка у нас ряд сервисов завязан на Windows Server,
> И ты, Брут?
>> На ноутбуке держу родную винду на особые случаи
> ...таки даже ты дуалбутчик?
>>  а программа прошивки есть только под Windows).
> А я таки перелил древний телефон из вайна в порядке научного эксперимента.
Иногда бывают вещи посерьёзнее (да и поинтереснее) древних телефонов. И, кстати, да, под OpenBSD wine отсутствует.
А вообще смешно смотрятся комментарии «и ты, Брут» вместе с рассказом об использовании wine. ;)

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

99. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от имя (?), 11-Май-18, 20:46

> Виртуализации все еще нет.
Тео, мягко говоря, совсем не в восторге от неё: https://marc.info/?l=openbsd-misc&m=119318909016582
Так что расчитывать на неё я бы не советовал.

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

103. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 12-Май-18, 15:04

А он уже прекратил вымогать деньги за электричество на свой парк серверов? А то прикольно умничать за чужой счет. А многие другие себе такое пижонство позволить не могут, вот и любят виртуализацию :)

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

16. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 10:48

>64-разрядных процессорах AMD
>Intel 64
как это понимать?

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

36. "Неверная трактовка документации Intel привела к уязвимости в..." +12 +/–

Сообщение от Аноним (-), 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 +/–

Сообщение от Аноним (-), 10-Май-18, 12:46

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

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

48. "Неверная трактовка документации Intel привела к уязвимости в..." +3 +/–

Сообщение от Аноним (-), 10-Май-18, 13:15

Ну не все в моем рассказе наверное правда," я художник я так вижу". В частности про S3TC, это оказывается Microsoft для DirectX лицензировала метод сжатия и назвала его DXTC, наверное она тогда все вкусности в свой api тащила, потому как вокруг конкуренты в лице OGL и проприетарых Glide и MeTaL. Кстати только в прошлом году на S3TC истекли патенты (20 лет) и буквально несколько месяцев назад это древнее сжатие текстур стало доступно в mesa, хотя уже есть свободные и более эффективные алгоритмы сжатия текстур, но вроде для старых игр нужно.

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

54. "Неверная трактовка документации Intel привела к уязвимости в..." –1 +/–

Сообщение от пох (?), 10-Май-18, 14:15

> В общем Intel решила создать новую ISA IA-64, потеряв обратную совместимость
> с x86. Из этого ничего не вышло, рынок не поддержал, старый
наоборот, сохранив, но кривым полу-софтовым способом. Поэтому "рынок" в лице не особенно разбирающихся в технике топтопов решил ничего не делать, "оно же совместимо", а потом пошли жалобы что "что-то оно в разы медленнее чем на i86, за в разы больше денег". Кто бы мог подумать, ну правда.
И тут amd воспользовалась моментом, сделав кривое-косое, но позволяющее ничего не менять, решеньице, не имеющее явных проблем с производительностью.
топ-топы получили возможность еще лет десять рассказывать, что 64 бита дорого и ненужно, и кормить
меньше индусско-подданных. А те, кому уже было совсем тесно в 32 - возможность кое-как работать.
В общем, закон рынка - из всех возможных решений всегда побеждает технически наиболее уродливое.

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

70. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 18:34

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

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

78. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от пох (?), 10-Май-18, 20:50

ну а в чем проблема? У интела параллельность инструкций - аж с 486, хоть ему до настоящего vliw как до китая раком.
Ну да, разные. Ну да, вручную это оптимизировать - удел сильно долбанутых. В принципе, и не предназначалось для подбора вручную. (ну да, и компиляторы были - то еще гуано. И ничего, никак на продажи не повлияло, пипл все схавал и добавки просил ;-)

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

81. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 21:15

Ничего хорошего от IA-64 не случилось бы, почитал статьи о тех годах, многие пишут что intel сделал несовместимую архитектуру чтоб убрать конкрецию с AMD, это был венодр лок, они бы не лицензировали IA-64. Даже сейчас когда вдруг появляется информация что кто-то готов сделать x86 транслятор для серверных ARM, intel начинает в прессе заявлять про свою интеллектуальную собственность на x86.
Даже если x86 плох, то сейчас уже есть OpenSpark и risc-v, глядишь скоро можно будет купить в свободной продаже.

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

88. "Неверная трактовка документации Intel привела к уязвимости в..." –1 +/–

Сообщение от anomymous (?), 10-Май-18, 22:32

Закон рынка: теоретики идут лесом. Их "правильные прямые" поделки в итоге либо не взлетают, либо оказываются нерентабельны, либо ещё чего. Отличный пример "ещё чего" от теоретиков - IPv6.

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

105. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 12-Май-18, 22:47

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

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

17. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от tensor (?), 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), 10-Май-18, 13:15

Действительно какая-то фигня про AMD написано, в самом CVE-2018-8897 только Intel

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

20. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 11:02

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

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

25. "Неверная трактовка документации Intel привела к уязвимости в..." +6 +/–

Сообщение от КО (?), 10-Май-18, 11:20

Хорошо если двояко, только двояко - это до изменения регистра или после.
А предположение, что исключение срабатывает не в сбойной инструкции, а в следующей (и предварительно установив как нив в чем не бывало контекст этой следующей инструкции) это уже за гранью добра и зла.

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

27. "Неверная трактовка документации Intel привела к уязвимости в..." +6 +/–

Сообщение от cat666 (ok), 10-Май-18, 11:32

Со стороны выглядит как - "Мы не виноваты, это вы нас не правильно поняли..."

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

29. "Неверная трактовка документации Intel привела к уязвимости в..." +6 +/–

Сообщение от пох (?), 10-Май-18, 11:39

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

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

30. "Неверная трактовка документации Intel привела к уязвимости в..." –2 +/–

Сообщение от A.Stahl (ok), 10-Май-18, 11:39

А со стороны Интела это выглядит так: "Эти придурки не удосужились проверить результат, даже при не совсем однозначной документации"

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

65. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от Crazy Alex (ok), 10-Май-18, 17:27

Если так много "придурков" (обычно вполне компетентных) не удосужилось - видать, всё же не в них дело

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

93. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 11-Май-18, 05:50

так себе аргументик, про миллиард мух

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

98. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от КО (?), 11-Май-18, 15:25

Это выглядит как,
Оказывается надо было перебрать все комбинации команд, чтобы выяснить, что оказывается можно установить точку останова из отладчика работающего в ring3 на код в ring0 и отладчик вуаля в ring0.
Всего-то в одной (хотя и не гарантированно, что в одной, просто до других видать еще очумелые ручки не добрались) комбинации из 100500.

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

28. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от Аноним (-), 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 +/–

Сообщение от Аноним (-), 10-Май-18, 11:42

По-моему это бэкдор.

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

37. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от ПДК (?), 10-Май-18, 12:36

В документации?

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

41. "Неверная трактовка документации Intel привела к уязвимости в..." +5 +/–

Сообщение от Аноним (-), 10-Май-18, 12:58

Почему бы и нет? Новый уровень. Никто и не заподозрит.

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

76. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от Тыгра (?), 10-Май-18, 20:20

Чорд, это тогда самый старый бэкдор у интела - эту особенность mov ss я помню ещё кажется на 286 процах.

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

82. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 21:24

В микроархитектуре. Ни один здравомыслящий человек не подумает, что добронамеренные и здравомыслящие разработчики процессора могли допустить такое и что в документации правда написана и что можно реально из юзермода свою функцию выполнить в кернелмоде, если разрабы не озаботились активным противодействием этому. Отсюда и уязвимости - нормальные разработчики ОС прочитали документацию, покрутили у виска, подумали что в документации ошибка и запилили в соответствии со своими представлениями, паранойные же проверили, выложили кирпичей и запилили противодействие, засрав свой код.

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

40. "Неверная трактовка док..." –8 +/–

Сообщение от Аноним (-), 10-Май-18, 12:55

NetBSD not affected. Собственно вот почему безопасники предпочитают бсд в качестве дешевых firewall, и для хостинга php страничек. А не пургеникс ваш. Удел линукса - это смартфоны и китайские планшеты!

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

43. "Неверная трактовка док..." +2 +/–

Сообщение от анон (?), 10-Май-18, 13:03

еще суперкомпьютеры и сетевое оборудование ну и еще немного серверов

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

106. "Неверная трактовка док..." +1 +/–

Сообщение от Аноним (-), 12-Май-18, 22:49

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

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

46. "Неверная трактовка док..." +/–

Сообщение от Аноним (-), 10-Май-18, 13:11

На самом деле NetBSD (в отличие от других BSD) неплох, тк он мне больше всех похож на классический Unix. Если бы все было так же хорошо с поддержкой железа, как в линуксе, то использовал бы только его.

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

66. "Неверная трактовка док..." +/–

Сообщение от Crazy Alex (ok), 10-Май-18, 17:31

Так себе аргумент - со времён "классического Unix" поменялось примерно всё, начиная со скоростей и заканчивая разными USB-устройствами и лэптопами. И модель пользования тоже поменялась радикально. Хотя всякие убунты с федорами да гномокеды я и сам не выдерживаю - это уже виндомакось какая-то - хрен угадаешь, что когда оно сотворит. Но подозреваю, что баланс всё же не там, где NetBSD.
Ну и BSD-лицензия - это отдельное зло.

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

42. "Неверная трактовка документации Intel привела к уязвимости в..." +3 +/–

Сообщение от Клыкастый (ok), 10-Май-18, 13:00

>  OpenBSD и NetBSD не подвержены уязвимости.
а говорили - masturbating monkeys... а оно вона как...

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

94. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 11-Май-18, 05:53

>Для решения проблемы в контексте ядра следовало очистить значение регистра DR6, определить обработчик #DB в стиле обработчика NMI или подменить стек при помощи IST (Interrupt Stack Table).
т.е. в опенке и нетбсд так было сделано изначально? Или они просто не использовали сабжевую функциоанльность процессора?

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

107. "Неверная трактовка документации Intel привела к уязвимости в..." –1 +/–

Сообщение от Аноним (-), 12-Май-18, 22:51

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

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

44. "Неверная трактовка документации Intel привела к уязвимости в..." –2 +/–

Сообщение от Аноним (-), 10-Май-18, 13:08

[Параноик мод он]
Я, конечно, понимаю, что интеловцы косячат, но зашкаливающее количество уязвимостей, которые в последнее время раскрываются чуть ли не каждый день, наводит на мысли о развернутой кампании по дискредитации интела. Уверен, если покопаться в амдшных процах, и не такое всплыть может, но все сосредоточены именно на интеле.
Да, я знаю, что на опеннете принято люто-бешено ненавидеть все интеловское, но все же странно, не?
[Параноик мод офф]

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

50. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 13:27

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

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

52. "Неверная трактовка документации Intel привела к уязвимости в..." –1 +/–

Сообщение от пох (?), 10-Май-18, 14:05

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

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

58. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 15:06

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

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

64. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 17:26

у спецслужб, семей, любовниц, агентуры какое-то особое оборудование без бэкдоров? или это контроль за спецслужбами?

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

77. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 20:28

Им то какая разница? Сами себя будут взламывать? Они работают на дядю Рокфеллера (утрирую), который им платит за слитые данные. Собственно и всё.

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

84. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 21:29

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

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

95. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 11-Май-18, 07:25

Ну смотри. То есть сидит такой хакер в АНБ идёт домой и взламывает свой компьютер? Зачем? Или его кто-то взламывает? Опять же - зачем? Он у всех на виду. Да и наверняка работа и личная жизнь отделена и никто не знает кто он на самом деле, так что для иностранных спецслужб он тоже малоинтересен. Не понимаю логики, потрудись объяснить.

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

97. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 11-Май-18, 10:34

Поясняю. Об этой байде скорее всего знали только те, для кого она была предназначена. А остальные до сегодняшнего момента не знали. Поэтому свои особо критические системы они укрепили, а некритические оставили как есть, риск их временной компрометации не перевешивает вред от раскрытия инфы об уязвимости шпионам других государств внутри анб.

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

108. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 12-Май-18, 22:54

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

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

67. "Неверная трактовка документации Intel привела к уязвимости в..." +3 +/–

Сообщение от Crazy Alex (ok), 10-Май-18, 17:33

Это нахывается "мода". кинулись ковырять интел - наковыряли, разумеется. Возьмутся за AMD или ARM/Qualcomm - и там будет то же самое. Процессоры делаются совсем на грани человеческих возможностей - и технологических, и интеллектуальных. То, что там будет куча багов - ожидаемо.

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

55. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 14:17

25-й кадр, в смысле 65-й бит в процессоре или 66-й уже, или что это?...
Уже не хочется покупать, ни интел, ни амд.
Слышал, что есть какие-то другие процессоры, но они пока-что доступны только для организаций. Кто нибудь знает, когда они будут выпускаться для частных потребителей?

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

57. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от КО (?), 10-Май-18, 15:01

Уже недолго... Там 82 бита в регистрах регистрового файла (80 бит под long double + 2 бита тегов), скоро будет доступен проц с 130 битными регистрами.

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

61. "Неверная трактовка документации Intel привела к уязвимости в..." +2 +/–

Сообщение от Аноне (?), 10-Май-18, 16:06

Эльбрус. Недавно вроде новость была про снижение цены и розницу, не помню...

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

68. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от Аноним (-), 10-Май-18, 17:41

> Эльбрус. Недавно вроде новость была про снижение цены и розницу, не помню...
Хорошая попытка, МЦСТ, но нет, ваши процессоры никому не нужны.

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

73. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от pavlinux (ok), 10-Май-18, 19:07

>> Эльбрус. Недавно вроде новость была про снижение цены и розницу, не помню...
> Хорошая попытка, МЦСТ, но нет, ваши процессоры никому не нужны.
На картинках-то хоть видел?

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

79. "Неверная трактовка документации Intel привела к уязвимости в..." –2 +/–

Сообщение от пох (?), 10-Май-18, 20:52

>> Хорошая попытка, МЦСТ, но нет, ваши процессоры никому не нужны.
> На картинках-то хоть видел?
ну я увидел, и чо? "собирает собственное ядро за 3.2 часа". Прекрасно.

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

100. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от pavlinux (ok), 12-Май-18, 04:25

>>> Хорошая попытка, МЦСТ, но нет, ваши процессоры никому не нужны.
>> На картинках-то хоть видел?
> ну я увидел, и чо? "собирает собственное ядро за 3.2 часа". Прекрасно.
Что там в ядре навключал?  А то у меня 16-ядерный Opteron убунтушное ядро часов 5 собирает.

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

110. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 12-Май-18, 22:57

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

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

114. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от pavlinux (ok), 07-Июл-18, 16:48

>> Что там в ядре навключал?  А то у меня 16-ядерный Opteron
>> убунтушное ядро часов 5 собирает.
> А чего так медленно то? FX 8-ядерный и то менее чем за
> 2 часа со всеми модулями чистую сборку обмолачивает.
Ядро убунту, дистрибутивное, со всеми плюшками, ....

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

109. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 12-Май-18, 22:55

> Эльбрус. Недавно вроде новость была про снижение цены и розницу, не помню...
Как там с открытым компилером дела? NDA при покупке по прежнему надо?

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

60. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 15:48

У Intel скоро будет как с талмудом - документация и трактовка, превосходящая по объёму документацию.

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

69. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от IZh. (?), 10-Май-18, 18:18

Ссылка на коммит: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

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

72. "Неверная трактовка документации Intel привела к уязвимости в..." +2 +/–

Сообщение от pavlinux (ok), 10-Май-18, 19:05

100500 раз надо говорить майнтейнерам-пингвинам: Удаляйте (отключайте полностью) наxep отладочный функционал из ядра.

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

111. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 12-Май-18, 23:01

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

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

86. "Неверная трактовка документации Intel привела к уязвимости в..." +/–

Сообщение от Аноним (-), 10-Май-18, 22:03

Ну это же интел, они вечно косячат

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

91. "Неверная трактовка документации Intel привела к уязвимости в..." +1 +/–

Сообщение от Аноним (-), 11-Май-18, 03:14

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

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Неверная трактовка документации Intel привела к уязвимости в..."	+62 +/–
Сообщение от Anonymous Coward (?), 10-Май-18, 09:48
> OpenBSD и NetBSD не подвержены уязвимости. Срочно в новости: авторы OpenBSD и NetBSD умеют читать!
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


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


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


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


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


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


	96. "Неверная трактовка документации Intel привела к уязвимости в..."	+/–
	Сообщение от Аноним (-), 11-Май-18, 08:53
	> OpenBSD и NetBSD не подвержены уязвимости. А где ссылка на пруф?
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору

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


	6. "Неверная трактовка документации привела к уязвимости в больш..."	+2 +/–
	Сообщение от Смузихлеб (?), 10-Май-18, 09:55
	> Вот это номер... > Получается, что формальное следование формулярам приводит к опсным последствиям. В RFC те же грабли, даже неточности в BGP.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору

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


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


	9. "Неверная трактовка документации Intel привела к уязвимости в..."	+4 +/–
	Сообщение от ваш К.О. (?), 10-Май-18, 10:12
	потому что обработка прерываний устроена по разному, линуксу случайно повезло. ("зато я раком не болею..." в смысле, зато performance hit от наличия кода для pti у них околонулевой. [кода, а не самого pti] Тоже потому, что механизмы передачи управления ядру устроены совершенно иначе.)
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	113. "Неверная трактовка документации Intel привела к уязвимости в..."	–1 +/–
	Сообщение от недобрый (?), 15-Май-18, 19:32
	> зато performance hit от наличия кода для pti у них околонулевой Нет. > механизмы передачи управления ядру устроены совершенно иначе Нет.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


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

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

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

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


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

15. "Неверная трактовка документации Intel привела к уязвимости в..."	–1 +/–
Сообщение от Аноним (-), 10-Май-18, 10:44
> OpenBSD... не подверж... уязвимости. OpenBSD многие годы меня очень радует. Только для домашнего использования не всегда удобна и под рукой всегда держишь какой-нибудь Дебиан для узкоспециализированных задач.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


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


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


	45. "Неверная трактовка документации Intel привела к уязвимости в..."	+/–
	Сообщение от Ку (?), 10-Май-18, 13:08
	1)Нет нормального прикладного десктопного софта + мало пакетов в целом. 2)Иксы, на глаз видно, как медленней работают. 3)UFS работает гораздо медленней ext4. 4)Виртуализации все еще нет. 5)Апдейты каждые полгода вручную. .. ит.п. Система простая и самобытная, но, увы!, на десктоп полноценный не тянет. Сама система обновлялась бы с репов, а вся прикладуха типа flatpack или snap, было бы круто.
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	51. "Неверная трактовка документации Intel привела к уязвимости в..."	+/–
	Сообщение от Аноним (-), 10-Май-18, 13:38
	> а вся прикладуха типа flatpack или > snap, было бы круто. Лучше не надо. А то куда мне валить, после того как у меня будет пол-системы в flatpack и занимать это дело будет гигов 100. Он же так и не научился шарить либы? Ну и накой он нужен?
	Ответить \| Правка \| ^ к родителю #45 \| Наверх \| Cообщить модератору


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


	102. "Неверная трактовка документации Intel привела к уязвимости в..."	+/–
	Сообщение от Аноним (-), 12-Май-18, 15:01
	> Лучше не надо. А то куда мне валить, после того как у > меня будет пол-системы в flatpack и занимать это дело будет гигов > 100. Он же так и не научился шарить либы? Ну и накой он нужен? Чтобы показать что сделать МАЗДАЙ можно даже из OpenBSD. Его, в принципе, из чего угодно можно сделать - достаточно притащить over 9000 библиотек, за которые никто не отвечает. И получится маздай, даже если это формально и не винда.
	Ответить \| Правка \| ^ к родителю #51 \| Наверх \| Cообщить модератору


	62. "Неверная трактовка документации Intel привела к уязвимости в..."	+3 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok), 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 привела к уязвимости в..."	+/–
	Сообщение от Ку (?), 10-Май-18, 19:34
	Благодарю за адекватные ответы, серьезно. Видяха Intel, ноут 12 года. Читал, что Иксы патченые у них, мбыть из-за этого. У Softupdates есть свои минусы, да и пишут, что в основном влияет на скорость создания\удаления файлов. Однако я наблюдал, что приложения стартуют гораздо медленней. В целом было видно, что производительность упала по сравнению с пингвином. Может, действительно, что-то можно было подркутить, но я не осилил. По мне так лучше когда в репах только все системное. ОС это чугунная неубиваемая сковорода, а прикладуха, то что на ней жаришь. И здесь мне больше импанируют более контейнеры. Установил, не надо - снес, + не нужно ждать обновления в репах. Чтобы однажды установленная ОС работала до смерти железа и оставалась всегда возможность запускать свежую прикладуху. Поэтому сижу на убунте ЛТС, свежий софт + 5 лет можно не париться с обновлением. Роллинг страдает тем, что может однажды прибить систему, ибо постоянно перелопачивается все и вся. Поэтому на рабочей машине он противопоказан. Как обновить безопасно Опенка? Если умрет при апдейте, есть возможность откатиться?
	Ответить \| Правка \| ^ к родителю #62 \| Наверх \| Cообщить модератору


	75. "Неверная трактовка документации Intel привела к уязвимости в..."	+1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok), 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 привела к уязвимости в..."	+/–
	Сообщение от Ку (?), 10-Май-18, 21:12
	Спасибо за инфу. Какие конкретно задачи вы решаете на Опенке и как давно? Что еще используете и для чего?
	Ответить \| Правка \| ^ к родителю #75 \| Наверх \| Cообщить модератору


	85. "Неверная трактовка документации Intel привела к уязвимости в..."	+1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok), 10-Май-18, 21:44
	> Спасибо за инфу. > Какие конкретно задачи вы решаете на Опенке и как давно? Если не считать моего личного ноутбука, являющегося основным компом для всего подряд (от разработки до ютубных котиков) уже лет... уже почти пятнадцать?! — фигасе время-то жизни пролетело... Так вот, если не считать периодически меняющийся ноутбук, то на базе опёнка у меня в отделе разработки, где работаю большую часть времени, развёрнута большая часть инфраструктуры: Java-based бизнес-ПО, wiki, мониторинг и т.д. В качестве платформы виртуализации (большая часть сервисов на виртуалках) используется VMware. > Что еще используете и для чего? Помимо опёнка у нас ряд сервисов завязан на Windows Server, плюс зоопарк на стендах (в основном специфические вещи на базе Linux). На ноутбуке держу родную винду на особые случаи (скажем, давеча столкнулся с необходимостью прошивать одну железку, а программа прошивки есть только под Windows).
	Ответить \| Правка \| ^ к родителю #80 \| Наверх \| Cообщить модератору