Единое адрессное пространство
От: Barbar1an Украина www.mightywill.com
Дата: 21.08.19 10:49
Оценка: :))) :)
от лиссабона до.... шутка)

была у сингулярити интересная фича, это одно линейное пространство для всех процессов

но наскока я понимаю устройство цпу, нет никакой особой проблемы сделать так и без управляемой среды.

остаются страницы памяти, остаются дескрпиторы безопасностии, остается разряженное виртуальное адресное пространство, остается segmentation fault, ниче особо не меняется, а 64 бита на адрес хватит всем,

зато теперь все указатели — глобальные, и можно иметь нормальный ООП ОС АПИ, можно сильно упростить user-kernel переход, и можно передавать между процессами указатели напрямую, а не мучаться с глупой сериализацией

или может какието хипстеры из какогото стремного АРМ уже такое сделали?
http://files.rsdn.org/27037/zx128.png
Отредактировано 21.08.2019 10:51 Barbar1an . Предыдущая версия . Еще …
Отредактировано 21.08.2019 10:51 Barbar1an . Предыдущая версия .
Re: Единое адрессное пространство
От: IID Россия  
Дата: 21.08.19 11:41
Оценка: 1 (1) +3
Здравствуйте, Barbar1an, Вы писали:

B>можно передавать между процессами указатели напрямую


Для этого указатель должен быть подписан выдающей стороной. Иначе ДЫРИЩА в безопасности.
kalsarikännit
Re[2]: Единое адрессное пространство
От: Эйнсток Файр Мухосранск  
Дата: 21.08.19 13:14
Оценка:
B>> можно передавать между процессами указатели напрямую
IID> Для этого указатель должен быть подписан выдающей стороной. Иначе ДЫРИЩА в безопасности.

Непонятно почему дырища, и как там может образоваться man-in-the-middle, когда прикладная программа вызывает ядро и обрабатывает из ядра коллбэки.

B> может какието хипстеры из какогото стремного АРМ уже такое сделали?


Я читал, что такое было реализовно в TempleOS
Re: Единое адрессное пространство
От: lpd Россия  
Дата: 21.08.19 13:17
Оценка:
Здравствуйте, Barbar1an, Вы писали:

B>остаются страницы памяти, остаются дескрпиторы безопасностии, остается разряженное виртуальное адресное пространство, остается segmentation fault, ниче особо не меняется, а 64 бита на адрес хватит всем,


B>зато теперь все указатели — глобальные, и можно иметь нормальный ООП ОС АПИ, можно сильно упростить user-kernel переход, и можно передавать между процессами указатели напрямую, а не мучаться с глупой сериализацией


Приложения смогут читать память друг друга(да еще и записывать), с любой учетной записи.
1) Сколько тролля ни корми, все равно флеймить будет.
2) Заставь тролля C++ учить, он и последний стандарт применит.
Отредактировано 21.08.2019 13:19 lpd . Предыдущая версия .
Re[3]: Единое адрессное пространство
От: IID Россия  
Дата: 21.08.19 17:15
Оценка: 1 (1) +2
Здравствуйте, Эйнсток Файр, Вы писали:

B>>> можно передавать между процессами указатели напрямую

IID>> Для этого указатель должен быть подписан выдающей стороной. Иначе ДЫРИЩА в безопасности.

ЭФ>Непонятно почему дырища, и как там может образоваться man-in-the-middle, когда прикладная программа вызывает ядро и обрабатывает из ядра коллбэки.


причём тут MITM

Я о соседних с тобой процессах. Чтобы было понятнее — менее привелегированных. Или содержащих "вкусные" данные (тут вообще полный швах, очевидно).

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

Итак.
Злоумышленник может передать управление на произвольный адрес.

Что ему ещё надо ?
Ему надо как-то разместить в атакуемом приложении полезную нагрузку и запустить её.
Полезная нагрузка не может быть кодом года эдак с 2006, когда началась более-менее массовая поддержка жезелом NoneXecutable бита в MMU.

Значит полезная нагрузка это данные.
Т.е. злоумышленнику надо
— как-то разместить данные в твоей программе. В случае переполнения буфера — его можно сразу переполнить нужными данными. Но как понять где их адрес ?
— передать управление на уже имеющийся в программе код, инициировав ROP/JOP/FOP. Но как найти адрес твоего (и системного кода) ?

В классическом случае злоумышленнику мешают:
— изоляция адресного пространства
— ASLR
— Heap Randomization

В твоём варианте злоумышленнику не мешает НИЧЕГО.
Даже древние "черви Морриса" смогут обрести новое дыхание, которое им перекрыли стековыми канарейками в конце 90х.

!!!КСТАТИ!!!
1) как предполагается защищаться от изменения writable данных ? Злоумышленник находит такой блок (АП-то общее!), и повреждает его, провоцируя твою программу начать исполнение вредоносного кода.
2) как предполагается защищаться от изменения прочих данных ? Я отдал тебе ReadOnly буфер на парсинг, и продолжаю его менять. Классическое TOCTOU ведь, на котором были сломаны защиты миллионов устройств.
3) что будет если злоумышленник передаст управление из атакованной программы НА СЕБЯ ?

По п.3: именно так работали ядерные эксплоиты где-то до 2010-2013 года. Передавая управление на полезную нагрузку в юзермод — при этом юзерский код исполнялся с уровнем привилегий ядра ОС.

Разрабочикам процессоров ПРИШЛОСЬ сделать SMEP/PXN, а затем и SMAP/PAN. Что резко и сильно усложнило эксплуатацию уязвимостей в ядре.
Т.е. даже ПРОСТО ЧИТАТЬ память это ОПАСНО. Даже для читателя. Понимаешь ?


B>> может какието хипстеры из какогото стремного АРМ уже такое сделали?


ЭФ>Я читал, что такое было реализовно в TempleOS


Ага, которая падает по каждому чиху.

А почему не MS-DOS кстати ? Там было ровно то же самое.
kalsarikännit
Отредактировано 22.08.2019 13:25 IID . Предыдущая версия . Еще …
Отредактировано 21.08.2019 17:18 IID . Предыдущая версия .
Отредактировано 21.08.2019 17:16 IID . Предыдущая версия .
Re[2]: Единое адрессное пространство
От: vsb  
Дата: 21.08.19 17:28
Оценка:
Здравствуйте, lpd, Вы писали:

lpd>Приложения смогут читать память друг друга(да еще и записывать), с любой учетной записи.


Добить указатели до 256 бит и пускай ищут )))
Re[3]: Единое адрессное пространство
От: IID Россия  
Дата: 21.08.19 18:34
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Добить указатели до 256 бит и пускай ищут )))


А АЛУ пускай лишние биты гоняет и дополнительными транзисторами щелкает. Опять смарты будут разряжаться за полдня.

На хранение указателей 32 байта вместо 4/8 тоже создаст нехилый гешефт вендорам железа. И обьекты разжиреют, и деревья трансляции. Для 256 бит это ж сколько уровней потребуется ? Штук 16, против современных 3-4. А скйчас только 39 бит из 64 юзаются (или около того). И быстрой статики в кеши кпу придется досыпать, а она ух какая недешевая.
kalsarikännit
Re: Единое адрессное пространство
От: ononim  
Дата: 21.08.19 18:50
Оценка: +2
B>была у сингулярити интересная фича, это одно линейное пространство для всех процессов
B>но наскока я понимаю устройство цпу, нет никакой особой проблемы сделать так и без управляемой среды.
Это ты сейчас MS-DOS изобрел
Как много веселых ребят, и все делают велосипед...
Re: Единое адрессное пространство
От: AleksandrN Россия  
Дата: 21.08.19 21:59
Оценка: +2 :))) :)
Здравствуйте, Barbar1an, Вы писали:

B>или может какието хипстеры из какогото стремного АРМ уже такое сделали?


Сделали. Ещё в начале 80-х.

  Вот фото этих хипстеров.
https://mtdata.ru/u5/photo6688/20308024417-0/original.jpg#20308024417
Re: Единое адрессное пространство
От: Bill Baklushi СССР  
Дата: 21.08.19 22:20
Оценка:
Barbar1an:

B>от лиссабона до.... шутка)

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

Это стёб чтоли такой тонкий?
Сначала и было единое адресное пространство, а потом изобрели виртуальное.
Даже в x86 сделаешь тождественное отображение виртуальных адресов в физическое и полный доступ —
и любая задача может гадить каждой другой. Только вот зачем?

Насколько знаю в дотнете ссылки на объекты — особый уровень абстракции, они не привязаны даже к виртуальным адресам и могут перемещаться сборщиком мусора.
Соответственно в чисто управляемой среде само понятие виртуального адреса частично избыточно (но может защищать нативные драйвера друг от друга).
В революционном угаре сожгли людей. Не планировали, но так получилось. (с) Bjorn Skalpe про 2 мая
Автор: Bjorn Skalpe
Дата: 21.08 08:36
Отредактировано 21.08.2019 22:35 Bill Baklushi . Предыдущая версия .
Re[2]: Единое адрессное пространство
От: Bill Baklushi СССР  
Дата: 21.08.19 22:38
Оценка:
IID:

IID>Для этого указатель должен быть подписан выдающей стороной. Иначе ДЫРИЩА в безопасности.

Первый раз такое слышу. Это что за подписанные указатели? Можно подробнее?
В революционном угаре сожгли людей. Не планировали, но так получилось. (с) Bjorn Skalpe про 2 мая
Автор: Bjorn Skalpe
Дата: 21.08 08:36
Re[3]: Единое адрессное пространство
От: IID Россия  
Дата: 21.08.19 23:11
Оценка: 3 (3)
Здравствуйте, Bill Baklushi, Вы писали:

BB>Первый раз такое слышу. Это что за подписанные указатели? Можно подробнее?


Pointer Authentification Code (PAC).
Подписывается значение указателя и контекст (например его адрес в памяти). Ключи лежат в спец.регистрах процессора (уникальны для каждого процесса, кода и данных).

Если подпись нарушена — указатель не принимается (в АРМ портится старший бит чтобы вызвать исключение). Все подписи и их проверки выполняются аппаратно. Упрощенный перебор невозможен (например на основании знания значений других подписанных указателей), гарантируется криптостойкость.

Заметь, даже если "украсть" указатель на какую-нить важную функцию, например с помощью уязвимости раскрытия данных, то использовать такой указатель будет всё равно невозможно.

Нпример, мы хотим с помощью уязвимости заменить безобидный обрботчик какой-то структуры на опасный. И... даже зная их адреса — не можем этого сделать. Т.к.опасный указатель никогда не подписывался для этого адреса памяти.
kalsarikännit
Отредактировано 21.08.2019 23:13 IID . Предыдущая версия .
Re: Единое адрессное пространство
От: Masterspline Россия  
Дата: 22.08.19 04:29
Оценка:
B>зато теперь все указатели — глобальные, и можно иметь нормальный ООП ОС АПИ,

При переходе user->kernel в одном процессе, код в ядре легко пересчитает указатели туда и обратно. Так что тут глобальные указатели не помогут.

> можно сильно упростить user-kernel переход,


Упросить его таким образом не получится (при переключении контекста много чего делается) можно только совсем убрать. Опять толку никакого.

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


Когда нужно передавать данные между процессами используют разделяемую память и там вместо глобального указателя используют базу (свою для каждого процесса) и смещение. Таким образом не получится использовать стандартную библиотеку C++ для объектов в разделяемой памяти и придется писать что-то свое. Причем сериализация там особо не нужна, достаточно использовать одинаковые структуры (архитектура ведь не меняется и расположение данных в структуре одно и то же). Однако в любом случае нужно обеспечить синхронизацию доступа к разделяемой памяти. Тут глобальное адресное пространству чуть поможет, но не сильно.

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

P.S. Возможно, тебе нужно просто в одном приложении запускать несколько потоков или делать системный вызов clone() с флагом CLONE_VM, чтобы получить желаемое для ограниченного набора твоих приложений.
Re: Вроде ж единая адресация немного не о том
От: Wolverrum Украина  
Дата: 22.08.19 04:32
Оценка:
Здравствуйте, Barbar1an, Вы писали:

B>но наскока я понимаю устройство цпу, нет никакой особой проблемы

B>остаются страницы... дескрпиторы... виртуальное...
B>зато теперь все указатели — глобальные

Насколько помню, "единое" адресное пространство означает, что имеем в наличии один общий способ адресации — от регистров процессора (которые сейчас именная адресация A B C), ПЗУ BIOS, до дисков (у которых до сих пор вроде ж цилиндр-головка-сектор)

И на практике термин вроде как устарел, и применим для древних ЭВМ и калькуляторов каких нибудь, не?
Re: Единое адрессное пространство
От: Privalov  
Дата: 22.08.19 05:20
Оценка:
Здравствуйте, Barbar1an, Вы писали:

B>от лиссабона до.... шутка)


B>была у сингулярити интересная фича, это одно линейное пространство для всех процессов


Эта тема дет 15 назад здесь обсуждалась. Оберонные войны, нужна ли ОС защита памяти, как-то так.
Re[2]: Единое адрессное пространство
От: Pavel Dvorkin Россия  
Дата: 31.08.19 03:11
Оценка:
Здравствуйте, ononim, Вы писали:

O>Это ты сейчас MS-DOS изобрел


Она все же однопрограммная. Изобрел он Windows 16-битную.
With best regards
Pavel Dvorkin
Re: Единое адрессное пространство
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 01.09.19 09:31
Оценка:
Здравствуйте, Barbar1an, Вы писали:

B>или может какието хипстеры из какогото стремного АРМ уже такое сделали?


AS/400. 30 лет недавно исполнилось только публично.
Можно почитать книгу Фрэнка Солтиса "Основы AS/400" (есть на литмире). Там надо продираться через осанну и славословия на каждой странице, но технические методы реализации этого расписаны очень детально.
Re[4]: Единое адрессное пространство
От: Философ Ад http://vk.com/id10256428
Дата: 07.09.19 10:48
Оценка:
Здравствуйте, IID, Вы писали:

BB>>Первый раз такое слышу. Это что за подписанные указатели? Можно подробнее?


IID>Pointer Authentification Code (PAC).

IID>Подписывается значение указателя и контекст (например его адрес в памяти). Ключи лежат в спец.регистрах процессора (уникальны для каждого процесса, кода и данных).


Ужс! Теперья я знаю, почему всё тормозит, лагает и жрёт память: во всё виноваты долбанные безопасники.

ЗЫ: в каждой шутке есть доля шутки
Всё сказанное выше — личное мнение, если не указано обратное.
Отредактировано 07.09.2019 10:49 Философ . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.