была у сингулярити интересная фича, это одно линейное пространство для всех процессов
но наскока я понимаю устройство цпу, нет никакой особой проблемы сделать так и без управляемой среды.
остаются страницы памяти, остаются дескрпиторы безопасностии, остается разряженное виртуальное адресное пространство, остается segmentation fault, ниче особо не меняется, а 64 бита на адрес хватит всем,
зато теперь все указатели — глобальные, и можно иметь нормальный ООП ОС АПИ, можно сильно упростить user-kernel переход, и можно передавать между процессами указатели напрямую, а не мучаться с глупой сериализацией
или может какието хипстеры из какогото стремного АРМ уже такое сделали?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Bill Baklushi, Вы писали:
BB>Первый раз такое слышу. Это что за подписанные указатели? Можно подробнее?
Pointer Authentification Code (PAC).
Подписывается значение указателя и контекст (например его адрес в памяти). Ключи лежат в спец.регистрах процессора (уникальны для каждого процесса, кода и данных).
Если подпись нарушена — указатель не принимается (в АРМ портится старший бит чтобы вызвать исключение). Все подписи и их проверки выполняются аппаратно. Упрощенный перебор невозможен (например на основании знания значений других подписанных указателей), гарантируется криптостойкость.
Заметь, даже если "украсть" указатель на какую-нить важную функцию, например с помощью уязвимости раскрытия данных, то использовать такой указатель будет всё равно невозможно.
Нпример, мы хотим с помощью уязвимости заменить безобидный обрботчик какой-то структуры на опасный. И... даже зная их адреса — не можем этого сделать. Т.к.опасный указатель никогда не подписывался для этого адреса памяти.
Здравствуйте, Эйнсток Файр, Вы писали:
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 кстати ? Там было ровно то же самое.
B>была у сингулярити интересная фича, это одно линейное пространство для всех процессов B>но наскока я понимаю устройство цпу, нет никакой особой проблемы сделать так и без управляемой среды.
Это ты сейчас MS-DOS изобрел
Как много веселых ребят, и все делают велосипед...
B>> можно передавать между процессами указатели напрямую IID> Для этого указатель должен быть подписан выдающей стороной. Иначе ДЫРИЩА в безопасности.
Непонятно почему дырища, и как там может образоваться man-in-the-middle, когда прикладная программа вызывает ядро и обрабатывает из ядра коллбэки.
B> может какието хипстеры из какогото стремного АРМ уже такое сделали?
Здравствуйте, Barbar1an, Вы писали:
B>остаются страницы памяти, остаются дескрпиторы безопасностии, остается разряженное виртуальное адресное пространство, остается segmentation fault, ниче особо не меняется, а 64 бита на адрес хватит всем,
B>зато теперь все указатели — глобальные, и можно иметь нормальный ООП ОС АПИ, можно сильно упростить user-kernel переход, и можно передавать между процессами указатели напрямую, а не мучаться с глупой сериализацией
Приложения смогут читать память друг друга(да еще и записывать), с любой учетной записи.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, vsb, Вы писали:
vsb>Добить указатели до 256 бит и пускай ищут )))
А АЛУ пускай лишние биты гоняет и дополнительными транзисторами щелкает. Опять смарты будут разряжаться за полдня.
На хранение указателей 32 байта вместо 4/8 тоже создаст нехилый гешефт вендорам железа. И обьекты разжиреют, и деревья трансляции. Для 256 бит это ж сколько уровней потребуется ? Штук 16, против современных 3-4. А скйчас только 39 бит из 64 юзаются (или около того). И быстрой статики в кеши кпу придется досыпать, а она ух какая недешевая.
Barbar1an:
B>от лиссабона до.... шутка) B>была у сингулярити интересная фича, это одно линейное пространство для всех процессов B>но наскока я понимаю устройство цпу, нет никакой особой проблемы сделать так и без управляемой среды.
Это стёб чтоли такой тонкий?
Сначала и было единое адресное пространство, а потом изобрели виртуальное.
Даже в x86 сделаешь тождественное отображение виртуальных адресов в физическое и полный доступ —
и любая задача может гадить каждой другой. Только вот зачем?
Насколько знаю в дотнете ссылки на объекты — особый уровень абстракции, они не привязаны даже к виртуальным адресам и могут перемещаться сборщиком мусора.
Соответственно в чисто управляемой среде само понятие виртуального адреса частично избыточно (но может защищать нативные драйвера друг от друга).
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
IID:
IID>Для этого указатель должен быть подписан выдающей стороной. Иначе ДЫРИЩА в безопасности.
Первый раз такое слышу. Это что за подписанные указатели? Можно подробнее?
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
B>зато теперь все указатели — глобальные, и можно иметь нормальный ООП ОС АПИ,
При переходе user->kernel в одном процессе, код в ядре легко пересчитает указатели туда и обратно. Так что тут глобальные указатели не помогут.
> можно сильно упростить user-kernel переход,
Упросить его таким образом не получится (при переключении контекста много чего делается) можно только совсем убрать. Опять толку никакого.
> и можно передавать между процессами указатели напрямую, а не мучаться с глупой сериализацией
Когда нужно передавать данные между процессами используют разделяемую память и там вместо глобального указателя используют базу (свою для каждого процесса) и смещение. Таким образом не получится использовать стандартную библиотеку C++ для объектов в разделяемой памяти и придется писать что-то свое. Причем сериализация там особо не нужна, достаточно использовать одинаковые структуры (архитектура ведь не меняется и расположение данных в структуре одно и то же). Однако в любом случае нужно обеспечить синхронизацию доступа к разделяемой памяти. Тут глобальное адресное пространству чуть поможет, но не сильно.
В общем, я не понял, зачем ТС потребовалась глобальная память (даже при условии, что для разделения доступа все равно придется дать явное разрешение, потому что возможность читать пароли и другие данные моего приложения кем-то другим — плохая идея). Тут был бы уместен конкретный пример, в котором станет понятно, как глобальная память упростит решение задачи.
P.S. Возможно, тебе нужно просто в одном приложении запускать несколько потоков или делать системный вызов clone() с флагом CLONE_VM, чтобы получить желаемое для ограниченного набора твоих приложений.
Здравствуйте, Barbar1an, Вы писали:
B>но наскока я понимаю устройство цпу, нет никакой особой проблемы B>остаются страницы... дескрпиторы... виртуальное... B>зато теперь все указатели — глобальные
Насколько помню, "единое" адресное пространство означает, что имеем в наличии один общий способ адресации — от регистров процессора (которые сейчас именная адресация A B C), ПЗУ BIOS, до дисков (у которых до сих пор вроде ж цилиндр-головка-сектор)
И на практике термин вроде как устарел, и применим для древних ЭВМ и калькуляторов каких нибудь, не?
Здравствуйте, Barbar1an, Вы писали:
B>от лиссабона до.... шутка)
B>была у сингулярити интересная фича, это одно линейное пространство для всех процессов
Эта тема дет 15 назад здесь обсуждалась. Оберонные войны, нужна ли ОС защита памяти, как-то так.
Здравствуйте, Barbar1an, Вы писали:
B>или может какието хипстеры из какогото стремного АРМ уже такое сделали?
AS/400. 30 лет недавно исполнилось только публично.
Можно почитать книгу Фрэнка Солтиса "Основы AS/400" (есть на литмире). Там надо продираться через осанну и славословия на каждой странице, но технические методы реализации этого расписаны очень детально.
Здравствуйте, IID, Вы писали:
BB>>Первый раз такое слышу. Это что за подписанные указатели? Можно подробнее?
IID>Pointer Authentification Code (PAC). IID>Подписывается значение указателя и контекст (например его адрес в памяти). Ключи лежат в спец.регистрах процессора (уникальны для каждого процесса, кода и данных).
Ужс! Теперья я знаю, почему всё тормозит, лагает и жрёт память: во всё виноваты долбанные безопасники.
ЗЫ: в каждой шутке есть доля шутки
Всё сказанное выше — личное мнение, если не указано обратное.