Ядро предоставляет две функции для выполнения необходимых проверок при копировании данных в пространство пользователя и из него. Следует помнить, что ядро никогда не должно слепо следовать за указателем в пространстве пользователя! Одна из этих двух функций должна использоваться всегда.
Для записи в пространство пользователя предоставляется функция
copy_to_user
. Она принимает три параметра: адрес памяти назначения в пространстве пользователя; адрес памяти источника в пространстве ядра; и размер данных, которые необходимо скопировать, в байтах.
Для чтения из пространства пользователя используется функция
copy_from_user
, которая аналогична функции
copy_to_user
. Эта функция считывает данные, на которые указывает второй параметр, в область памяти, на которую указывает первый параметр, количество данных — третий параметр.
Обе
эти функции возвращают количество байтов, которые они не смогли скопировать в случае ошибки. При успешном выполнении операции возвращается нуль. В случае такой ошибки стандартным является возвращение системным вызовом значения
– EFAULT
.
Давайте рассмотрим пример системного вызова, который использует функции
copy_from_user
и
copy_to_user
. Системный вызов
silly_copy
является до крайности бесполезным. Он просто копирует данные из своего первого параметра во второй. Это очень не эффективно, так как используется дополнительное промежуточное копирование в пространство ядра безо всякой причины. Но зато это позволяет проиллюстрировать суть дела.
/*
* Системный вызов silly copy — крайне бесполезная функция,
* которая копирует len байтов из области памяти,
* на которую указывает параметр src, в область памяти,
* на которую указывает параметр dst, с использованием ядра
* безо всякой на то причины. Но это хороший пример!
*/
asmlinkage long sys_silly_copy(unsigned long *src,
unsigned long *dst, unsigned long len) {
unsigned long buf;
/* возвращаем ошибку, если размер машинного слова в ядре
не совпадает с размером данных, переданных пользователем */
if (len != sizeof(buf))
return -EINVAL;
/* копируем из src, который является адресом в пространстве
пользователя, в buf */
if (copy_from_user(&buf, src, len))
return -EFAULT;
/* копируем из buf в dst, который тоже является адресом
в пространстве пользователя */
if (copy_to_user(dst, &buf, len))
return -EFAULT;
/* возвращаем количество скопированных данных */
return len;
}
Следует заметить, что обе функции,
copy_from_user
и
copy_to_user
, могут блокироваться. Это возникает, например, если страница памяти, содержащая данные пользователя, не находится в физической памяти, а в данный момент вытеснена на диск. В таком случае процесс будет находиться в приостановленном состоянии до тек пор, пока обработчик прерываний из-за отсутствия страниц (page fault handler) не возвратит страницу памяти в оперативную память из файла подкачки на диске.
Последняя проверка — это проверка на соответствие правам доступа. В старых версиях ядра Linux стандартом было использование функции
suser
для системных вызовов, которые требуют прав пользователя root. Эта функция просто проверяла, запущен ли процесс от пользователя root. Сейчас эту функцию убрали и заменили более мелко структурированным набором системных "возможностей использования" (capabilities). В новых системах предоставляется возможность проверять специфические права доступа к специфическим ресурсам. Функция
capable
с допустимым значением флага, определяющего тип прав, возвращает ненулевое значение, если пользователь обладает указанным правом, и нуль— в противном случае. Например, вызов
capable
(
CAP_SYS_NICE
) проверяет, имеет ли вызывающий процесс возможность модифицировать значение параметра nice других процессов. По умолчанию суперпользователь владеет всеми правами, а пользователь, не являющийся пользователем root, не имеет никаких дополнительных прав. Следующий пример системного вызова, который демонстрирует использование возможностей использования, тоже является практически бесполезным.
asmlinkage long sys_am_i_popular(void) {
/*
Проверить, имеет пи право процесс использовать
возможность CAP_SYS_NICE */
if (!capable(CAP_SYS_NICE))
return -EPERM;
/* Возвратить нуль, чтобы обозначить успешное завершение */
return 0;
}
Список всех "возможностей использования" и прав, которые за ними закреплены, содержится в файле
<linux/capability.h>
.
Контекст системного вызова
Как уже обсуждалось в главе 3, "Управление процессами", при выполнении системного вызова ядро работает в контексте процесса. Указатель
current
указывает на текущее задание, которое и есть процессом, выполняющим системный вызов.
В контексте процесса ядро может переходит в приостановленное состояние (например, если системный вызов блокируется при вызове функции или явно вызывает функцию
schedule
), а также является полностью вытесняемым. Эти два момента важны. Возможность переходить в приостановленное состояние означает, что системный вызов может использовать большую часть функциональных возможностей ядра. Как будет видно из главы 6, "Прерывания и обработка прерываний", наличие возможности переходить в приостановленное состояние значительно упрощает программирование ядра [29] . Тот факт, что контекст процесса является вытесняемым, подразумевает, что, как и в пространстве пользователя, текущее задание может быть вытеснено другим заданием. Так как новое задание может выполнить тот же системный вызов, необходимо убедиться, что системные вызовы являются реентерабельными. Это очень похоже на требования, выдвигаемые для симметричной мультипроцессорной обработки. Способы защиты, которые обеспечивают реентерабельность, описаны в главе 8, "Введение в синхронизацию выполнения кода ядра", и в главе 9, "Средства синхронизации в ядре".
29
Обработчики прерываний не могут переходить в приостановленное состояние и, следовательно, более ограничены в своих действиях по сравнению с системными вызовами, которые работают в контексте процесса.
После завершение системного вызова управление передается обратно в функцию
system_call
, которая в конце концов производит переключение в пространство пользователя, и далее выполнение пользовательского процесса продолжается.
Окончательные шаги регистрации системного вызова
После того как системный вызов написан, процедура его регистрации в качестве официального системного вызова тривиальна и состоит в следующем.
• Добавляется запись в конец таблицы системных вызовов. Это необходимо сделать для всех аппаратных платформ, которые поддерживают этот системный вызов (для большинства системных вызовов — это все возможные платформы). Положение системного вызова в таблице — это номер системного вызова, начиная с нуля. Например, десятая запись таблицы соответствует системному вызову с номером девять.
• Для всех поддерживаемых аппаратных платформ номер системной функции должен быть определен в файле
include/linux/unistd.h
.
• Системный вызов должен быть вкомпилирован в образ ядра (в противоположность компиляции в качестве загружаемого модуля [30] ). Это просто соответствует размещению кода в каком-нибудь важном файле каталога
kernel/
.
Давайте более детально рассмотрим эти шаги на примере функции системного вызова,
foo
. Вначале функция
sys_fоо
должна быть добавлена в таблицу системных вызовов. Для большинства аппаратных платформ таблица системных вызовов размещается в файле
entry.S
и выглядит примерно следующим образом.
30
Регистрации новых постоянных системных вызовов в ядре требует компиляции системного вызова в образ ядра. Тем не менее есть принципиальная возможность с помощью динамически загружаемого модуля ядра перехватить существующие системные вызовы и даже, ценой некоторых усилий, динамически зарегистрировать новые. — Примеч. перев.