Главная » Ядро Linux » Реализация системных вызовов

0

Реализация системного вызова  в ОС  Linux  не  связана с поведением обработчика системных вызовов. Добавление нового  системного вызова  в операционной системе Linux  является сравнительно простым делом.  Тяжелая работа  связана с разработкой и реализацией самого   системного вызова.  Регистрация  его  в ядре  проста. Давайте рассмотрим шаги, которые необходимо предпринять, чтобы  написать новый системный  вызов  в операционной системе Linux.

Первый шаг в реализации системного вызова — это  определение его назначения, т.е.  что  он  должен  делать.  Каждый системный вызов  должен  иметь  только  одно  назначение.  Мультиплексные системные вызовы (один   системный вызов, который выполняет большой набор  различных операций,  в зависимости от значения флага, передаваемого в качестве аргумента) в операционной системе Linux  использовать не рекомендуется. Для  примера того, как  не надо делать,  можно обратиться к системной функции ioctl() .

Какие должны быть  аргументы, возвращаемые значения  и коды  ошибок для  новой  системной функции? Системная функция должна  иметь  понятный и простой интерфейс, по  возможности с меньшим количеством аргументов. Семантика и  поведение  системных функций — это очень  важные вещи, они  не должны меняться, потому что  от  них  будет  зависеть работа  прикладных программ.

Важным является разработка интерфейса с прицелом  на  будущее.  Не  ограничены  ли  возможности функции без  необходимости? Разрабатываемый системный  вызов  должен   быть  максимально общим. Не  нужно   полагать,  что  завтра  он  будет  использоваться так  же, как  сегодня. Назначение  системного вызова  должно оставаться постоянным,  но  его  использование  может  меняться. Является ли  системный вызов переносимым? Не  нужно  делать  допущений о возможном  размере машинного  слова или  порядка следования байтов.  В главе  19, "Переносимость",  рассматриваются соответствующие вопросы.  Нужно удостовериться,  что  никакие  неверные допущения не  будут  мешать  использованию системного вызова  в будущем.   Помните девиз  Unix: "Обеспечивать механизм,  а не  стратегию".

При  разработке системного вызова  важно  помнить, что  переносимость и устойчивость необходимы не только  сегодня, но  и будут необходимы в будущем.  Основные системные вызовы ОС  Unix  выдержали это  испытание временем. Большинство из них  такие  же  полезные и применимые сегодня, как  и почти  тридцать лет назад!

Проверка параметров

Системные вызовы должны тщательно проверять все  свои  параметры для  того, чтобы  убедиться, что  их значения адекватны и законны.  Системные вызовы выполняются в пространстве ядра, и если  пользователь может  передать неправильные значения ядру, то  стабильность и  безопасность системы могут  пострадать.

Например,  системные вызовы для  файлового ввода-вывода данных  должны проверить, является ли  значение файлового дескриптора допустимым. Функции,  связанные с управлением процессами,  должны проверить, является ли  значение переданного идентификатора  PID  допустимым. Каждый  параметр должен   проверяться не  только   на  предмет  допустимости и  законности,  но  и на  предмет  правильности значения.

Одна  из  наиболее важных  проверок— это  проверка указателей, которые передает пользователь. Представьте, что процесс может  передать любой  указатель, даже  тот, который  указывает на область  памяти, не  имеющей прав  чтения!  Процесс может  таким обманом заставить ядро  скопировать данные, к которым процесс не имеет  доступа, например данные, принадлежащие другому процессу. Перед  тем  как  следовать указателю, переданному из  пространства пользователя,  система должна  убедиться в следующем.

• Указатель указывает на  область  памяти в  пространстве пользователя.  Нельзя, чтобы  процесс заставил ядро  обратиться к памяти ядра  от  имени  процесса.

• Указатель указывает на  область  памяти в  адресном пространстве текущего  процесса.   Нельзя позволять,  чтобы  процесс заставил ядро  читать  данные  других процессов.

• Для  операций чтения есть  права  на  чтение  области памяти. Для  операций  записи  есть  права  на  запись области памяти.  Нельзя,  чтобы  процессы  смогли  обойти ограничения на чтение  и запись.

Ядро  предоставляет две  функции для  выполнения  необходимых проверок  при копировании данных  в пространство пользователя и из  него.  Следует  помнить, что ядро  никогда не должно слепо  следовать за указателем в пространстве пользователя! Одна  из  этих  двух функций должна  использоваться всегда.

Для  записи в пространство пользователя предоставляется функция copy_to_user () . Она  принимает три  параметра: адрес  памяти назначения в пространстве пользователя;  адрес  памяти источника в пространстве ядра;  и размер  данных, которые необходимо  скопировать, в байтах.

Для  чтения из  пространства пользователя используется функция  copy_from_user (), которая аналогична функции  copy_to_use r  () . Эта функция считывает данные, на которые указывает второй   параметр, в  область  памяти,  на  которую указывает первый  параметр, количество данных  — третий  параметр.

Обе  эти  функции возвращают количество байтов, которые они  не  смогли  скопировать  в случае  ошибки. При  успешном выполнении  операции возвращается нуль. В случае  такой  ошибки стандартным является возвращение системным вызовом значения -EFAULT.

Давайте рассмотрим пример системного вызова,  который  использует функции copy_from_use r ()   и  copy_to_use r () .  Системный  вызов   silly_cop y ()   является до крайности  бесполезным. Он  просто   копирует данные из  своего  первого параметра во второй. Это  очень  не эффективно, так как  используется дополнительное промежуточное копирование  в  пространство ядра  безо  всякой причины. Но  зато  это позволяет проиллюстрировать суть  дела.

/*

* Системный вызов 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_use r ()   и  copy_to_use r () , могут блокироваться. Это возникает, например, если  страница памяти, содержащая данные  пользователя, не находится в физической памяти, а в данный момент вытеснена на диск.  В таком  случае  процесс будет  находиться в приостановленном состоянии до тек  пор, пока  обработчик прерываний из-за отсутствия страниц (page  fault  handler) не  возвратит страницу памяти в оперативную память из файла  подкачки на диске.

Последняя  проверка — это  проверка на  соответствие правам доступа.   В  старых версиях ядра  Linux  стандартом  было  использование функции  suse r ()   для  системных  вызовов,  которые требуют  прав  пользователя root .  Эта  функция просто   проверяла,  запущен ли  процесс  от  пользователя  root .  Сейчас эту  функцию убрали  и заменили более  мелко   структурированным  набором  системных "возможностей  использования"  (capabilities). В новых  системах предоставляется возможность проверять  специфические права  доступа  к специфическим  ресурсам. Функция  capabl e ()

с допустимым значением флага, определяющего тип  прав, возвращает ненулевое значение, если  пользователь обладает  указанным правом, и  нуль—  в противном случае. Например, вызов  capabl e (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> .

Источник: Лав,  Роберт. Разработка ядра  Linux, 2-е  издание. : Пер.  с англ.  — М.  : ООО  «И.Д.  Вильяме» 2006. — 448 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии