30.09.2012 23:11, Andrey Rahmatullin пишет: > On Sun, Sep 30, 2012 at 11:06:06PM +0400, "Артём Н." wrote: >>>>>>>>> Менять .text в рантайме - плохо. Надо пояснять почему? >>>>>>>> Да, неплохо бы. Ведь, по-идее, изменение производится ещё до передачи >>>>>>>> управления, так что, такая ли большая разница (если не брать в расчёт >>>>>>>> протекторы >>>>>>>> и прочую навесную фигню, которая может при этом не работать)? >>>>>>> Страницы кода нельзя оставлять readonly (а это несекурно) >>>>>> Хм... А поставить им аттрибут после патчинга нельзя? >>>>> Видимо нет. >>>> Хм... Почему? >>> Не знаю, но раз не ставят, значит нельзя или не имеет смысла. Возможно, >>> флаги доступа ставятся линкером, а не лоадером, и это важно (я не очень >>> хорошо знаю эту тему). >> В смысле, ставит-то всё-равно загрузчик? >> Линкер просто выставляет флаги в заголовке? >> Насколько я помню, в виндоус вначале производится применение релокаций, затем >> применяются атрибуты страниц. >> А как-то иначе оно может работать? > Ну если вспомнить, что ридонли страницы вообще говоря могут в ПЗУ > лежать... Хм... Например? Какая-нибудь область BIOS или видеопамяти?
>>>>>> И как часто приходится патчить... >>>>> Всмысле? Каждую инструкцию, вызывающую код из другого объекта. >>>> В смысле, насколько часто адрес загрузки отличается от базового адреса? >>> С ASLR (по умолчанию в 2.6.12+) - всегда. Без - тоже всегда, у эльфов >>> базовый адрес никто не меняет. >> Хм... Любопытно, тогда как работает ASLR для библиотек, в которых секция кода >> разделяется? > Разделяется между чем? Между двумя процессами, использующими данную библиотеку. >> Или в Linux нет чего-то подобного kernel32.dll (т.е. всё только через libc >> обёртки над системными вызовами, через прерывания, например)? > Уточните вопрос. Т.е., libc не "висит" в памяти, а загружается каждый раз заново для каждого процесса (ну или загружается только часть libc, поскольку библиотека - архив, а как оно работает дальше, я не знаю)? Т.е., допустим, kernel32.dll всегда был доступен по определённому адресу у разных винд. Но по фиксированному. Загрузчик знал адрес и при разрешении импорта просто подставлял адреса из таблицы экспорта kernel32 + её адрес загрузки (грубо), насколько я понимаю. При включении ASLR (или как оно называется в винде), возможно просто проецировать единожды загруженный kernel32 на различные адреса виртуального адресного пространства процесса (если это делает загрузчик, он знает адрес). И на первый вопрос, вроде бы ответ понятен: в Linux всё может работать аналогично. Но как работает реально? 1. Возможно ли вкратце? 2. Нет ли у вас ссылок на вменяемую литературу по данной теме, отличающуюся от исходников ядра по содержанию (больше обзорную, чем перегруженную тех. подробностями)? -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
