За arm Linux могат ли нишките в потребителското пространство да имат достъп до виртуалния адрес на пространството на ядрото?

Виртуалната памет е разделена на две части. Традиционно 0~3GB е за потребителско пространство и 3GB~4GB за пространство на ядрото.

Въпросът ми:

Може ли нишката в потребителското пространство да има достъп до паметта на пространството на ядрото?

За листа с данни на ARM приписването на достъпа е в отговорността на регистъра за контрол на достъпа до домейна. Но в изходния код на ядрото стойността на домейна в записа на таблицата на страниците на виртуалната памет на потребителското пространство е същата като записа на таблицата на страниците на пространството на ядрото.


person Haifeng Li    schedule 30.06.2012    source източник
comment
Получих отговора. Управлението на разрешения за достъп все още разчита на полето за домейн и AP в записа в таблицата на страниците и регистъра за контрол на достъпа на домейна. Преди 2.6.38 кодът за стартиране инициализира DOMAIN_USER от DOMAIN_MANAGER. Но в early_trap_init системата ще промени DOMAIN_USER на DOMAIN_CLIENT. И когато атрибутът на домейна е DOMAIN_CLIENT, полето AP в записа в таблицата на страницата ще бъде ефективно. Благодаря за следните отговори.   -  person Haifeng Li    schedule 07.07.2012


Отговори (2)


Всъщност вашето приложение може да получи достъп до страница 0xFFFF0000, тъй като съдържа swi-обработчик и няколко други помощни средства за потребителско пространство. Така че не, разделянето 3/1 не е нищо магическо, просто е много лесно за управление от ядрото.

Обикновено ядрото ще настрои цялата памет над 3 GB да бъде достъпна само от самия домейн на ядрото. Ако драйверът трябва да споделя памет между потребителя и пространството на ядрото, той обикновено предоставя mmap интерфейс, който след това създава съпоставяне с псевдоними, така че имате два виртуални адреса за един и същ физически адрес. Това работи надеждно само на VIPT-Cache системи или с МНОГО внимателно явно промиване на кеша. Ако не искате това, МОЖЕТЕ да хакнете ядрото, за да направите част от паметта НАД 3G-сплита достъпна за потребителското пространство. Но тогава всички приложения на потребителското пространство ще споделят тази памет. Направих това веднъж за специално приложение на armv5-система.

person Nico Erfurth    schedule 30.06.2012
comment
Благодаря за вашият отговор. Съгласен съм. Казвате, че виртуален адрес над 3 GB може да бъде достъпен само от самия domain-kernel и да бъде блокиран от user-domain. Бихте ли представили накратко как да го приложите? - person Haifeng Li; 01.07.2012
comment
Имам отговора. Благодаря ти. - person Haifeng Li; 07.07.2012

Кодът на потребителското пространство получава памет на ядрото? Единственото ядро, което някога е позволявало това, е DOS и неговите архаични приятели. Но обратно към въпроса, вижте този примерен C код:

char c=42;
*c=42;

Взимаме един байт (a char) и му присвояваме числовата стойност 42. След това дереферираме този неуказател, който вероятно ще се опита да получи достъп до 42-ия байт виртуална памет, която почти определено не е вашата памет и, в името на този пример, памет на ядрото. познайте какво се случва, когато стартирате това (ако успеете да задържите компилатора на мушка):

Segmentation fault

Linux има защита на паметта като всяка съвременна операционна система. Ако се опитате да получите достъп до паметта на друг процес, вашият процес ще бъде прекратен, преди да може да направи нещо (други неща, за които не съм толкова сигурен обаче, се случват с дебъгерите). Дори тази памет да е на друг процес на Userland, пак ще бъдете прекратени. Почти съм сигурен, че root програмите нямат достъп до паметта на други програми или паметта на ядрото. Единственият начин за достъп до паметта на ядрото е да бъдете част от ядрото или индиректно чрез сътрудничеството на ядрото.

person Linuxios    schedule 30.06.2012
comment
Достатъчно привилегированото потребителско пространство може да отвори /dev/kmem на Linux (ако е конфигурирано в), което е виртуална памет на ядрото ;-) - person ephemient; 30.06.2012
comment
@ephemient: Наистина ли? Но достатъчно привилегированото все още не означава, че може да се пише, нали? Или е достатъчно привилегирован просто като root? - person Linuxios; 30.06.2012
comment
Ако ядрото е конфигурирано с CONFIG_DEVKMEM=y и няма LSM (като SELinux), блокиращи достъпа, наличието на CAP_SYS_RAWIO (root има всички възможности и те могат да бъдат предоставени на други процеси) е достатъчно за четене и запис на /dev/kmem. Имало едно време това е начинът, по който зареждането на модули работеше, но това вече не е така. - person ephemient; 01.07.2012
comment
@ephemient: Наистина ли? Странно. Но ако използвате инструмент при тестване с root достъп, опитвайки се да проникнете в ядрото, вероятно правите нещо нередно. - person Linuxios; 01.07.2012
comment
Има също API, които споделят потребителска памет и пространство на ядрото, като packet-mmap, те обикновено ще mmap kernelspace в потребителско пространство, използвайки същия физически адрес, но различни виртуални адреси. В момента НЯМА интерфейс на ядрото, който позволява споделянето на един и същ физически И виртуален адрес. Но вие МОЖЕТЕ (и аз вече го направих) да създадете памет на ядрото, която е достъпна от всички процеси в потребителското пространство. Това е много хакерски и специфичен за архитектурата подход, но беше необходим за специално приложение (споделяне на памет без проблеми с псевдонимите, въведени от VIVT-DCache) в ограничена среда. - person Nico Erfurth; 07.07.2012