The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Проект Pine64 выпускает в продажу плату STAR64 на базе архитектуры RISC-V, opennews (?), 02-Апр-23, (0) [смотреть все]

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


368. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +2 +/–
Сообщение от Аноним (368), 03-Апр-23, 17:23 
> нет роялити

И защиты памяти: https://www.opennet.me/openforum/vsluhforumID3/129886.html#324

А в x86 Intel добавил инструкцию NX ещё в начале 1990-тых.

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

369. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Alladin (?), 03-Апр-23, 17:51 
но даже я могу отключить эту вещь в биосе и не заметить разницы)
Ответить | Правка | Наверх | Cообщить модератору

370. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  –1 +/–
Сообщение от Аноним (370), 03-Апр-23, 18:32 
> но даже я могу отключить эту вещь в биосе и не заметить разницы)

Значит вы пользуетесь операционной системой некорректно работающей с памятью (нет аппаратной защиты памяти).

Инструкции NX для защиты пямяти используются даже Microsoft начиная с Windows XP SP2.

Среди свободных OS корректная реализация защиты памяти, без потери производительности, сегодня есть в NetBSD и GNU/Linux+PAX: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309

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

421. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (421), 04-Апр-23, 18:01 
Windows XP SP2 при установке выбирает разные ядра, с включенным NX выберет защищенное.

Другие OS используют NX для постриничной защиты памяти и при "страшной сишной дыре - переполнении буфера" ядро прогу вырубит и запишет всю информацию в лог. Это можно заметить.

А вот если отключить NX то при переполнении буфера эксплоит сработает так что ты не заметишь разницы)

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

460. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (-), 07-Апр-23, 03:41 
> А вот если отключить NX то при переполнении буфера эксплоит сработает так
> что ты не заметишь разницы)

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

Linux вон то делает даже на совсем древних системах не умеющих в NX, программно эмулируя фичу. Чуть медленнее но разница на самом деле микроскопическая.

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

499. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (499), 07-Апр-23, 18:53 
>> А вот если отключить NX то при переполнении буфера эксплоит сработает так
>> что ты не заметишь разницы)
> Вообще не обязан - с рандомизацией лэйаута памяти может просто упасть. А
> если там red zone помечен, что можно и программно сделать, оно
> еще и срубить выполнение программы может при первых намеках на это.

Необходимо постраничная защита процом и ядром OS.

> Linux вон то делает даже на совсем древних системах не умеющих в
> NX, программно эмулируя фичу. Чуть медленнее но разница на самом деле
> микроскопическая.

Если проц не умеет защищать память постранично  (аппаратно, например, NX), то есть вариант посегментной защиты програмно, с ограничениями 1.5Гб памяти и тормозами.

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

503. Скрыто модератором  +/–
Сообщение от Аноним (-), 08-Апр-23, 05:19 
Ответить | Правка | Наверх | Cообщить модератору

505. Скрыто модератором  +/–
Сообщение от Аноним (505), 08-Апр-23, 07:33 
Ответить | Правка | Наверх | Cообщить модератору

504. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (504), 08-Апр-23, 05:40 
> Необходимо постраничная защита процом и ядром OS.

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

x86 просто древний и во времена 386 этим не парились, поэтому там много проблем и много софта которому плохеет если W^X энфорснуть и есть куча особенностей. Актуальных вот именно ранним x86. У более современных систем вообще этого класса проблем быть не обязано, они могли уже с учетом делать. А MMU может адресоваться и иначе чем на x86, например как довольно отдельная mem-mapped железка. Не мешает ему быть эквивалентом по общим свойствам того что он делает.

> Если проц не умеет защищать память постранично

То это совсем уж микроконтроллер какой-то, на котором полновесная многозадачка вообще несколько оверкилл, или что-то вообще совсем древнее. MMU как идея оформился еще аж в эпоху 386. Но в те времена не заморачивались W^X, там хакеров и вирусов почти еще не было, проблема еще не была осознана.

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

507. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (507), 08-Апр-23, 07:38 
>> Необходимо постраничная защита процом и ядром OS.
> MMU это умеет со времен 80386, сложно сказать кто там у кого идею утащил, но почти все архитектуры реализуют это похоже - MMU, страницы, права доступа к ним. В мало мальски современных штуках права на R, W и X отдельно ставятся и вопрос в основном в том чтобы ос не протупляла в настройке этих прав.

Вот RISC-V прогулял на аппаратном уровне защиту пямяти W^X.
И большинство GNU/Linux, *BSD прогуливают корректную работу с памятью W^X.
Хочишь возразить? Проводи аудит и вноси в студию результаты тестов: https://www.opennet.me/openforum/vsluhforumID3/130135.html#501

> x86 просто древний и во времена 386 этим не парились,

Парелись W^X с конца 1960-тых годов. Просто парятся как и сегодня не все.

> поэтому там много проблем и много софта которому плохеет если W^X энфорснуть и  есть куча особенностей. Актуальных вот именно ранним x86.

большых проблем с софтом на архитектурах со строгим W^X до пропоганды JIT небыло!

> У более современных систем вообще этого класса проблем быть не обязано, они могли уже с учетом делать.

А теперь проблемы есть: JIT, ...

> А MMU может адресоваться и иначе чем на x86, например как довольно отдельная mem-mapped железка. Не мешает ему быть эквивалентом по общим свойствам того что он делает.

Проведи аудит архитектуры CPU + OS и выложи результаты тестов.

>> Если проц не умеет защищать память постранично
> То это совсем уж микроконтроллер какой-то, на котором полновесная многозадачка вообще несколько оверкилл, или что-то совсем древнее, выпущенное до 80386.

Речь о RISC-V https://www.opennet.me/openforum/vsluhforumID3/130135.html#501

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

510. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (504), 08-Апр-23, 09:22 
> Вот RISC-V прогулял на аппаратном уровне защиту пямяти W^X.

Вообще-то если его MMU запрограмить с нужными правами - будет тот набор прав. И оно прочекает именно эти права на уровне железа. То что операционка должна этим заморочиться - так раздача правов это как раз суть рода деятельности кернела многозадачки. Если кернел делает не то что вам хочется, при чем тут железка? Это как-то доказывает что железка технически не способна на такое? С фига ли?

Кстати для тех кто не в курсе, у "конструкторов" типа ARM, RISCV и проч - MMU так то отдельная от проца железка, ничему не противоречит даже какую-то другую прилепить (при этом конечно же придется ее подержку в кернелах интересных ос накодить). И идея предъявлять за дизайн MMU вот именно процессорному, именно ядру, или его набору команд - вообще немного не в ладах со здравым смыслом. Это вообще отдельный хардварный блок как таковой.

> И большинство GNU/Linux, *BSD прогуливают корректную работу с памятью W^X.

Мир не идеален. Но он не идеален по чертовой куче аспектов.

> Парелись W^X с конца 1960-тых годов. Просто парятся как и сегодня не все.

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

> большых проблем с софтом на архитектурах со строгим W^X до пропоганды JIT небыло!

Ну да, только про быстрые эмуляторы других архитектур придется забыть, JS и прочие умеющие в JIT будут работать как черепаха, ... и в generic семействе процов это как-то "не очень". Если это что-то специализированное по типу ARM SecureCore - там это может еще и поймут, все равно там софт очень кастомный.

> У более современных систем вообще этого класса проблем быть не обязано,
> они могли уже с учетом делать.

Могли. Но жесткий неотключаемый энфорс этого в железе все же нагнет ряд применений. Софт и железо эволюционируют совместно, друг под друга.

> А теперь проблемы есть: JIT, ...

JIT это технология. Почему она должна быть под запретом я не понимаю. У нее так то есть довольно интересные применения. Вот смотрите, виртуалочка RISCV на x86. Разве это не прекрасно? Без JIT это будет выглядеть достаточно печально, оно и с JIT то так себе.

> Проведи аудит архитектуры CPU + OS и выложи результаты тестов.

Мне слабо в полный аудит мало-мальски крупной ОС, как впрочем и всем остальным.

> Речь о RISC-V

Они так то разные бывают, от MMU-less микроконтроллеров до здоровенных апликушников. И MMU у них внезапно не есть неотъемлимая и прибитая на гвозди часть вот именно процессорного ядра. Для начала. В свете этого претензии "RISCV" выглядят довольно забавно. Видно что человек вообще не понимает что есть RISCV.

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

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

516. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (516), 08-Апр-23, 12:01 
>> Вот RISC-V прогулял на аппаратном уровне защиту пямяти W^X.
> Вообще-то если его MMU запрограмить с нужными правами - будет тот набор прав. И оно прочекает именно эти права на уровне железа. ... Если кернел делает не то что вам хочется, при чем тут железка? Это как-то доказывает что железка технически не способна на такое? С фига ли?

Потому, что RISC-V вместо корректной установки прав на выделяемую память RWX устанавливает RW_Протрояненый_бит_изменения_памяти : https://www.opennet.me/openforum/vsluhforumID3/129886.html#323

> Кстати для тех кто не в курсе, у "конструкторов" типа ARM, RISCV и проч - MMU так то отдельная от проца железка, ничему не противоречит даже какую-то другую прилепить (при этом конечно же придется ее подержку в кернелах интересных ос накодить). И идея предъявлять за дизайн MMU вот именно процессорному, именно ядру, или его набору команд - вообще немного не в ладах со здравым смыслом. Это вообще отдельный хардварный блок как таковой.

Может они себе и без трояна сделают. А пока констатируем факт, что вместо бита запрета исполнения ЕСТЬ ТРОЯН - бит изменения памяти: https://www.opennet.me/openforum/vsluhforumID3/129886.html#323

>> И большинство GNU/Linux, *BSD прогуливают корректную работу с памятью W^X.
> Мир не идеален. Но он не идеален по чертовой куче аспектов.

Но даже в этом мире есть те кто стремится к идеалу: NetBSD, Linux+PAX, ... поддерживают даже в неидеальном мире строгую W^X.

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

А я тогда откуда узнал? Были хакеры, была проблема и ее решение W^X из тех времен. В 1983 году W^X уже стал предъявлятся как МИНИМАЛЬНОЕ требование ко всем OS. Но и сегодня многие принцип W^X не понимают.

> Ну да, только про быстрые эмуляторы других архитектур придется забыть ... и в generic семействе процов это как-то "не очень".

Intel, AMD с NX инструкциями живут и эмуляторам не мешают. Но у x86 для защиты W^X требуется ядро с W^X. Grsecurity имеет готовые профили специально для виртуализации. Все довольны.

Есть строгие архитектуры, где аппаратно запрещено W^X но виртуализация в них тоже есть и работает. Надо смотреть как с производительностью эмуляции других архитектур, например, на IBM POWER*

> Могли. Но жесткий неотключаемый энфорс этого в железе все же нагнет ряд применений. Софт и железо эволюционируют совместно, друг под друга.

Подстраивание есть: инструкции NX, инструкции виртуализации. Но JIT ради строгой W^X для безопасности стоит пожертвовать. Я за оптимизацию во время компиляции.

> Мне слабо в полный аудит мало-мальски крупной ОС, как впрочем и всем остальным.

Необходимо не только ОС, а архитектуру: процесор + ОС
Для оценки архитектуры соответствию уровню C2 хватит результатов ~8 простых тестов, на 10 минут работы, опыт не требуется: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309

> Они так то разные бывают, от MMU-less микроконтроллеров до здоровенных апликушников. И MMU у них внезапно не есть неотъемлимая и прибитая на гвозди часть вот именно процессорного ядра. Для начала. В свете этого претензии "RISCV" выглядят довольно забавно. Видно что человек вообще не понимает что есть RISCV.

Пришол спросить как дела в RISC-V сегодня с защитой памяти: https://www.opennet.me/openforum/vsluhforumID3/129886.html#134

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

436. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (436), 05-Апр-23, 20:31 
> А в x86 Intel добавил инструкцию NX ещё в начале 1990-тых.

Это только x86-32 и было актуально. У более современных платформ сильно меньше проблем с этим изначально. И вообще, правами доступа к памяти MMU занимается.

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

457. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (499), 06-Апр-23, 18:36 
> У более современных платформ сильно меньше проблем с этим изначально. И вообще, правами доступа к памяти MMU занимается.

Меньше больше проблем с CPU не интересно. Результат работы какой с MMU? Имею ввиду ядро OS + процессор корректно работающие с памятью и без потери производительности: https://www.opennet.me/openforum/vsluhforumID3/129886.html#351

Покажи тесты: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309

И ссылки на код ядра OS корректно работающего с памятью для "современных платформ с MMU".

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

458. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (-), 07-Апр-23, 03:26 
> Меньше больше проблем с CPU не интересно. Результат работы какой с MMU?

Я про то что права доступа к памяти вообще-то MMU обрабатываются. Так, по жизни. Расставлять эти права страницам памяти - прерогатива ядра ОС, кидать исключения при их нарушении - дело процессора. И это разумеется быстро, прозрачно проверяется железом при работе с памятью.

У x86-32 просто было множество дурацких проблем, из-за которых сделать вон то сразу и прямо - большая проблема. Например, у него нет относительных режимов адресации. Поэтому просто взять программу и подвинуть ее код в другие адреса при старте? Да сейчас! Там при этом целый комплекс танцев с бубном. И при этом на x86-32 надо половину КОДА программы ПАТЧИТЬ до того как его запускать. Это "немного" противоречит идее W^X: а как патчить исполняемый код, если туда записывать нельзя?

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

Если это не делать, программа в фиксированных адресах памяти с точки зрения безопасности хуже не придумаешь: атакующий сразу точно знает что и где. У менее дурных архитектур включая RISCV с этим сильно меньше проблем с самого начала - там грузить программы в другие адреса сильно проще.

> Имею ввиду ядро OS + процессор корректно работающие с памятью и
> без потери производительности: https://www.opennet.me/openforum/vsluhforumID3/129886.html#351

И где вот в этом вот всем принципиально требуются именно "специальные команды" какие-то? Для чего? Чего из вон того не реализуемо правами страниц в MMU?

> Покажи тесты: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309

1) Тесты чего именно? В этом списке довольно много.
2) Мы вроде про архитектуру и принципиаьлную (не) возможность сделать там нечто а это немного не про конкретные тесты конкретной конфиги а про принципиальную (не)возможность это сделать.

> И ссылки на код ядра OS корректно работающего с памятью для "современных
> платформ с MMU".

https://kernel.org сойдет? Конечно стопроцентные гарантии сейчас даже страховой полис не дает, но все же. И у конкретно RISCV меньше всего дурного легаси подставляюшего безопасность, если уж на то пошло. Даже у ARM каких например безопасность может быть снижена всякими фиксироваными call table по общеизвестным адресам если compat с более старыми форматами бинарей надо. Можно запретить - но тогда кернел не сможет более старые программы EABI запускать. Вот и выбирают люди между секурити и работоспособностью и совместимостью. И вот именно паксов целиком в майнлайн не берут потому что много чего ломается.

А так самый безопсасный компьютер - не подключеный к питанию. Там хакеры точно в пролете. В остальных случаях... интересно, много вам радости с команд если там чего доброго с Management Engine отменеджат с условного "ring -3" всякие супербоги? Безопасность - штука весьма комплексная. Системы на RISCV в 20 раз проще в понимании, без ME/PSP и прочих SMM mode в проприетарной фирмваре, там весь системный уровень самому реально обыграть. А у какого-нибудь интела еще может быть бонусом какая-нибудь iwl вафля с фирмварой сервисного проца на пару мегов - умеющая в DMA и интегрирующаяся с ME для предоставления ему комуникационого канала. Ну и кто будет ломиться лобовым способом обходя все эти DEP если например можно вон оттуда просто DMA зафигачить? На DMA вообще права доступа к памяти могут не действовать - он не проц, MMU по пути нет, о "командах проца" он вообше ничего не знает. В лучшем случае у платформы будет такая штука как IOMMU, это реверсный вариант, проверяющий права доступа уже когда железо -> RAM лезет. Но это опциональная штука и даже когда он есть, сильно отдельный вопрос как он там настроен и насколько он там эффективный. В кернеле на этот счет забавные дефолты есть.

Я это к тому что вы не контролируете низкоуровневый системыный уровень безопасности, менеджмента и проч позволяюший вынести всю систему - но при этом паритесь какими-то костыликами. Это очень странный взгляд на системную безопасность, в том смысле что вы игнорите десятки способов раздербанить систему и выпячиваете какие-то костыли как нечто офигенное. На x86 вообще проблематично получить реально доверяемую и безопасную систему где не надо "доверять" хрен знает каким блобам делающим черт знает что в самых критичных местах системы. А чтоб не скучно было EFI еще и рантайм сервисы умеет, чтобы блобварь не отваливала не только с ME/PSP/сервисных процов но и более прямой доступ к основному имела.

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

501. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (501), 07-Апр-23, 19:45 
>> Меньше больше проблем с CPU не интересно. Результат работы какой с MMU?
> Я про то что права доступа к памяти вообще-то MMU обрабатываются. Так, по жизни. Расставлять эти права страницам памяти - прерогатива ядра ОС, кидать исключения при их нарушении - дело процессора. И это разумеется быстро, прозрачно проверяется железом при работе с памятью.

Список архитектур, процессор + ядро OS которые обеспечивают __корректную__ работу с памятью со ссылками на исходники ядер?

Критерии корректности работы ядра OS c памятью: https://www.opennet.me/openforum/vsluhforumID3/129886.html#351

W^X это фундаментальный и принципиальный момент для безопасности архитектуры:
"Все что исполняется никогда не должно изменятся, а что изменяется никогда не должно исполнятся" - это правило основа всей ИТ безопасности.

из него следует:

     1. запрет изменения на исполняемую области памяти которая исполняемой не создавалась (W^X),
     2. запрет изменения на запись памяти которая выделена как исполняемая (W^X),
     3. запрет создания исполняемой памяти из анонимной памяти (W^X),
     4. запрет изменения на запись памяти выделеной только для чтения (RELRO).

>[оверквотинг удален]
> другие адреса при старте? Да сейчас! Там при этом целый комплекс танцев с бубном. И при этом на x86-32 надо половину КОДА программы ПАТЧИТЬ до того как его запускать. Это "немного" противоречит идее W^X: а как патчить исполняемый код, если туда записывать нельзя? В этом месте мы еще замечаем что x86 порнография позволяет иметь систему странными способами. Скажем пропатчив не сам код а такой х86-изврат как релокейшны и все что вокруг. В этом месте нас начинают волновать RELRO всякие и прочая х86 муть.
> Если это не делать, программа в фиксированных адресах памяти с точки зрения безопасности хуже не придумаешь: атакующий сразу точно знает что и где.

USE="pic pie"
CFLAG="-fPIE -fPIC"
Трудно, да...

Держи пример x86-32 где всё работает правельно: https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../
Грузи и запускай тесты: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309 видишь тесты проходит!!!

> У менее дурных архитектур включая RISCV с этим сильно меньше проблем с самого начала - там грузить программы в другие адреса сильно проще.

Теперь покажи мне пример дистра для RISC-V который может пройти эти тесты: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309
Покажи результаты аудита lynix для RISC-V

Ах не может архитектура W^X ?!! Разарбы в RISC-V засунули аппаратный троян: вместо стандартных прав RWX на выделяемую память сделали RW_изменение_памяти_ : https://www.opennet.me/openforum/vsluhforumID3/129886.html#323

>> Имею ввиду ядро OS + процессор корректно работающие с памятью и
>> без потери производительности: https://www.opennet.me/openforum/vsluhforumID3/129886.html#351
> И где вот в этом вот всем принципиально требуются именно "специальные команды" какие-то? Для чего? Чего из вон того не реализуемо правами страниц в MMU?

Реализуй вот эти критерии: https://www.opennet.me/openforum/vsluhforumID3/129886.html#351 и дай ссылку на исходники ядра OS.

>> Покажи тесты: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309
> 1) Тесты чего именно? В этом списке довольно много.
> 2) Мы вроде про архитектуру и принципиаьлную (не) возможность сделать там нечто а это немного не про конкретные тесты конкретной конфиги а про принципиальную (не)возможность это сделать.

Покажи эти тесты: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309 для RISK-V. Там мало тестов. Lynix можешь не запускать.

>> И ссылки на код ядра OS корректно работающего с памятью для "современных платформ с MMU".
> https://kernel.org сойдет?

НЕТ! "ссылки на код ядра OS __корректно работающего__ с памятью". Критерии корректности работы ядра OS c памятью: https://www.opennet.me/openforum/vsluhforumID3/129886.html#351

Пример результатов тестов, для корректной архитектуры: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309

> Конечно стопроцентные гарантии сейчас даже страховой полис не дает, но все же.

У тебя плохая страховая и плохой договор.

> И у конкретно RISCV меньше всего дурного легаси подставляюшего безопасность, если уж на то пошло.

Где аудит и результаты тестов? Без них для меня у конкретно RISC-V меньше всего безопасности.

> Даже у ARM каких например безопасность может быть снижена всякими фиксироваными call table  по общеизвестным адресам если compat с более старыми форматами бинарей надо. Можно запретить - но тогда кернел не сможет более старые программы EABI запускать. Вот и выбирают люди между секурити и работоспособностью и совместимостью. И вот именно паксов целиком в майнлайн не берут потому что много чего ломается.

Это проблемы проприетарщиков, которым лень для клиента пересобрать пакет под новую архитектуру. Да, знаю таких лично, от покупки их софта отказались именно по причине __не__ __желания__ пересобрать под новую архитектуру проца.

> В остальных случаях... интересно, много вам радости с команд если там чего доброго с Management Engine отменеджат с условного "ring -3" всякие супербоги? Безопасность - штука весьма комплексная. Системы на RISCV в 20 раз проще в понимании, без ME/PSP и прочих SMM mode в проприетарной фирмваре, там весь системный уровень самому реально обыграть. А у какого-нибудь интела еще может быть бонусом какая-нибудь iwl вафля с фирмварой сервисного проца на пару мегов - умеющая в DMA и интегрирующаяся с ME для предоставления ему комуникационого канала.

Бери железо с LibreBOOT. Да аппаратные трояны ещё хуже чем плохие архитектуры.

> Ну  и кто будет ломиться лобовым способом обходя все эти DEP если например можно вон оттуда просто DMA зафигачить? На DMA вообще права доступа к памяти могут не действовать - он не проц, MMU по пути нет, о "командах проца" он вообше ничего не знает. В лучшем случае у платформы будет такая штука как IOMMU, это реверсный вариант, проверяющий права доступа уже когда железо -> RAM лезет. Но это опциональная штука и даже когда он есть, сильно отдельный вопрос как он там настроен и насколько он там эффективный. В кернеле на этот счет забавные дефолты есть.

Для борьбы с этим разрабатывают https://muen.sk/ Можно делать CPU+Muen+GNU/Linux

> Я это к тому что вы не контролируете низкоуровневый системыный уровень безопасности, менеджмента и проч позволяюший вынести всю систему - но при этом паритесь какими-то костыликами. Это очень странный взгляд на системную безопасность, в том смысле что вы игнорите десятки способов раздербанить систему и выпячиваете какие-то костыли как нечто офигенное. На x86 вообще проблематично получить реально доверяемую и безопасную систему где не надо "доверять" хрен знает каким

блобам делающим черт знает что в самых критичных местах системы. А чтоб не скучно было EFI еще и рантайм сервисы умеет, чтобы блобварь не отваливала не только с ME/PSP/сервисных процов но и более прямой доступ к основному имела.

Бери железо с LibreBOOT. Делее CPU+Muen+GNU/Linux+PAX

Это https://www.opennet.me/openforum/vsluhforumID3/129886.html#309 не костыли, а простая, корректно работающая система. Странный взгляд на безопасность у вас с виртуализацией, MAC, .... и без настройки минимальных требований DAC.

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

506. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (504), 08-Апр-23, 07:36 
> Список архитектур, процессор + ядро OS которые обеспечивают __корректную__ работу с
> памятью со ссылками на исходники ядер?

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

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

> W^X это фундаментальный и принципиальный момент для безопасности архитектуры

К сожалению некоторый софт в результате перестает работать или работает плохо. Как JIT в браузере допустим. Совсем это отключить можно, но за это придется очень дорого заплатить. Либо отказом от набитых JS сервисов (отличная идея но не для всех) либо крайне печальной скоростью загрузки многих сайтов (тоже не для всех).

> USE="pic pie"
> CFLAG="-fPIE -fPIC"
> Трудно, да...

Теоретики от секурити забавные. Ну вот например, ваша пакость IIRC требует питон. В нем уже есть такая чудная штука как eval(), суть обход W^X по смыслу. А еще ему вооооон те права - пофиг! Он поди еще и на noexec разделов забьет - это же интерпретер, он "читает" а не "выполняет" с точки зрения ос. С его фичами не так уж и важно что это интерпретируемый код. Если он в кучу сисколов и проч может, какая в общем то разница. Он даже сисколы может попытаться огревать левыми аргументами не сильно хуже нативного кода, да и половина эксплойтов у кидизов на питоне как раз. Отсутствие в системе питона поэффективней W^X пожалуй может быть, если у кидиза сплойт не запустился - прикольно, да? :)

А конкретно вон то комбо CFLAGS иногда ломается с очень прикольными сообщениями компилера. Хотя если программа не компильнется, хакеры обломятся ее хакнуть, вот тут спора нет.

> Держи пример x86-32 где всё работает правельно:

И чего мне с этим мусором делать предлагается? У меня давно уже нет x86-32.

> Ах не может архитектура W^X ?!!

Это что за бред? В качестве "пруфа" приведены какие-то измышлизмы какого-то анона опеннета, с "претензиями" что битики прав R, W и X отдельные видите ли. Я не понимаю что операционке мешает "софтварно" форсить W^X между этими битиками при программировании прав MMU, если решено что должно быть именно так, поэтому заявление этого гражданина - технически некорректное. А то что ядро

> Теперь покажи мне пример дистра для RISC-V который может пройти эти тесты

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

Я могу с десяток примеров некорректной работы с памятью за пределами этих тестов с наскока придумать. Убедить драйвер или фирмвару железки DMA некорректные адреса допустим отдать - и MMU вообще в пролете. Он между процом и RAM и ничего не говорит что будет если это железка и DMA в рам обращаются. А адреса для этого всего софт програмит. Верифицировать это? Современный GPU по сложности - как большой город. Верифицируйте мне что на улице Пердяевка коллектор не протекает. А, его даже на карте города нет и про него все забыли? Ну вот все ваши гарантии на x86 - примерно столько же стоят.

> Где аудит и результаты тестов? Без них для меня у конкретно RISC-V меньше всего безопасности.

Ваши заявы о "безопасности" х86 стоят и того меньше. Приличный человек вообще постеснялся бы расписываться за поведение платформы с проприетарными фирмварами в самых критичных местах, подымаюших чего доброго платформу (ME, PSP) и обладающими правами супербога относительно x86 ядра - оно даже загружать этот ваш x86 не будет, если решит что ему что-то не нравится. То что оно по всей системе шариться может... ээээ... в современных системах оно ранний старт делает. И поэтому настоящий мастер - это вот оно. А вы так, в гостях.

И да, вы знаете, вон тот мастер-ключ, вшитый в фузы проца или чипсета, прописывающий гранд-ауторити которая реально получает ПОЛНЫЙ контроль над системой - на x86 вам "почему-то" вписать не дадут. Права бога Intel и AMD зарезервировали себе и делиться не собираются особо. А вот на ARM или RISCV - такого механизма или нет, или он не активен, или можно самому СВОЙ ключ вписать, став таким себе OEM. И как бы разглагольствовать о безопасности с чужим мастерключом дающим полный оверрайд все и вся в системе - забавно, конечно, но врядли очень секуно. Тем более что ME и PSP так то еще и вызовы делать позволяют, а прошивки обновляемые и то что вы там что-то где-то реверснули ничего не говорит о том что будет через год в новых мамках и апдейтах биосов.

Libreboot это прекрасно но реально полный деблоб только для древнего железа. Для более современного упс. А вот тривиальный ROM сабжа можно и прочекать. Через год он будет такой же. А дальше мой опенсорсный системный софт. И если мне надо хардварный root of trust, я какому-нибудь uboot даже могу наглухо readonly media организовать. И вот он таки чеканет мне что кернель и что там еще легитимные. И при этом единственной гранд-ауторити в системе я. А остальные идут в пень, и снять это реально разве что физическим доступом, и то не прямо сразу.

> Странный взгляд на безопасность у вас с виртуализацией, MAC, .... и
> без настройки минимальных требований DAC.

Есть бесконечное количество способов попытаться приблизиться к желаемой цели. ИМХО,
1) Хочу чтобы было просто и удобно мне, сложно и неудобно атакующему. Все что я делаю преследует оптимизацию вот этого соотношения в мою пользу.
2) В более менее реальной системе векторов атак дочерта и больше. Все их предусмотреть малореально. А пользоваться примитивным микрокернелом, с примерно 0 задач и драйверов чтобы это реально верифицировано было - мне не катит. А чуть более фичасто, даже вот просто баш какой - и вот DHCP сервер получает у меня рут. Потому что баш фичастый а програмер сделал какую-то ерунду. А права памяти и страницы вообще не часть этой абстракции, внезапно. А вот рут у левого скрипта вполне реальный, это проблема.
3) Из пункта 2 следует что я предпочту иметь какой-то понятный мне план на случай если что-то все-таки пошло не так. Этот план опять же подразумевает что атакующий должен застрять и не достичь своих целей, получив минимум профита с атаки при максимуме возни.
4) В идеально надежные железки и системы я не верю. Современное железо и софт сложные, хрупкие, это правда жизни. Она неприятная но какая есть, странно ее игнорить. Предпочтение систем где я могу получить full view и гранд-ауторити - минимизация этого фактора. Это не про x86. Особенно современный.
5) Конопатинг 1 проблемы до идеала не затыкает более 9000 иных векторов атак. Атакующий может зайти на проблему с другого бока, наконец. Поэтому я не вижу смысла фиксироваться на 1 проблеме до упора, предпочитая иные подходы и соотношения, апгрейдящие эти соотношения в мою пользу сразу по ряду направлений.

Как идеальная работа с памятью спасет меня от вон того JS который проламывается в контекст браузера и сканирует мой жесткий диск? А вот контейнер да с виртуалочкой подсунут этому негодяю очень печальный view, а урон будет так то здорово минимизирован. Ну, окей, он даунлоады браузера сопрет. А каких там ключей ssh или ценных данных там чисто технически нету, например.

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

523. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (523), 08-Апр-23, 13:31 
>> Список архитектур, процессор + ядро OS которые обеспечивают __корректную__ работу с памятью со ссылками на исходники ядер?
> Такие гарантии реально получить разве что для тривиальных математически верифицивароных штуках типа какого ядра seL4, но даже там будет швах как только на этом захочется запустить какие-то реальные задачи, драйвера железа (умеющие в опасные операции by design) и все такое.

Кореектную работу с памятью в плане W^X https://www.opennet.me/openforum/vsluhforumID3/129886.html#351
Корректная работа с памятью необходима для уровня C1 - минимум для ОС.
Речи о верификации, соотведствие уровню A, не идёт.

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

Там для верификации используются языки типа SPARK. Люди не верифицируют, это делает компьютер.

>> W^X это фундаментальный и принципиальный момент для безопасности архитектуры
> К сожалению некоторый софт в результате перестает работать или работает плохо. Как JIT в браузере допустим. Совсем это отключить можно, но за это придется очень дорого заплатить. Либо отказом от набитых JS сервисов (отличная идея но не для всех) либо крайне печальной скоростью загрузки многих сайтов (тоже не для всех).

JIT - зло и его надо выкинуть. ПО c JIT не использовать. Корпорашки специально внедряют JIT чтобы вы отключили безопасность с W^X!

> Теоретики от секурити забавные. Ну вот например, ваша пакость IIRC требует питон.

Не ставлю пользовательское ПО требующие интерпреаторы. Использую альтернативы.

> В нем уже есть такая чудная штука как eval(), суть обход W^X по смыслу. А еще ему вооооон те права - пофиг!

У меня патченый python, требование W^X строго соблюдает.

> Он поди еще и на noexec разделов забьет - это же интерпретер, он "читает" а не "выполняет" с точки зрения ос. С его фичами не так уж и важно что это интерпретируемый код. Если он в кучу сисколов и проч может, какая в общем то разница. Он даже сисколы может попытаться огревать левыми аргументами не сильно хуже нативного кода, да и половина эксплойтов у кидизов на питоне как раз. Отсутствие в системе питона поэффективней W^X пожалуй может быть, если у кидиза сплойт не запустился - прикольно, да? :)

У меня интерпретаторы заблокированы DAC:


$ getfacl /usr/bin/python3.6
getfacl: Removing leading '/' from absolute path names
# file: usr/bin/python3.6
# owner: root
# group: python
user::rwx
group::r-x
mask::r-x
other::---

> А конкретно вон то комбо CFLAGS иногда ломается с очень прикольными сообщениями  компилера.

Чтоб не ломалось больше:
USE="pic pie"

>> Держи пример x86-32 где всё работает правельно:
> И чего мне с этим мусором делать предлагается? У меня давно уже  нет x86-32.

Это эталонный пример правельно собраной OS с крутыми фичами, которых сегодня уже нет и небудет .

>> Ах не может архитектура W^X ?!!
> Это что за бред? В качестве "пруфа" приведены какие-то измышлизмы какого-то анона опеннета, с "претензиями" что битики прав R, W и X отдельные видите ли. Я не понимаю что операционке мешает "софтварно" форсить W^X между этими битиками при программировании прав MMU, если решено что должно быть именно так, поэтому заявление этого гражданина - технически некорректное.

Спроси разрабов RISC-V чем они бредели когда вместо бита запрета исполнения засунули ТРОЯН - бит изменения памяти: https://www.opennet.me/openforum/vsluhforumID3/129886.html#351

>> Теперь покажи мне пример дистра для RISC-V который может пройти эти тесты
> где вот эти тесты верифицируют корректность работы ос с памятью от и до и почему они истина в последней инстанции? Они чекают какие-то наиболее очевидные случаи, не более того.

Тесты: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309 показывают принадлежность архитектуры (процесор + ОС) к уровню C2. Этот уровень кроме прочего требует строгое W^X и для файлов на диске и для процессов в оперативке.

Да тесты W^X корректны. И если какойто *NIX их не проходит, то его архитектура уровень C не тянет.

> Я могу с десяток примеров некорректной работы с памятью за пределами этих тестов с наскока придумать.

Жду.

> Убедить драйвер или фирмвару железки DMA некорректные  адреса допустим отдать - и MMU вообще в пролете. Он между  процом и RAM и ничего не говорит что будет если это  железка и DMA в рам обращаются.

Убрал по максимому DMA c ядра Linux. Далее стоит Linux запускать в https://muen.sk/

> А адреса для этого всего софт програмит. Верифицировать это?

Софт который програмит, flashrom можно проверять.

> Современный GPU по сложности - как большой  город. Верифицируйте мне что на улице Пердяевка коллектор не протекает. А, его даже на карте города нет и про него все забыли? Ну вот все ваши гарантии на x86 - примерно столько же стоят. Ваши заявы о "безопасности" х86 стоят и того меньше.

С проприетарной фирмварью есть БОЛЬШАЯ проблема с безопасностью. Сегодня уже нельзя доверять подписаным BIOS/UEFI/Firmware
Корпорашки:
ASUS
JMicron
Realtek
подписывают вирусные BIOS/UEFI/Firmware (и список наверняка не полный).

Делаю сколько есть возможность и на чем есть возможность. Да работаю на проце x86_64 c NX и PAE. Заметь результат - выполнение тестов аудита; не работоспособность эксплоитов! Текущая система удолетворяет уровню C2, а могу и B3 сделать и даже чуть с A1.

Есть другой вариант безопасности - послушать эффективных менеджеров, меркетологов о модели угроз, накупить всякой дряни ничего не умеющей,  понатрахать всем вокруг мозги и быть уверенным что все безопасно. Но, тесты аудита проходить не будут, а эксплоиты работать будут все. А почему так? Что не то с этой безопасностью? Что не так с моделью угроз? Ах да, надо быстро обновлятся (не проверяя обновления)  и все срочно переписать на "самый безопасный" Rust!

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

LibreBOOT  для всех приличных людей!

> И да, вы знаете, вон тот мастер-ключ, вшитый в фузы проца или чипсета, прописывающий гранд-ауторити которая реально получает ПОЛНЫЙ контроль над системой - на x86 вам "почему-то" вписать не дадут. Права бога Intel и AMD зарезервировали себе и делиться не собираются особо.

Раскажу большую военную тайну от Intel если проц и мамку покупать отдельно, то ключ Intel Boot Guard непрошит и если мамка и проц разрешают, то его иожно прошить при первом старте компа. Далее ключом Intel Boot Guerd надо подписать все компонента UEFI включая свой ключ UEFI для подписи загрузчика OS.

> А вот на ARM или RISCV - такого механизма или нет, или он не активен, или можно самому СВОЙ ключ вписать, став таким себе  OEM.
> И как бы разглагольствовать о безопасности с чужим мастерключом дающим полный оверрайд все и вся в системе - забавно, конечно, но врядли очень секуно.

А ты лжец!

Я всех учу другому: https://www.linux.org.ru/forum/security/16550382?cid=16564526

> Тем более что ME и PSP так то  еще и вызовы делать позволяют, а прошивки обновляемые и то что вы там что-то где-то реверснули ничего не говорит о том что будет через год в новых мамках и апдейтах биосов.

LibreBOOT !

> Libreboot это прекрасно но реально полный деблоб только для древнего железа. Для более современного упс.

Да, нагибают: https://www.opennet.me/openforum/vsluhforumID3/130135.html#515

> А вот тривиальный ROM сабжа можно и прочекать. Через год он будет такой же. А дальше мой опенсорсный системный софт.

Теория говорит:
1 DAC
2 MAC
3 Верификация
И я прислушаюсь к мнению людей 60-70 годов. Не надо заниматся MAC не настроив DAC и не надо верифицировать софт не настроив MAC.

> И если мне надо хардварный root of trust, я какому-нибудь uboot даже могу наглухо readonly media организовать. И вот он таки чеканет мне что кернель и что там еще легитимные. И при этом единственной гранд-ауторити в системе я. А остальные идут в пень, и снять это реально разве что физическим доступом, и то не прямо сразу.

Глянь это: https://www.linux.org.ru/forum/security/16550382?cid=16567100

>> Странный взгляд на безопасность у вас с виртуализацией, MAC, .... и без настройки минимальных требований DAC.
> Есть бесконечное количество способов попытаться приблизиться к желаемой цели. ИМХО,
> 1) Хочу чтобы было просто и удобно мне, сложно и неудобно атакующему. Все что я делаю преследует оптимизацию вот того соотношения в мою пользу.
> 2) В более менее реальной системе векторов атак дочерта и больше. Все их предусмотреть малореально. А пользоваться примитивным микрокернелом, с примерно 0 задач и драйверов чтобы это реально верифицировано было - мне не катит. А чуть более фичасто, даже вот просто баш какой - и вот DHCP сервер получает у меня рут. Потому что баш фичастый а програмер сделал какую-то ерунду. А права памяти и страницы вообще не часть этой абстракции, внезапно. А вот рут у левого скрипта  вполне реальный, это проблема.
> 3) Из пункта 2 следует что я предпочту иметь какой-то понятный мне план на случай если что-то все-таки пошло не так. Этот план опять же подразумевает что атакующий должен застрять и не достичь своих целей, получив минимум профита с атаки при максимуме возни.
> 4) В идеально надежные железки и системы я не верю. Современное железо и софт сложные, хрупкие, это правда жизни. Она неприятная но какая есть, странно ее игнорить. Предпочтение систем где я могу получить full view и гранд-ауторити - минимизация этого фактора. Это не про x86.  Особенно современный.
> 5) Конопатинг 1 проблемы до идеала не затыкает более 9000 иных векторов атак. Атакующий может зайти на проблему с другого бока, наконец. Поэтому я не вижу смысла фиксироваться на 1 проблеме до упора, предпочитая иные подходы и соотношения, апгрейдящие эти соотношения в мою пользу сразу по ряду направлений.

PAX+GRSecurity собирают векторы атаки, и вырабатывают правельные и эффективные противодействия.
Векторов много. С появлением нового вектора, до оптимальной промышленной защиты  проходит <5 лет разработки.

Затраты на внедрения GRSecurity минимальны, если архитектура проца правельная.

DAC как не крути все равно необходимо настроить.

Вот на изоляции с MAC можно экономить. Сервисы которые в инете торчат все-же изолировать придется.

Мне нравится в GNU/Linux подсистема Integrity https://www.linux.org.ru/forum/security/16550382?cid=16567177 безопасность даст, а настраивать много меньше чем у MAC, кроме того для уровня B2 она и так необходима.

> Как идеальная работа с памятью спасет меня от вон того JS который проламывается в контекст браузера и сканирует мой жесткий диск? А вот контейнер да с виртуалочкой подсунут этому негодяю очень печальный view, а урон будет так то здорово минимизирован. Ну, окей, он даунлоады браузера сопрет.

Да, DAC это не вытянет. Надо изоляцию каким-то из MAC..

> А каких там ключей ssh или ценных данных там чисто технически нету, например.

Настроить DAC необходимо как не крути: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

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

459. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (-), 07-Апр-23, 03:38 
> Меньше больше проблем с CPU не интересно. Результат работы какой с MMU?

Я про то что права доступа к памяти вообще-то MMU обрабатываются. Расставлять эти права страницам памяти - дело ядра ОС, кидать исключения при их нарушении - дело процессора. И это разумеется быстро, прозрачно проверяется железом при работе с памятью.

У x86-32 было множество дурных проблем, из-за которых сделать то сразу и прямо - проблема. Например, нет относительных режимов адресации. Поэтому взять программу и подвинуть ее код в другие адреса при старте? Фиг. Там целое действо, на x86-32 вообще надо половину КОДА программы ПАТЧИТЬ до того как запускать. Это "немного" противоречит W^X: как патчить исполняемый код, если записывать нельзя?!

В этом месте замечаем ЧТО x86 позволяет иметь систему странными способами. Скажем пропатчив не сам код а такой х86-изврат как релокейшны и все что вокруг. В этом месте нас начинают волновать RELRO и прочая х86 муть.

А программа в фиксированных адресах памяти с точки зрения безопасности хуже не придумаешь: атакующий сразу точно знает что и где. У менее дурных архитектур включая RISCV с этим сильно меньше проблем - там грузить программы в произвольные адреса намного проще, можно position independent код делать. На x86-32 он не является таковым без адских костылищ.

> Имею ввиду ядро OS + процессор корректно работающие с памятью и
> без потери производительности: https://www.opennet.me/openforum/vsluhforumID3/129886.html#351

И где вот в этом вот всем принципиально требуются именно "специальные команды" какие-то? Для чего? Чего из вон того не реализуемо правами страниц в MMU?

> Покажи тесты: https://www.opennet.me/openforum/vsluhforumID3/129886.html#309

1) Тесты чего именно? В этом списке довольно много.
2) Мы вроде про архитектуру и принципиаьлную (не) возможность сделать там нечто. И в этом месте я хочу обоснование что какие-то там команды какого-то x86 для этого принципиально необходимы. И понимание откуда это следует. Это не про некие тесты.

> И ссылки на код ядра OS корректно работающего с памятью для "современных
> платформ с MMU".

https://kernel.org сойдет? Конечно стопроцентные гарантии сейчас даже страховой полис не дает, но все же. И у конкретно RISCV меньше всего дурного легаси подставляюшего безопасность, если мы об этом.

На RISCV общесистемный контроль наладить сильно проще. Без блобвари в системных аспектах. На интеле очень безопасно с проприетарным биосом/EFI который в любой момент в SMM может уйти, а там еще резидентно блобокод в ME или PSP постоянно активен и может DMA долбануть все и вся если захочет. Да и железки это тоже могут - права памяти на них изначально не действуют, про какие там еще наборы команд они вообще ничего не знают, а стать bus master и записать вон то по конкретному физическому адресу DMA может на раз. Хоть ядро в RAM пропатчив. Современные системы по этому бывают с IOMMU но есть ли он и если да то как настроен - отдельный аспект. Ну конечно мы на честное слово поверим какой-нибудь фирмвари IWL вафли на мегабайт, если не два, умеющей играть в совместную игру с Management Engine для ремотного доступа. Зато покажем красивый тест. Еще вот дергайте пожалуйста всякий ACPI и EFI runtime services, как можно чаще, иначе проприетарные блобы расстраиваются что их надолго на контроль обули. Они конечно могут и сбоку, но тут то как белый человек, на основном проце сразу.

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

502. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (502), 07-Апр-23, 20:01 
> На RISCV общесистемный контроль наладить сильно проще. Без блобвари в системных аспектах. На интеле очень безопасно с проприетарным биосом/EFI который в любой момент в SMM может уйти, а там еще резидентно блобокод в ME или PSP постоянно активен и может DMA долбануть все и вся если захочет. Да и железки это тоже могут - права памяти на них изначально не действуют, про какие там еще наборы команд они вообще ничего не знают, а стать bus master и записать вон то по конкретному физическому адресу DMA может на раз. Хоть ядро в RAM пропатчив. Современные системы по этому бывают с IOMMU но есть ли он и если да то как настроен - отдельный аспект. Ну конечно мы на честное слово поверим какой-нибудь фирмвари IWL вафли на мегабайт, если не два, умеющей играть в совместную игру с Management Engine для ремотного доступа. Зато покажем красивый тест. Еще вот дергайте пожалуйста всякий ACPI и EFI runtime services, как можно чаще, иначе проприетарные блобы расстраиваются что их надолго на контроль обули. Они конечно могут и сбоку, но тут то как белый человек, на основном проце сразу.

Бери железо с LibreBOOT. Делее CPU (c инструкцией NX) <-> Muen <-> Linux+PAX

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

508. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (504), 08-Апр-23, 07:52 
У меня есть идеи получше. В том числе и полностью отделаться от x86 в пользу более предсказуемых систем, дающих мне настоящий 100% контроль с самого раннего старта. Это важный аспект системной безопасности, а резидентные DMA-capable процессорные ядра в том же проце или чипсете, подымающие платформу при раннем старте - крайне нежелательный элемент пейзажа. Именно по линии секурити. А настоящие мастерключи ни интел ни амд не дает свои прописать вот туда, в самый ключевой компонент. Это как-то можно игнорить только на старом железе, на новом это полный лохотрон.
Ответить | Правка | Наверх | Cообщить модератору

515. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (515), 08-Апр-23, 10:52 
> У меня есть идеи получше. В том числе и полностью отделаться от  x86 в пользу более предсказуемых систем,

Найдешь свободную архитектуру (проц + ОС) строго соблюдающую W^X приходи раскажешь.

> дающих мне настоящий 100% контроль с самого раннего старта. Это важный аспект системной безопасности, а резидентные  DMA-capable процессорные ядра в том же проце или чипсете, подымающие платформу при раннем старте - крайне нежелательный элемент пейзажа. Именно по линии секурити.

Повыкидывал DMA с ядра Linux где можно было. Далее надо GNU/Linux в https://muen.sk/ запускать.

> А настоящие мастерключи ни интел ни амд не дает свои прописать вот туда, в самый ключевой компонент.

Раскажу большую военную тайну от Intel если проц и мамку покупать отдельно, то ключ Intel Boot Guard непрошит и если мамка и проц разрешают, то его иожно прошить при первом старте компа. Далее ключом Intel Boot Guerd надо подписать все компонента UEFI включая свой ключ UEFI для подписи загрузчика OS.

> Это как-то можно игнорить только на старом железе, на новом это полный лохотрон.

Это "порочный круг затягивающий в ад":

1. Жидо-масоны нагибают АНБ
2. АНБ нагибает корпорашки
3. Корпорашки делают JIT, .... и нагибают своих рабов
4. Рабы на демократических выборах избирают жидо-масонов.
6. GOTO 1.

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

517. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (504), 08-Апр-23, 12:23 
> Найдешь свободную архитектуру (проц + ОС) строго соблюдающую W^X приходи раскажешь.

Я не настолько перфекционист и могу жить с умеренными отклонениями от идеала. Лично мне отделаться от ME/PSP, блоб-фирмваре и грандмастер-ключей от "богов" в системе приоритетнее чем перфекционизм. И более компактная и простая в понимании система, умещающаяся в голове сильно более велкам, я ее возьму под мой чуткий контроль с самого нижнего уровня и все будет ОК. Желательно уметь реимплементить с ноля, вплоть до переразводки печатки, из соображений гибкости, предсказуемости и адаптации к задачам. А также вот именно МОЙ root of trust, если это надо. Это базовый контроль над системой и ее аспектами.

> Повыкидывал DMA с ядра Linux где можно было.

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

К тому же bus master потому и bus master что может сам инициировать транзакции. Работает он так, сам может лазить в оперативку, не хуже проца. Какой-нибудь ME или PSP с его софтом вообще не обязан линуха спрашивать. Попросит DMA напрямую положить от сих до сих, и фиг оспоришь. А если там был ваш кернел который оно решило пропатчить - ну вот и расскажете ему про W^X, только там MMU на пути нету. В лучшем случае IOMMU, но это другое, был ли он на пути вот именно этих, как он запрограммлен и что будет - это отдельный вопрос. На который я так сходу даже ответа не знаю.

> Далее надо GNU/Linux в https://muen.sk/ запускать.

Запускайте, мне не жалко. А я запускаю виртуалки в основном линукс на линуксе. Это в теории не так круто, но лучше чем raw, проще по менеджменту в разы, жесткий реюз имеющихся знаний и технологий, а на случай если этого мало - у меня несколько забавных выкрутасов. Чисто теоретически, я предполагаю что это в целом может удержать и ME/PSP и JS-эксплойт для браузера сканирующий диск. Потому что все чуть хитрее чем кажется. Но вот стопроцентные гарантии этого никто не даст. Достаточно крутой и компетентный атакующий может попробовать обойти все грабли. Но это имхо будет долго, канительно и неудобно. Потому что я сам немного практикую - и знаю что мне бы нравилось меньше всего. Вот именно это и было сделано.

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

527. "Проект Pine64 выпускает в продажу плату STAR64 на базе архит..."  +/–
Сообщение от Аноним (527), 08-Апр-23, 14:01 
> Лично мне отделаться от ME/PSP, блоб-фирмваре и грандмастер-ключей от "богов" в системе приоритетнее чем перфекционизм.

Использую x86_64 с NX и без ME/PSP и чужих ключей!

> И более компактная и простая в понимании система, умещающаяся в голове сильно более велкам, я ее возьму под мой чуткий контроль с самого нижнего уровня и все будет ОК. А также вот именно МОЙ root of trust, если это надо. Это базовый контроль над системой и ее аспектами.

Integrity: https://www.opennet.me/openforum/vsluhforumID3/130135.html#523

>  Желательно уметь реимплементить с ноля, вплоть до переразводки печатки, из соображений гибкости, предсказуемости и адаптации к задачам.

Надо гараж.

Ладно, может кого обидел или задел матеря JIT и RISC-V, но моя цель была не оскорбление, а донести необходимость строгого соблюдения W^X и угрозу безопасности со стороны любых технологий несовместимых с W^X.

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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