forum.opennet.ru

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

Оглавление

Разработчики OpenBSD развивают новый метод защиты стека, opennews (ok), 12-Мрт-18, (0) [смотреть все]

сначало полумал не плохая идея а теперь думаю ну и какой толк от этой проверк, X4asd (ok), 13:27 , 12-Мрт-18, (3) –7 //

Конечно так, ведь libc не общается с ядром и не использует сисколов , Anon4ik (?), 13:36 , 12-Мрт-18, (5) +12
Да пускай он как хочет делает, но ему придётся возиться с тем, чтобы указатель с, Ordu (ok), 15:13 , 12-Мрт-18, (19) +8 //

А потом они насыпают один практически бесплатный поверх другого и сумма, подоз, Crazy Alex (ok), 18:09 , 12-Мрт-18, (34) +2 //

Может быть Сложно сказать, потому что здесь ведь речь об одной проверке одного , Ordu (ok), 19:12 , 12-Мрт-18, (38) +3

Положительные эффекты суммируются, когда они есть IMHO, если ты не доверяешь за, Crazy Alex (ok), 21:52 , 12-Мрт-18, (50)

ЕРЕТИК , Аноним (-), 21:55 , 12-Мрт-18, (51)

Ага, еретик Я считаю, что если б тулкитчики сделали по-людски, расширив иксы ну, Crazy Alex (ok), 00:16 , 13-Мрт-18, (64) +1

Ну, так рассуждая, можно придти к выводу, что DOS лучшая операционная система, п, Ordu (ok), 23:11 , 12-Мрт-18, (60) +2

С моей точки зрения ответственность ядра - защищать ядро от юзерспейса и разных , Crazy Alex (ok), 00:29 , 13-Мрт-18, (68)

Ы Я заглянул в man mmap, и нашёл там такое MAP_STACK since Linux 2 6 27, Ordu (ok), 02:09 , 13-Мрт-18, (73)

И что Оно no-op, и фактически является костылём на случай чего Это никак не зн, Crazy Alex (ok), 03:33 , 13-Мрт-18, (75)

Какую другую песочницу Если речь идет о виртуальной машине то потеря производит, Аноним (-), 20:45 , 13-Мрт-18, (83)

Да любой из этих вариантов Накладные расходы получаем только там, где они нужны, Crazy Alex (ok), 19:00 , 17-Мрт-18, (93)

После Spectre я вдруг понял почему Тео говорил, что виртуалка это не о безопасно, Аноним (-), 22:55 , 13-Мрт-18, (84) +1

Определённо, Тео таки кое-что понимает x86 небезопасна по двум причинам фундамен, Anonymoustus (ok), 00:20 , 14-Мрт-18, (87)

У вас это предложение в утвердительной формеА вот тут с вами не согласенПри чем , Не тот Аноним (?), 05:06 , 14-Мрт-18, (89) –1

Можете добавить ещё причин Я выделил те, которые мне представляются имеющими зн, Anonymoustus (ok), 12:47 , 14-Мрт-18, (90)
Произвольно взятый отрывок из доступных в сети исходников Оффтопика-2000 CODE , Anonymoustus (ok), 12:58 , 14-Мрт-18, (91)

Так если ты не заметил, продакшны и не рвутся использовать OpenBSD По всем бенч, Аноним (-), 23:22 , 12-Мрт-18, (62) +1

А продакшены, которые решились на OpenBSD кучу девяток сделать, это не продакшен, Аноним (-), 00:18 , 13-Мрт-18, (65)

Не продакшны Ну есть где-то в углу рынка - и хрен с ним Их же совсем единицы , Crazy Alex (ok), 03:37 , 13-Мрт-18, (76) +2

Давайте просто в вашем сообщении заменим продакшен на мейнстрим и на этом пореши, Аноним (-), 23:15 , 13-Мрт-18, (86)

А это, в общем, одно и то же - мейнстрим таков, каков он есть, не из-за заговора, Crazy Alex (ok), 19:07 , 17-Мрт-18, (94)

Слой за слоем выходит армированная броня Или вы представляете себе один метод р, Anon4ik (?), 23:29 , 12-Мрт-18, (63)

Прям лирическое определение OpenBSD, Аноним (-), 00:19 , 13-Мрт-18, (66)
Если уж продолжать метафору - ну и тащат эту броню потом на гонки Ф-1, потому ка, Crazy Alex (ok), 00:31 , 13-Мрт-18, (69)
Это, в смысле, бронированная броня , Аноним (-), 16:58 , 13-Мрт-18, (82)

Наверно в смысле композитная костылями прошитая , а не цельнолитая, Аноним (-), 23:11 , 13-Мрт-18, (85)

Думать - это не твой конек , Аноним (-), 19:56 , 12-Мрт-18, (43)

не понятно что дает такая защита защищает от сбоев или еще от атак , x0r (??), 13:33 , 12-Мрт-18, (4) +1 //

Защита от выхода за границу По своей воли или по принуждению - без разницы , КО (?), 13:40 , 12-Мрт-18, (7)
От сбоев она не защищает, а наоборот 8212 добавляет их Как и любые другие ра, Аноним (-), 16:33 , 12-Мрт-18, (26) +1

не понимаю, чего разбушевались комментаторы Разве защищать не надо Без защиты , Аноним (-), 13:49 , 12-Мрт-18, (9) +1 //

Защищать может кому-то и надо Но, если перестараться, то получится концлагерь, , saahriktu (ok), 14:22 , 12-Мрт-18, (13) +2 //

Наверное когда один такой хакер советовал ставить другому пустой пароль, в его, Аноним (-), 14:29 , 12-Мрт-18, (15) +2 //

В те годы домашних и не только персоналок как таковых ещё не было Машины тогд, saahriktu (ok), 14:58 , 12-Мрт-18, (16)

Самая большая ошибка - приводить разнообразные факты из 70-ых по типу Знаете ли, Аноним (-), 15:07 , 12-Мрт-18, (18) +3
Это расхожее ложное рассуждение проистекающее от невежества Ведь и содержимое кв, ыы (?), 15:30 , 12-Мрт-18, (20) –5

На самом деле тут другой практический принцип Есть люди, которые готовы поддерж, saahriktu (ok), 17:01 , 12-Мрт-18, (31) –1

Ты даже в таких простейших вопросах умудряешься возводить категории, никак не со, Аноним (-), 18:01 , 12-Мрт-18, (33) –1

Это, между прочим, из философии проекта GNU Хозяева говорят, что они терпят э, saahriktu (ok), 18:18 , 12-Мрт-18, (35)

Хорошо, теперь установили, из какой литературки ты черпаешь свое черно-белое мир, Аноним (-), 18:44 , 12-Мрт-18, (36)

Заметьте, я нигде не утверждал, что, якобы, проприетарщики и проприетарщина - аб, saahriktu (ok), 19:26 , 12-Мрт-18, (40) +1

В свою очередь последователи Абд уль-Уаххаба рекомендуют не называть их ваххаби, Аноним (-), 19:41 , 12-Мрт-18, (41)

Что значит борьба На самом деле, и так многие люди одни и теже слова понимают, saahriktu (ok), 19:55 , 12-Мрт-18, (42)
То есть ты приходишь в магазин и просишь хлеба, а тебя вместо этого начинают стр, Аноним (-), 20:12 , 12-Мрт-18, (45) –1
В понимании простых слов, разумеется, многие люди сходятся, но и то с определённ, saahriktu (ok), 20:25 , 12-Мрт-18, (46) +1
Ты снова путаешь теплое с мягким Разные образы при слове хлеб никак не означают, angra (ok), 20:48 , 12-Мрт-18, (48) –2
Суть всё равно в том, что в одно и тоже слово разные люди вкладывают разные смыс, saahriktu (ok), 21:07 , 12-Мрт-18, (49) +1
Семибитное или ещё проще , Аноним (-), 15:18 , 15-Мрт-18, (92)
KISS В твоем понимании термины -- это пара вида имя - определение А на деле , Аноним (-), 00:42 , 13-Мрт-18, (70) +1
Это спекуляция на простых терминах Во-первых, даже если разные люди видят разно, saahriktu (ok), 01:36 , 13-Мрт-18, (72)
Это зависит не от определения слову дружба , а от ценностей и интересов конкрет, Аноним (-), 02:33 , 13-Мрт-18, (74)
Довольно рассуждений b Кража b - это когда что-то где-то убыло и где-то приб, Ne01eX (ok), 00:24 , 14-Мрт-18, (88)

Какой концлагерь Чем тебе это мешает Не выделить из кучи память под стек юзерс, Ordu (ok), 15:32 , 12-Мрт-18, (21) +1 //

Да и в 70-ых всё было ровно то же Или права на файлуху и процессы просто так за, Клыкастый (ok), 15:46 , 12-Мрт-18, (22) +1
Он забыл добавить, что среди хакеров семидесятых были в тренде лсд, хиппи, комму, Anonymoustus (ok), 16:04 , 12-Мрт-18, (24)

http www darwinawards com darwin darwin2016-02 html, Аноним (-), 22:51 , 12-Мрт-18, (55) –2

Каждому вызову по виртуальной машине , iZEN (ok), 14:01 , 12-Мрт-18, (10) //

И оркестрацию , Аноним (-), 14:12 , 12-Мрт-18, (12) +2
Вы вот шутите, а посмотрим что через 5 лет будет , Всем Анонимам Аноним (?), 15:46 , 12-Мрт-18, (23) +2 //

мясной fixed , pavlinux (ok), 22:52 , 12-Мрт-18, (56)

все это чушь скоро каждому вызову будет свой процессор аппаратный со своим ку, ыы (?), 14:58 , 12-Мрт-18, (17) –1 //

уже было, давно, первоадмин (?), 18:58 , 12-Мрт-18, (37)
Каждой переменной по процессору , pavlinux (ok), 22:53 , 12-Мрт-18, (57) –1 //

переменные - это рудимент зло порожденное порочной арихитектурой , ыы (?), 23:06 , 12-Мрт-18, (58) //

Партия Навального Свой вариант сложения двух чисел будет , pavlinux (ok), 23:11 , 12-Мрт-18, (59) –2

да вам знакомо понятие жесткой логики переменные ненужны частота ненужна ско, ыы (?), 23:19 , 12-Мрт-18, (61) +1

Как в этом случае создавать сложные приложения Для простоты обсужедния, начнем , VoDA (ok), 00:22 , 13-Мрт-18, (67) +1

Биологический компьютер Молекулярный компьютер , VimCoder (?), 00:48 , 13-Мрт-18, (71)

где песня, блин уже полгода ждём какие ещё стеки-шмеки, песню давай , бедный буратино (ok), 05:21 , 13-Мрт-18, (77)
неужели сложно зайти на репозиторий, если не помните свои же новостидля amd64, i, бедный буратино (ok), 05:22 , 13-Мрт-18, (78) //

Для прошлой ветки ветки были только amd64 и i386 https fastly cdn openbsd org , Аноним (-), 08:36 , 13-Мрт-18, (80)

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

3. "Разработчики OpenBSD развивают новый метод защиты стека" –7 +/–

Сообщение от X4asd (ok), 12-Мрт-18, 13:27

сначало полумал не плохая идея. а теперь думаю...
> При совершении системного вызова осуществляется проверка регистра с указателем на стек.
ну и какой толк от этой проверки?
гаджет вместо вызова системных вызовов -- будет делать библиотечный вызов libc..
всё на что остаётся надеяться -- это рандомизация адресов символов библиотеки

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

5. "Разработчики OpenBSD развивают новый метод защиты стека" +12 +/–

Сообщение от Anon4ik (?), 12-Мрт-18, 13:36

Конечно так, ведь libc не общается с ядром и не использует сисколов.

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

19. "Разработчики OpenBSD развивают новый метод защиты стека" +8 +/–

Сообщение от Ordu (ok), 12-Мрт-18, 15:13

> гаджет вместо вызова системных вызовов -- будет делать библиотечный вызов libc..
Да пускай он как хочет делает, но ему придётся возиться с тем, чтобы указатель стека указывал бы на стек, а не в кучу и не в код.
> какой толк от этой проверки?
Это практически бесплатный способ создать проблем вредоносному коду и снизить риски переполнения стека. Он не серебряная пуля, и не решит всех проблем выхода связанных с переполнением стека, но во многих ситуациях он справится.

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

34. "Разработчики OpenBSD развивают новый метод защиты стека" +2 +/–

Сообщение от Crazy Alex (ok), 12-Мрт-18, 18:09

А потом они насыпают один "практически бесплатный" поверх другого и сумма, подозреваю, выходит совсем не бесплатной.
В итоге всё это выгдялит как куча костылей.

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

38. "Разработчики OpenBSD развивают новый метод защиты стека" +3 +/–

Сообщение от Ordu (ok), 12-Мрт-18, 19:12

> А потом они насыпают один "практически бесплатный" поверх другого и сумма, подозреваю,
> выходит совсем не бесплатной.
Может быть. Сложно сказать, потому что здесь ведь речь об одной проверке одного бита в процессе сисколла, который сам по себе тормозной и содержит кучу проверок, поскольку ядерный код не склонен доверять юзерспейсу. Не факт, что дополнительную стоимость вообще возможно детектировать профайлером, она запросто может утонуть в статистическом шуме. Но, может быть, сумма выйдет не бесплатной.
Но положительные эффекты ведь тоже суммируются.
> В итоге всё это выгдялит как куча костылей.
Сложная система вообще выглядит как куча костылей. Но этот конкретный костыль мне нравится -- он не создаёт новых взаимосвязей между подсистемами, он очень хорошо вписывается в *nix'овую модель памяти. Вон, sbcl работает с памятью (и со стеком) сильно особенным образом, но его допилили вместе с go, который, видимо, на фоне всей этой его модели горутинов, тоже со стеком играется очень интересно. Допилили за несколько дней. Что собственно неудивительно, поскольку всё что надо было сделать -- это в нужном месте в вызов mmap добавить ещё один флаг.

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

50. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Crazy Alex (ok), 12-Мрт-18, 21:52

Положительные эффекты суммируются, когда они есть. IMHO, если ты не доверяешь запускаемому коду - заворачивай его в виртуалку или какую другую песочницу, где ты можешь настроить соотношение безопасность/геморрой. А если доверяешь - то защищать надо от тупости, и не более. А уж энфорсить в ядре защиту защиту приложений от их же дыр - это бред сивой кобылы. Кстати, то, что стек в результате заставляют выделять строго меммапом, мне не особо нравится. Впрочем, в линуксе, насколько я знаю, таким безумием не страдают (тем более, что это может сломать юзерспейс), так что, по большому счёту, можно не волноваться.

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

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

51. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Аноним (-), 12-Мрт-18, 21:55

> при этом расширялась костылями, как современные иксы, допустим.
ЕРЕТИК !!!

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

64. "Разработчики OpenBSD развивают новый метод защиты стека" +1 +/–

Сообщение от Crazy Alex (ok), 13-Мрт-18, 00:16

Ага, еретик. Я считаю, что если б тулкитчики сделали по-людски, расширив иксы нужными им функциями, а не плевались битмапами на каждый чих - мы бы сейчас имели и сетевую прозрачность, Ии шустрый универсальный GUI, и всё прочее - без необходимости изобретать велосипеды.

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

60. "Разработчики OpenBSD развивают новый метод защиты стека" +2 +/–

Сообщение от Ordu (ok), 12-Мрт-18, 23:11

> Положительные эффекты суммируются, когда они есть. IMHO, если ты не доверяешь запускаемому
> коду - заворачивай его в виртуалку или какую другую песочницу, где
> ты можешь настроить соотношение безопасность/геморрой. А если доверяешь - то защищать
> надо от тупости, и не более. А уж энфорсить в ядре
> защиту защиту приложений от их же дыр - это бред сивой
> кобылы.
Ну, так рассуждая, можно придти к выводу, что DOS лучшая операционная система, потому что она полностью доверяет приложениям. Они могут делать всё что угодно, и DOS им не мешает. Кстати да, когда я когда-то давно перелез из DOS в Windows, меня кошмарно раздражало, что Windows не пускает меня к видеопамяти, к контроллеру клавиатуры, к прерываниям таймера и прочим железкам. Со временем я привык и даже научился получать удовольствие от этих ограничений, но поначалу бесило ужасно: засунули меня в позорную ring3 песочницу, как ребёнка малого прям, и не выпускают оттуда. Одной из причин моего радостного перехода в linux было то, что в linux'е не нужно было платить денег за DDK, чтобы написать модуль, который будет по-взрослому работать в ring0. Но, как-то так выяснилось довольно быстро, что в ring0 мне делать нечего, и неинтересно. И я как ребёнок малый с тех пор сижу в песочнице ring3.
> Кстати, то, что стек в результате заставляют выделять строго меммапом,
> мне не особо нравится.
Не знаю даже почему. Потому, что память из mmap надо освобождать через munmap, а не через free? Ну, это неудобство, наверное, но я не думаю, что какое-то особое: все эти развлечения со стеком всё равно требуют либо asm'а, либо этих дурацких костыльных API, типа setjmp/longjmp или makecontext, то есть вокруг переключения контекстов по-любому приходится устраивать какие-то особые пляски с бубном, поэтому если добавить в эти пляски ещё и ритуал вызова munmap, вместо free, то это не сделает ситуацию хуже.
Я пользовался mmap и с другими целями -- чтобы не выделять из кучи больших кусков. При помощи malloc получается почти то же самое, но с лишними посредниками в виде алгоритмов кучи, и с невозможностью потом отдать память обратно системе. Ещё я использовал его, чтобы файлы открывать -- если забить на переносимость программы на железо с другим endianess, то очень удобно бинарный файл открыть через mmap, привести указатель к типу struct my_binary_file_format, и работать потом с результатом, не парясь на вычитывание из FILE* одного поля за другим, и в то же время подгружая в память с диска только то, что надо. Так вот, я не упомню, чтобы необходимость использования munmap вместо free создавала каких-либо проблем, даже несмотря на то, что всё это происходило в C, где нет возможности создать тип параметризованный аллокатором, с тем чтобы свалить на компилятор проблемы выбора между free и munmap.
> Сложная система выглядит как куча костылей, когда она используется за пределами тех
> областей, для которых предназначена,
Может быть. Но пускай в OpenBSD первой кинет камень та сложная система, которая не выходила за пределы своей области предназначения.

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

68. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Crazy Alex (ok), 13-Мрт-18, 00:29

С моей точки зрения ответственность ядра - защищать ядро от юзерспейса и разных пользователей друг от друга. Всё остальное должно реализовываться поверх и по необходимости. Собственно, так оно традиционно и используется - как создаются отдельные пользователи для всяких веб-серверов и подобного. Даже то, что сверху накинули cgroups и capabilities прицнипиально это не меняет - конечной единицей остаётся процесс. А вот когда начинаются NX-биты на данные, подобные ограничения на стек и так далее - это уже лишнее, что, как минимум, должно быть опциональным - это личное дело приложения.
Конкретно со стеком - понятия не имею, но наверняка найдётся пара-тройка экзотических случаев, когда таки удобно использовать под стек чёрт знает что.
Что до OpenBSD - не уверен, что у неё вообще область применения есть.

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

73. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Ordu (ok), 13-Мрт-18, 02:09

> Впрочем, в линуксе, насколько я знаю, таким безумием не страдают (тем более, что это может сломать юзерспейс), так что, по большому счёту, можно не волноваться.
Ы. Я заглянул в man mmap, и нашёл там такое:
       MAP_STACK (since Linux 2.6.27)
              Allocate  the  mapping  at  an address suitable for a process or
              thread stack.  This flag is currently a no-op, but  is  used  in
              the glibc threading implementation so that if some architectures
              require special treatment for  stack  allocations,  support  can
              later be transparently implemented for glibc.
Это правда, судя по описанию, создано не для софтварной защиты, а для железной -- на случай чего-нибудь в стиле особо экзотической не-гарвардской архитектуры, где память под стек особенная.

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

75. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Crazy Alex (ok), 13-Мрт-18, 03:33

И что? Оно no-op, и фактически является костылём на случай чего. Это никак не значит, что кто-то рискнёт убить софтину за то, что она создала стек без этой плюшки. Разве что Линус помрёт и его место займёт кто-то странный.
Под "безумием" я имел в виду вмешательство в личные дела юзерленда а не хинт, созданный на всякий случай в замшелом году и никак не применяемый.

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

83. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Аноним (-), 13-Мрт-18, 20:45

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

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

93. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Crazy Alex (ok), 17-Мрт-18, 19:00

Да любой из этих вариантов. Накладные расходы получаем только там, где они нужны. Как в плюсах - "платишь за то, что используешь"

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

84. "Разработчики OpenBSD развивают новый метод защиты стека" +1 +/–

Сообщение от Аноним (-), 13-Мрт-18, 22:55

> IMHO, если ты не доверяешь запускаемому
> коду - заворачивай его в виртуалку или какую другую песочницу, где
> ты можешь настроить соотношение безопасность/геморрой.
После Spectre я вдруг понял почему Тео говорил, что виртуалка это не о безопасности. А после плевков Тео в сторону Core2Duo, с его кучей Erarata, у меня возникли мысли, что наверно Тео что-то там понимает и даже видимо уверенно прав. Жаль не хватает квалификации заценить всю его крутизну, если она есть. Хотя, как я понял, он утверждает, что на x86 невозможно построить гарантированно безопасную систему

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

87. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Anonymoustus (ok), 14-Мрт-18, 00:20

Определённо, Тео таки кое-что понимает.

x86 небезопасна по двум причинам фундаментального свойства.
Во-первых, из-за костылей и подпорок внутри себя, которыми её оборудовали для обратной совместимости с окаменелыми древностями доисторического программирования на перфокартах. Когда-то это было нужно, но вот после появления на свет OS/2 и NT, как по мне, следовало рвать и резать связи со старым по живому и строить домик на новом фундаменте. Они (Штеуд), кстати, делали такие попытки, да люди не поняли, не оценили.
Во-вторых, даже те средства обеспечения безопасности, которые в ней есть, программеры не используют, либо используют недостаточно, либо используют неправильно. По каким-то своим эзотерическим причинам, в которых стесняются признаться публике.

Сама Интел знает недостатки своих продуктов, и они неоднократно предлагали радикальные решения, но требующие разрыва с прошлым, смены железа и парадигм мышления и работы. Я не только про Итаниум, но и про него. Что же ответил рынок? А рынок отверг новые, хорошие правильные решения, продолжая чавкать протухшей x86ятиной. ИЧХ, даже открывшиеся уязвимости и проблемы с безопасностью не склоняют людей сделать выводы.

Из истории неудачных попыток уйти от сабжа:
https://en.wikipedia.org/wiki/Intel_iAPX_432
https://en.wikipedia.org/wiki/Intel_i860

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

89. "Разработчики OpenBSD развивают новый метод защиты стека" –1 +/–

Сообщение от Не тот Аноним (?), 14-Мрт-18, 05:06

> x86 небезопасна по двум причинам фундаментального свойства.
У вас это предложение в утвердительной форме
> Во-вторых, даже те средства обеспечения безопасности, которые в ней есть, программеры не
> используют, либо используют недостаточно, либо используют неправильно. По каким-то своим
> эзотерическим причинам, в которых стесняются признаться публике.
А вот тут с вами не согласен
При чем здесть программисты, если
https://webcache.googleusercontent.com/search?q=cache:ArAOiu...
И очень даже не стесняются признаться публике в какой помойной яме сидят
> Сама Интел знает недостатки своих продуктов, и они неоднократно предлагали радикальные
> решения, но требующие разрыва с прошлым, смены железа и парадигм мышления
> и работы.
> Из истории неудачных попыток уйти от сабжа:
> https://en.wikipedia.org/wiki/Intel_iAPX_432
> https://en.wikipedia.org/wiki/Intel_i860
А ΑΡΜ и MIPS взлетел, когда пришло время
Когда важное програмное обеспечение станет настолько сложным, что не будет требоваться закрытия сырцов ( например по причине первостепенного значения инфраструктуры создания ПО), тогда можно менять архитектуру железа на любую, но есть одно но:
если рынок требует скорости на однопоточном гов<CENSORED>коде, а на безопасность можно спокойно положить (ну утечет база пользователей с паролями, и что?), вот что делать?
> Что же ответил рынок? А рынок отверг новые, хорошие правильные решения,
> продолжая чавкать протухшей x86ятиной. ИЧХ, даже открывшиеся уязвимости и проблемы с
> безопасностью не склоняют людей сделать выводы.
Менеджеры Интела мудро и дальновидно угадали, что построив свои процессоры со свойством уязвимости к Meltdown получат конкурентное преимущество перед AMD и, пока, последняя будет на вторых ролях можно загребать рынок под себя (главное держать руку на пульсе, чтобы вовремя сбросить акции)
Рынок тянется к максимизации прибыли, и увы наверно со скорбью надо иметь ввиду, что здесь не до инженерных правильных решений. Пока кто-то тормозит на правильных решениях, конкуренты успевают вас обанкротить.
Пока что мне видится надежда на изменение в майнерах, работающих на дырявых системах

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

90. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Anonymoustus (ok), 14-Мрт-18, 12:47

>> x86 небезопасна по двум причинам фундаментального свойства.
> У вас это предложение в утвердительной форме
Можете добавить ещё причин. Я выделил те, которые мне представляются имеющими значение в контексте дискуссии.

>> Во-вторых, даже те средства обеспечения безопасности, которые в ней есть, программеры не
>> используют, либо используют недостаточно, либо используют неправильно. По каким-то своим
>> эзотерическим причинам, в которых стесняются признаться публике.
> А вот тут с вами не согласен
> При чем здесть программисты, если
> https://webcache.googleusercontent.com/search?q=cache:ArAOiu...
> И очень даже не стесняются признаться публике в какой помойной яме сидят
Спасибо, я знаком с этой статьёй и согласен с её тоном и смыслом.
От этого много раз пытались уйти (и та же Intel, к слову, тоже, как я уже писал) — в RISC, VLIW, микроядро, наноядро, экзоядро, да и «гарвардская архитектура» есть. Но «рынок» — точнее, общественное сознание в целом, искалеченное наркозависимостью от «новинок моды» — не принимает решения, которые менее быстры в простом измеримом исчислении (тестовых «попугаях», грубо говоря), хотя более надёжны и безопасны. А ведь не тайна, что сложные вещи всегда имеют больше точек отказа, чем простые. Но так и живём с этим всем.

> А ΑΡΜ и MIPS взлетел, когда пришло время
Они взлетели _не там_, где формируется общественное мнение, а потому не оказывают влияния не смену общественного отношения к проблеме и, в результате, не влияют на работу по исправлению проблемы. Обыватель даже не знает этих слов. Зато про Intel знает каждый ребёнок.

> Когда важное програмное обеспечение станет настолько сложным, что не будет требоваться
> закрытия сырцов ( например по причине первостепенного значения инфраструктуры создания
> ПО), тогда можно менять архитектуру железа на любую, но есть одно
> но:
> если рынок требует скорости на однопоточном гов<CENSORED>коде, а на безопасность можно
> спокойно положить (ну утечет база пользователей с паролями, и что?), вот
> что делать?
Да. Именно в этом _проблема_, а не в собственно багах ПО и аппаратуры. И мы даже знаем имена тех, кого надо за неё благодарить: Intel и Microsoft. Они взрастили и воспитали этот менталитет на компьютерном рынке.
Что делать — _отказываться_ от использования фатально сложных технических систем. Упомянутые выше наноядро и экзоядро вполне решают одну из главных проблем небезопасности. Программистам стоило бы начать писать для MINIX, например, а не для модных JS-фреймфорков, потому что будущее строится сегодня.

>> Что же ответил рынок? А рынок отверг новые, хорошие правильные решения,
>> продолжая чавкать протухшей x86ятиной. ИЧХ, даже открывшиеся уязвимости и проблемы с
>> безопасностью не склоняют людей сделать выводы.
> Менеджеры Интела мудро и дальновидно угадали, что построив свои процессоры со свойством
> уязвимости к Meltdown получат конкурентное преимущество перед AMD и, пока, последняя
> будет на вторых ролях можно загребать рынок под себя (главное держать
> руку на пульсе, чтобы вовремя сбросить акции)
> Рынок тянется к максимизации прибыли, и увы наверно со скорбью надо иметь
> ввиду, что здесь не до инженерных правильных решений. Пока кто-то тормозит
> на правильных решениях, конкуренты успевают вас обанкротить.
Хм. Значит не только я думаю, что они делали всё это _сознательно_. Беглое знакомство с Core 2 и, особенно, с Nehalem не может, по моему мнению, не вызвать таких мыслей.

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

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

91. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Anonymoustus (ok), 14-Мрт-18, 12:58

Произвольно взятый отрывок из доступных в сети исходников Оффтопика-2000:

/*++
Abstract:
        This file implements the circular buffer management for
        input events.
        The circular buffer is described by a header,
        which resides in the beginning of the memory allocated when the
        buffer is created.  The header contains all of the
        per-buffer information, such as reader, writer, and
        reference counts, and also holds the pointers into
        the circular buffer proper.
        When the in and out pointers are equal, the circular buffer
        is empty.  When the in pointer trails the out pointer
        by 1, the buffer is full.  Thus, a 512 byte buffer can hold
        only 511 bytes; one byte is lost so that full and empty
        conditions can be distinguished. So that the user can
        put 512 bytes in a buffer that they created with a size
        of 512, we allow for this byte lost when allocating
        the memory.
--*/
Я убрал упоминание про автора и прочие конкретизирующие моменты, как и сам текст программы, оставил только описательную часть. Дальше там интересно, в том числе про хаки. :)
Иходники, в целом, хорошо прокомментированы и структурированы. Я не думаю, что есть какие-то иные причины скрывать это от человечества, кроме копирайтов. На этот кусок, например, было упомянуто о преемственности от соответствующей подсистемы OS/2.

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

62. "Разработчики OpenBSD развивают новый метод защиты стека" +1 +/–

Сообщение от Аноним (-), 12-Мрт-18, 23:22

> В итоге всё это выгдялит как куча костылей.
Так если ты не заметил, продакшны и не рвутся использовать OpenBSD. По всем бенчмаркам она относительно пингвина понятно где. Все быстренько прикидывают что лишние серваки придется оплатить - дальнейшее предсказуемо.

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

65. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Аноним (-), 13-Мрт-18, 00:18

>> В итоге всё это выгдялит как куча костылей.
> Так если ты не заметил, продакшны и не рвутся использовать OpenBSD. По
> всем бенчмаркам она относительно пингвина понятно где. Все быстренько прикидывают что
> лишние серваки придется оплатить - дальнейшее предсказуемо.
А продакшены, которые решились на OpenBSD кучу девяток сделать, это не продакшены?

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

76. "Разработчики OpenBSD развивают новый метод защиты стека" +2 +/–

Сообщение от Crazy Alex (ok), 13-Мрт-18, 03:37

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

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

86. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Аноним (-), 13-Мрт-18, 23:15

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

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

94. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Crazy Alex (ok), 17-Мрт-18, 19:07

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

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

63. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Anon4ik (?), 12-Мрт-18, 23:29

Слой за слоем выходит армированная броня. Или вы представляете себе один метод решающий все проблемы безопасности? (power off хороший метод, но не вариант)

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

66. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Аноним (-), 13-Мрт-18, 00:19

> Слой за слоем выходит армированная броня. Или вы представляете себе один метод
> решающий все проблемы безопасности? (power off хороший метод, но не вариант)
Прям лирическое определение OpenBSD

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

69. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Crazy Alex (ok), 13-Мрт-18, 00:31

Если уж продолжать метафору - ну и тащат эту броню потом на гонки Ф-1, потому как приросла и не снимается. Или сидят в ней в собственном доме в собственной спальне.

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

82. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Аноним (-), 13-Мрт-18, 16:58

> армированная броня
Это, в смысле, бронированная броня?

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

85. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Аноним (-), 13-Мрт-18, 23:11

>> армированная броня
> Это, в смысле, бронированная броня?
Наверно в смысле композитная (костылями прошитая), а не цельнолитая

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

43. "Разработчики OpenBSD развивают новый метод защиты стека" +/–

Сообщение от Аноним (-), 12-Мрт-18, 19:56

Думать - это не твой конек.

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

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

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

Партнёры:

Хостинг:

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

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

3. "Разработчики OpenBSD развивают новый метод защиты стека"	–7 +/–
Сообщение от X4asd (ok), 12-Мрт-18, 13:27
сначало полумал не плохая идея. а теперь думаю... > При совершении системного вызова осуществляется проверка регистра с указателем на стек. ну и какой толк от этой проверки? гаджет вместо вызова системных вызовов -- будет делать библиотечный вызов libc.. всё на что остаётся надеяться -- это рандомизация адресов символов библиотеки
Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Разработчики OpenBSD развивают новый метод защиты стека"	+12 +/–
	Сообщение от Anon4ik (?), 12-Мрт-18, 13:36
	Конечно так, ведь libc не общается с ядром и не использует сисколов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Разработчики OpenBSD развивают новый метод защиты стека"	+8 +/–
	Сообщение от Ordu (ok), 12-Мрт-18, 15:13
	> гаджет вместо вызова системных вызовов -- будет делать библиотечный вызов libc.. Да пускай он как хочет делает, но ему придётся возиться с тем, чтобы указатель стека указывал бы на стек, а не в кучу и не в код. > какой толк от этой проверки? Это практически бесплатный способ создать проблем вредоносному коду и снизить риски переполнения стека. Он не серебряная пуля, и не решит всех проблем выхода связанных с переполнением стека, но во многих ситуациях он справится.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	34. "Разработчики OpenBSD развивают новый метод защиты стека"	+2 +/–
	Сообщение от Crazy Alex (ok), 12-Мрт-18, 18:09
	А потом они насыпают один "практически бесплатный" поверх другого и сумма, подозреваю, выходит совсем не бесплатной. В итоге всё это выгдялит как куча костылей.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "Разработчики OpenBSD развивают новый метод защиты стека"	+3 +/–
	Сообщение от Ordu (ok), 12-Мрт-18, 19:12
	> А потом они насыпают один "практически бесплатный" поверх другого и сумма, подозреваю, > выходит совсем не бесплатной. Может быть. Сложно сказать, потому что здесь ведь речь об одной проверке одного бита в процессе сисколла, который сам по себе тормозной и содержит кучу проверок, поскольку ядерный код не склонен доверять юзерспейсу. Не факт, что дополнительную стоимость вообще возможно детектировать профайлером, она запросто может утонуть в статистическом шуме. Но, может быть, сумма выйдет не бесплатной. Но положительные эффекты ведь тоже суммируются. > В итоге всё это выгдялит как куча костылей. Сложная система вообще выглядит как куча костылей. Но этот конкретный костыль мне нравится -- он не создаёт новых взаимосвязей между подсистемами, он очень хорошо вписывается в *nix'овую модель памяти. Вон, sbcl работает с памятью (и со стеком) сильно особенным образом, но его допилили вместе с go, который, видимо, на фоне всей этой его модели горутинов, тоже со стеком играется очень интересно. Допилили за несколько дней. Что собственно неудивительно, поскольку всё что надо было сделать -- это в нужном месте в вызов mmap добавить ещё один флаг.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Crazy Alex (ok), 12-Мрт-18, 21:52
	Положительные эффекты суммируются, когда они есть. IMHO, если ты не доверяешь запускаемому коду - заворачивай его в виртуалку или какую другую песочницу, где ты можешь настроить соотношение безопасность/геморрой. А если доверяешь - то защищать надо от тупости, и не более. А уж энфорсить в ядре защиту защиту приложений от их же дыр - это бред сивой кобылы. Кстати, то, что стек в результате заставляют выделять строго меммапом, мне не особо нравится. Впрочем, в линуксе, насколько я знаю, таким безумием не страдают (тем более, что это может сломать юзерспейс), так что, по большому счёту, можно не волноваться. Сложная система выглядит как куча костылей, когда она используется за пределами тех областей, для которых предназначена, и при этом расширялась костылями, как современные иксы, допустим. Или если не проектировали вообще никак, тоже бывает. А когда используется подход, в принципе не особо подходящий под задачу, как в OpenBSD, где хотят и си с посиксом и совместимостью с существующим софтом, и безопасность - это совсем другое.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	51. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Аноним (-), 12-Мрт-18, 21:55
	> при этом расширялась костылями, как современные иксы, допустим. ЕРЕТИК !!!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	64. "Разработчики OpenBSD развивают новый метод защиты стека"	+1 +/–
	Сообщение от Crazy Alex (ok), 13-Мрт-18, 00:16
	Ага, еретик. Я считаю, что если б тулкитчики сделали по-людски, расширив иксы нужными им функциями, а не плевались битмапами на каждый чих - мы бы сейчас имели и сетевую прозрачность, Ии шустрый универсальный GUI, и всё прочее - без необходимости изобретать велосипеды.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	60. "Разработчики OpenBSD развивают новый метод защиты стека"	+2 +/–
	Сообщение от Ordu (ok), 12-Мрт-18, 23:11
	> Положительные эффекты суммируются, когда они есть. IMHO, если ты не доверяешь запускаемому > коду - заворачивай его в виртуалку или какую другую песочницу, где > ты можешь настроить соотношение безопасность/геморрой. А если доверяешь - то защищать > надо от тупости, и не более. А уж энфорсить в ядре > защиту защиту приложений от их же дыр - это бред сивой > кобылы. Ну, так рассуждая, можно придти к выводу, что DOS лучшая операционная система, потому что она полностью доверяет приложениям. Они могут делать всё что угодно, и DOS им не мешает. Кстати да, когда я когда-то давно перелез из DOS в Windows, меня кошмарно раздражало, что Windows не пускает меня к видеопамяти, к контроллеру клавиатуры, к прерываниям таймера и прочим железкам. Со временем я привык и даже научился получать удовольствие от этих ограничений, но поначалу бесило ужасно: засунули меня в позорную ring3 песочницу, как ребёнка малого прям, и не выпускают оттуда. Одной из причин моего радостного перехода в linux было то, что в linux'е не нужно было платить денег за DDK, чтобы написать модуль, который будет по-взрослому работать в ring0. Но, как-то так выяснилось довольно быстро, что в ring0 мне делать нечего, и неинтересно. И я как ребёнок малый с тех пор сижу в песочнице ring3. > Кстати, то, что стек в результате заставляют выделять строго меммапом, > мне не особо нравится. Не знаю даже почему. Потому, что память из mmap надо освобождать через munmap, а не через free? Ну, это неудобство, наверное, но я не думаю, что какое-то особое: все эти развлечения со стеком всё равно требуют либо asm'а, либо этих дурацких костыльных API, типа setjmp/longjmp или makecontext, то есть вокруг переключения контекстов по-любому приходится устраивать какие-то особые пляски с бубном, поэтому если добавить в эти пляски ещё и ритуал вызова munmap, вместо free, то это не сделает ситуацию хуже. Я пользовался mmap и с другими целями -- чтобы не выделять из кучи больших кусков. При помощи malloc получается почти то же самое, но с лишними посредниками в виде алгоритмов кучи, и с невозможностью потом отдать память обратно системе. Ещё я использовал его, чтобы файлы открывать -- если забить на переносимость программы на железо с другим endianess, то очень удобно бинарный файл открыть через mmap, привести указатель к типу struct my_binary_file_format, и работать потом с результатом, не парясь на вычитывание из FILE* одного поля за другим, и в то же время подгружая в память с диска только то, что надо. Так вот, я не упомню, чтобы необходимость использования munmap вместо free создавала каких-либо проблем, даже несмотря на то, что всё это происходило в C, где нет возможности создать тип параметризованный аллокатором, с тем чтобы свалить на компилятор проблемы выбора между free и munmap. > Сложная система выглядит как куча костылей, когда она используется за пределами тех > областей, для которых предназначена, Может быть. Но пускай в OpenBSD первой кинет камень та сложная система, которая не выходила за пределы своей области предназначения.
	Ответить \| Правка \| К родителю #50 \| Наверх \| Cообщить модератору


	68. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Crazy Alex (ok), 13-Мрт-18, 00:29
	С моей точки зрения ответственность ядра - защищать ядро от юзерспейса и разных пользователей друг от друга. Всё остальное должно реализовываться поверх и по необходимости. Собственно, так оно традиционно и используется - как создаются отдельные пользователи для всяких веб-серверов и подобного. Даже то, что сверху накинули cgroups и capabilities прицнипиально это не меняет - конечной единицей остаётся процесс. А вот когда начинаются NX-биты на данные, подобные ограничения на стек и так далее - это уже лишнее, что, как минимум, должно быть опциональным - это личное дело приложения. Конкретно со стеком - понятия не имею, но наверняка найдётся пара-тройка экзотических случаев, когда таки удобно использовать под стек чёрт знает что. Что до OpenBSD - не уверен, что у неё вообще область применения есть.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	73. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Ordu (ok), 13-Мрт-18, 02:09
	> Впрочем, в линуксе, насколько я знаю, таким безумием не страдают (тем более, что это может сломать юзерспейс), так что, по большому счёту, можно не волноваться. Ы. Я заглянул в man mmap, и нашёл там такое: MAP_STACK (since Linux 2.6.27) Allocate the mapping at an address suitable for a process or thread stack. This flag is currently a no-op, but is used in the glibc threading implementation so that if some architectures require special treatment for stack allocations, support can later be transparently implemented for glibc. Это правда, судя по описанию, создано не для софтварной защиты, а для железной -- на случай чего-нибудь в стиле особо экзотической не-гарвардской архитектуры, где память под стек особенная.
	Ответить \| Правка \| К родителю #50 \| Наверх \| Cообщить модератору


	75. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Crazy Alex (ok), 13-Мрт-18, 03:33
	И что? Оно no-op, и фактически является костылём на случай чего. Это никак не значит, что кто-то рискнёт убить софтину за то, что она создала стек без этой плюшки. Разве что Линус помрёт и его место займёт кто-то странный. Под "безумием" я имел в виду вмешательство в личные дела юзерленда а не хинт, созданный на всякий случай в замшелом году и никак не применяемый.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Аноним (-), 13-Мрт-18, 20:45
	Какую другую песочницу? Если речь идет о виртуальной машине то потеря производительности и накладные расходы будут гораздо больше. Если речь идет о визуализации на уровне операционной системы, то во первых накладные расходы будут больше, во вторых как раз для таких контейнеров описываемый в новости защитный механизм очень нужен
	Ответить \| Правка \| К родителю #50 \| Наверх \| Cообщить модератору


	93. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Crazy Alex (ok), 17-Мрт-18, 19:00
	Да любой из этих вариантов. Накладные расходы получаем только там, где они нужны. Как в плюсах - "платишь за то, что используешь"
	Ответить \| Правка \| Наверх \| Cообщить модератору


	84. "Разработчики OpenBSD развивают новый метод защиты стека"	+1 +/–
	Сообщение от Аноним (-), 13-Мрт-18, 22:55
	> IMHO, если ты не доверяешь запускаемому > коду - заворачивай его в виртуалку или какую другую песочницу, где > ты можешь настроить соотношение безопасность/геморрой. После Spectre я вдруг понял почему Тео говорил, что виртуалка это не о безопасности. А после плевков Тео в сторону Core2Duo, с его кучей Erarata, у меня возникли мысли, что наверно Тео что-то там понимает и даже видимо уверенно прав. Жаль не хватает квалификации заценить всю его крутизну, если она есть. Хотя, как я понял, он утверждает, что на x86 невозможно построить гарантированно безопасную систему
	Ответить \| Правка \| К родителю #50 \| Наверх \| Cообщить модератору


	87. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Anonymoustus (ok), 14-Мрт-18, 00:20
	Определённо, Тео таки кое-что понимает. x86 небезопасна по двум причинам фундаментального свойства. Во-первых, из-за костылей и подпорок внутри себя, которыми её оборудовали для обратной совместимости с окаменелыми древностями доисторического программирования на перфокартах. Когда-то это было нужно, но вот после появления на свет OS/2 и NT, как по мне, следовало рвать и резать связи со старым по живому и строить домик на новом фундаменте. Они (Штеуд), кстати, делали такие попытки, да люди не поняли, не оценили. Во-вторых, даже те средства обеспечения безопасности, которые в ней есть, программеры не используют, либо используют недостаточно, либо используют неправильно. По каким-то своим эзотерическим причинам, в которых стесняются признаться публике. Сама Интел знает недостатки своих продуктов, и они неоднократно предлагали радикальные решения, но требующие разрыва с прошлым, смены железа и парадигм мышления и работы. Я не только про Итаниум, но и про него. Что же ответил рынок? А рынок отверг новые, хорошие правильные решения, продолжая чавкать протухшей x86ятиной. ИЧХ, даже открывшиеся уязвимости и проблемы с безопасностью не склоняют людей сделать выводы. Из истории неудачных попыток уйти от сабжа: https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_i860
	Ответить \| Правка \| Наверх \| Cообщить модератору


	89. "Разработчики OpenBSD развивают новый метод защиты стека"	–1 +/–
	Сообщение от Не тот Аноним (?), 14-Мрт-18, 05:06
	> x86 небезопасна по двум причинам фундаментального свойства. У вас это предложение в утвердительной форме > Во-вторых, даже те средства обеспечения безопасности, которые в ней есть, программеры не > используют, либо используют недостаточно, либо используют неправильно. По каким-то своим > эзотерическим причинам, в которых стесняются признаться публике. А вот тут с вами не согласен При чем здесть программисты, если https://webcache.googleusercontent.com/search?q=cache:ArAOiu... И очень даже не стесняются признаться публике в какой помойной яме сидят > Сама Интел знает недостатки своих продуктов, и они неоднократно предлагали радикальные > решения, но требующие разрыва с прошлым, смены железа и парадигм мышления > и работы. > Из истории неудачных попыток уйти от сабжа: > https://en.wikipedia.org/wiki/Intel_iAPX_432 > https://en.wikipedia.org/wiki/Intel_i860 А ΑΡΜ и MIPS взлетел, когда пришло время Когда важное програмное обеспечение станет настолько сложным, что не будет требоваться закрытия сырцов ( например по причине первостепенного значения инфраструктуры создания ПО), тогда можно менять архитектуру железа на любую, но есть одно но: если рынок требует скорости на однопоточном гов<CENSORED>коде, а на безопасность можно спокойно положить (ну утечет база пользователей с паролями, и что?), вот что делать? > Что же ответил рынок? А рынок отверг новые, хорошие правильные решения, > продолжая чавкать протухшей x86ятиной. ИЧХ, даже открывшиеся уязвимости и проблемы с > безопасностью не склоняют людей сделать выводы. Менеджеры Интела мудро и дальновидно угадали, что построив свои процессоры со свойством уязвимости к Meltdown получат конкурентное преимущество перед AMD и, пока, последняя будет на вторых ролях можно загребать рынок под себя (главное держать руку на пульсе, чтобы вовремя сбросить акции) Рынок тянется к максимизации прибыли, и увы наверно со скорбью надо иметь ввиду, что здесь не до инженерных правильных решений. Пока кто-то тормозит на правильных решениях, конкуренты успевают вас обанкротить. Пока что мне видится надежда на изменение в майнерах, работающих на дырявых системах
	Ответить \| Правка \| Наверх \| Cообщить модератору


	90. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Anonymoustus (ok), 14-Мрт-18, 12:47
	>> x86 небезопасна по двум причинам фундаментального свойства. > У вас это предложение в утвердительной форме Можете добавить ещё причин. Я выделил те, которые мне представляются имеющими значение в контексте дискуссии. >> Во-вторых, даже те средства обеспечения безопасности, которые в ней есть, программеры не >> используют, либо используют недостаточно, либо используют неправильно. По каким-то своим >> эзотерическим причинам, в которых стесняются признаться публике. > А вот тут с вами не согласен > При чем здесть программисты, если > https://webcache.googleusercontent.com/search?q=cache:ArAOiu... > И очень даже не стесняются признаться публике в какой помойной яме сидят Спасибо, я знаком с этой статьёй и согласен с её тоном и смыслом. От этого много раз пытались уйти (и та же Intel, к слову, тоже, как я уже писал) — в RISC, VLIW, микроядро, наноядро, экзоядро, да и «гарвардская архитектура» есть. Но «рынок» — точнее, общественное сознание в целом, искалеченное наркозависимостью от «новинок моды» — не принимает решения, которые менее быстры в простом измеримом исчислении (тестовых «попугаях», грубо говоря), хотя более надёжны и безопасны. А ведь не тайна, что сложные вещи всегда имеют больше точек отказа, чем простые. Но так и живём с этим всем. > А ΑΡΜ и MIPS взлетел, когда пришло время Они взлетели _не там_, где формируется общественное мнение, а потому не оказывают влияния не смену общественного отношения к проблеме и, в результате, не влияют на работу по исправлению проблемы. Обыватель даже не знает этих слов. Зато про Intel знает каждый ребёнок. > Когда важное програмное обеспечение станет настолько сложным, что не будет требоваться > закрытия сырцов ( например по причине первостепенного значения инфраструктуры создания > ПО), тогда можно менять архитектуру железа на любую, но есть одно > но: > если рынок требует скорости на однопоточном гов<CENSORED>коде, а на безопасность можно > спокойно положить (ну утечет база пользователей с паролями, и что?), вот > что делать? Да. Именно в этом _проблема_, а не в собственно багах ПО и аппаратуры. И мы даже знаем имена тех, кого надо за неё благодарить: Intel и Microsoft. Они взрастили и воспитали этот менталитет на компьютерном рынке. Что делать — _отказываться_ от использования фатально сложных технических систем. Упомянутые выше наноядро и экзоядро вполне решают одну из главных проблем небезопасности. Программистам стоило бы начать писать для MINIX, например, а не для модных JS-фреймфорков, потому что будущее строится сегодня. >> Что же ответил рынок? А рынок отверг новые, хорошие правильные решения, >> продолжая чавкать протухшей x86ятиной. ИЧХ, даже открывшиеся уязвимости и проблемы с >> безопасностью не склоняют людей сделать выводы. > Менеджеры Интела мудро и дальновидно угадали, что построив свои процессоры со свойством > уязвимости к Meltdown получат конкурентное преимущество перед AMD и, пока, последняя > будет на вторых ролях можно загребать рынок под себя (главное держать > руку на пульсе, чтобы вовремя сбросить акции) > Рынок тянется к максимизации прибыли, и увы наверно со скорбью надо иметь > ввиду, что здесь не до инженерных правильных решений. Пока кто-то тормозит > на правильных решениях, конкуренты успевают вас обанкротить. Хм. Значит не только я думаю, что они делали всё это _сознательно_. Беглое знакомство с Core 2 и, особенно, с Nehalem не может, по моему мнению, не вызвать таких мыслей. > Пока что мне видится надежда на изменение в майнерах, работающих на дырявых > системах В каком-то смысле, для прогресса человечества было бы полезно понести сейчас на этих дырах самые тяжелейшие потери. Дабы на собственном опыте научиться не выбирать сложные технические системы по принципу покупки модных украшений.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	91. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Anonymoustus (ok), 14-Мрт-18, 12:58
	Произвольно взятый отрывок из доступных в сети исходников Оффтопика-2000: /++ Abstract: This file implements the circular buffer management for input events. The circular buffer is described by a header, which resides in the beginning of the memory allocated when the buffer is created. The header contains all of the per-buffer information, such as reader, writer, and reference counts, and also holds the pointers into the circular buffer proper. When the in and out pointers are equal, the circular buffer is empty. When the in pointer trails the out pointer by 1, the buffer is full. Thus, a 512 byte buffer can hold only 511 bytes; one byte is lost so that full and empty conditions can be distinguished. So that the user can put 512 bytes in a buffer that they created with a size of 512, we allow for this byte lost when allocating the memory. --/ Я убрал упоминание про автора и прочие конкретизирующие моменты, как и сам текст программы, оставил только описательную часть. Дальше там интересно, в том числе про хаки. :) Иходники, в целом, хорошо прокомментированы и структурированы. Я не думаю, что есть какие-то иные причины скрывать это от человечества, кроме копирайтов. На этот кусок, например, было упомянуто о преемственности от соответствующей подсистемы OS/2.
	Ответить \| Правка \| К родителю #89 \| Наверх \| Cообщить модератору


	62. "Разработчики OpenBSD развивают новый метод защиты стека"	+1 +/–
	Сообщение от Аноним (-), 12-Мрт-18, 23:22
	> В итоге всё это выгдялит как куча костылей. Так если ты не заметил, продакшны и не рвутся использовать OpenBSD. По всем бенчмаркам она относительно пингвина понятно где. Все быстренько прикидывают что лишние серваки придется оплатить - дальнейшее предсказуемо.
	Ответить \| Правка \| К родителю #34 \| Наверх \| Cообщить модератору


	65. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Аноним (-), 13-Мрт-18, 00:18
	>> В итоге всё это выгдялит как куча костылей. > Так если ты не заметил, продакшны и не рвутся использовать OpenBSD. По > всем бенчмаркам она относительно пингвина понятно где. Все быстренько прикидывают что > лишние серваки придется оплатить - дальнейшее предсказуемо. А продакшены, которые решились на OpenBSD кучу девяток сделать, это не продакшены?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	76. "Разработчики OpenBSD развивают новый метод защиты стека"	+2 +/–
	Сообщение от Crazy Alex (ok), 13-Мрт-18, 03:37
	Не продакшны. Ну есть где-то в углу рынка - и хрен с ним. Их же совсем единицы. Примерно как если где-то есть три гения, успешно пишущих коммерческий софт на лиспе это не делает лисп конкурентом пхп, питона или джавы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	86. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Аноним (-), 13-Мрт-18, 23:15
	> Не продакшны. Ну есть где-то в углу рынка - и хрен с > ним. Их же совсем единицы. Примерно как если где-то есть три > гения, успешно пишущих коммерческий софт на лиспе это не делает лисп > конкурентом пхп, питона или джавы. Давайте просто в вашем сообщении заменим продакшен на мейнстрим и на этом порешим, а то надо будет определяться - после какого количества денег спродуцированного (в вашей терминологии видимо не участника, а всего рынка) системой можно считать продакшеном
	Ответить \| Правка \| Наверх \| Cообщить модератору


	94. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Crazy Alex (ok), 17-Мрт-18, 19:07
	А это, в общем, одно и то же - мейнстрим таков, каков он есть, не из-за заговора марсиан, а потому что в данных условиях это оптимум, отклоняться от которого - значит искать себе приключения. Иногда, конечно, это делать приходится - когда есть чёткое понимание, на кой оно надо. Но в абсолютном большинстве случаев это не понимание, а глюки, и результат выходит соответствующий.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	63. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Anon4ik (?), 12-Мрт-18, 23:29
	Слой за слоем выходит армированная броня. Или вы представляете себе один метод решающий все проблемы безопасности? (power off хороший метод, но не вариант)
	Ответить \| Правка \| К родителю #34 \| Наверх \| Cообщить модератору


	66. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Аноним (-), 13-Мрт-18, 00:19
	> Слой за слоем выходит армированная броня. Или вы представляете себе один метод > решающий все проблемы безопасности? (power off хороший метод, но не вариант) Прям лирическое определение OpenBSD
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Crazy Alex (ok), 13-Мрт-18, 00:31
	Если уж продолжать метафору - ну и тащат эту броню потом на гонки Ф-1, потому как приросла и не снимается. Или сидят в ней в собственном доме в собственной спальне.
	Ответить \| Правка \| К родителю #63 \| Наверх \| Cообщить модератору


	82. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Аноним (-), 13-Мрт-18, 16:58
	> армированная броня Это, в смысле, бронированная броня?
	Ответить \| Правка \| К родителю #63 \| Наверх \| Cообщить модератору


	85. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Аноним (-), 13-Мрт-18, 23:11
	>> армированная броня > Это, в смысле, бронированная броня? Наверно в смысле композитная (костылями прошитая), а не цельнолитая
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Разработчики OpenBSD развивают новый метод защиты стека"	+/–
	Сообщение от Аноним (-), 12-Мрт-18, 19:56
	Думать - это не твой конек.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору