ты утверждаешь что mmap при мапинге /dev/mem будет напрямую писать в физическую память ??
mmap не будет никуда писать. Но mmap может отобразить любую область физической памяти в адресное пространство процесса для прямого доступа.тогда получается любой пользователь может получить доступ к любому участку физической памяти без каких-либо проверок, только за'mmap'ив /dev/mem в своей проге ??
/dev/mem.
mmap в mem_fops, mem_fops указаны как fops в массиве devlist для устройства с минорным кодом DEVMEM_MINOR, этот массив обрабатывается здесь, где регистрируются устройства с мажорным кодом MEM_MAJOR. Устройство с кодом 1, 1 -- это /dev/mem и есть, как можно увидеть здесь
…но это совсем не в тему
…в контексте вопроса сие не имеет значения.
код, реализующий mmap под /dev/mem, не приводил :)
это потребует наличие в хуке кода обработки доступов пользователя к /dev/mem.
open, которым файл открывают.сильно сомневаюсь что такой хук будет внедрен, смысл в нем ??
mmap для /dev/mem, в чём ты конкретно сомневаешься, я не понял?
в каком месте бредовость ??
mmap отлавливает это изменение…
…и формирует файловый запрос на запись. запрос получает драйвер VFS разбирает путь
выявляет подстрочку /dev
/dev/mem работает только пока он в /dev, а если его перенести в какое-нибудь другое место, то он работать перестанет?и направляет его в драйвер udev ответственный за этот путь
не все знаю, чего в этом криповатого ??
Цепочку действий для записи значения в память с помощью спец.файла /dev/mem я привел чуть выше.
Приведи свою.
Я сильно сомневаюсь что в функции mmap есть хук под файл /dev/mem
/dev/mem конечно нет. Есть поле mmap в структуре file_operations, позволяющее любой файловой системе или драйверу предоставить свою реализацию mmap для файлов которые они обслуживают. Опять же, любая книжка по внутренностям ядра об этом рассказывает.
неа, ваапче не так :)
согласен. этих подробностей не знаю.
запись значения в память, посредством /dev/mem, проходит кучу прослоек
mmap отображает фал на произвольную память, котрую ему выдал менджер памяти. ты записываешь в эту область, mmap отлавливает это изменение и формирует файловый запрос на запись. запрос получает драйвер VFS разбирает путь, выявляет подстрочку /dev и направляет его в драйвер udev ответственный за этот путь. udev перенаправляет запрос в драйвер, ответственный за /dev/mem, и только он разбирает файловый запрос и пишет напрямую в указанный адрес физической памяти.
/dev/mem и передаёшь его fd в системный вызов mmap, в ядре вызывается функция mmap_mem зарегистрированная здесь. Эта функция, как можно увидеть здесь, вызывает remap_pfn_range для выделенного участка виртуальной памяти, а в качестве параметра pfn, определяющего номер страницы физической памяти, как написано здесь, передаёт vma->vm_pgoff, т.е. смещение, переданное mmap, но выраженное в страницах. Т.е. не "произвольную память, котрую ему выдал менджер памяти", а вполне конкретную физическую память, которую ты попросил в вызове mmap.
обычно -O3 для отладки с макс. кол-вом символов
-O3 -- это максимальная оптимизация. Максимальная отладочная информация -- -g3. Уровень отдладочной информации выбранной ключом -g не влияет на сгенерированный код.
Отвечая на твой вопрос, что предотвращает запись в секцию .text - флаги секций. У каждой секции есть свои флаги, которые отвечают за возможности работы с этими секциями.
readelf -l их удобно показывает, вместе с таблицей соответствия секций сегментам.
Есть системный вызов ptrace, который вообще-то может изменить секцию кода,
Пусть меня поправят
про то чтобы вебсокет сервер открывался с адресной строки броузера, я никогда не слышал.
в основном потоке только принимаешь соединения. А все общение делаешь в новом треде.
попробуй сперва случай попроще, когда клиент инициатор диалога, а сервер отвечает на запросы
На его базе можно сделать часы реального времени, если озаботиться его непрерывным питанием.