Ioctl - Википедия - ioctl

В вычисление, ioctl (сокращение от управление вводом / выводом) это системный вызов для конкретного устройства ввод, вывод операции и другие операции, которые нельзя выразить обычными системными вызовами. Требуется параметр, указывающий код запроса; эффект вызова полностью зависит от кода запроса. Коды запросов часто зависят от устройства. Например, CD-ROM драйвер устройства который может дать команду физическому устройству извлечь диск, обеспечит ioctl запросить код для этого. Коды запросов, не зависящие от устройства, иногда используются для пространство пользователя доступ к функциям ядра, которые используются только основным системным программным обеспечением или все еще находятся в стадии разработки.

В ioctl системный вызов впервые появился в Версия 7 из Unix под этим именем. Он поддерживается большинством Unix и Unix-подобный системы, в том числе Linux и macOS, хотя доступные коды запросов различаются от системы к системе. Майкрософт Виндоус предоставляет аналогичную функцию под названием "DeviceIoControl"в своем Win32 API.

Фон

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

Пространство пользователя приложения обычно делают запросы к ядру с помощью системные вызовы, код которого лежит на уровне ядра. Системный вызов обычно принимает форму «вектора системного вызова», в котором желаемый системный вызов обозначается порядковым номером. Например, выход() может быть системный вызов номер 1 и записывать() номер 4. Затем вектор системного вызова используется для нахождения желаемой функции ядра для запроса. Таким образом, обычные операционные системы обычно предоставляют несколько сотен системных вызовов пользовательскому пространству.

Несмотря на то, что это целесообразная конструкция для доступа к стандартным возможностям ядра, системные вызовы иногда не подходят для доступа к нестандартным периферийным устройствам. По необходимости, большинство аппаратных периферийных устройств (также называемых устройствами) имеют прямую адресацию только внутри ядра. Но пользовательскому коду может потребоваться прямая связь с устройствами; например, администратор может настроить тип носителя на Ethernet интерфейс. Современные операционные системы поддерживают различные устройства, многие из которых предлагают большой набор функций. Некоторые из этих возможностей могут быть не предусмотрены разработчиком ядра, и, как следствие, ядру трудно обеспечить системные вызовы для использования устройств.

Чтобы решить эту проблему, ядро ​​разработано с возможностью расширения и может принимать дополнительный модуль, называемый драйвер устройства который работает в пространстве ядра и может напрямую обращаться к устройству. An ioctl интерфейс - это единственный системный вызов, с помощью которого пользовательское пространство может взаимодействовать с драйверами устройств. Запросы к драйверу устройства направляются с учетом этого ioctl системный вызов, обычно с помощью дескриптора устройства и номера запроса. Таким образом, базовое ядро ​​может позволить пользовательскому пространству получить доступ к драйверу устройства, ничего не зная о средствах, поддерживаемых устройством, и без необходимости в неуправляемом большом наборе системных вызовов.

Использует

Конфигурация аппаратного устройства

Обычное использование ioctl для управления аппаратными устройствами.

Например, на Win32 системы, ioctl звонки могут общаться с USB устройства, или они могут обнаружить информацию о геометрии дисков подключенных запоминающих устройств.

На OpenBSD и NetBSD, ioctl используется био (4) драйвер псевдоустройства и биоктл утилита для реализации RAID управление томами в едином интерфейсе, не зависящем от поставщика, похожем на ifconfig.[1][2]

На NetBSD, ioctl также используется sysmon рамки.[3]

Терминалы

Одно использование ioctl в коде, доступном для приложений конечного пользователя, используется терминальный ввод-вывод.

Unix операционные системы традиционно интенсивно использовали интерфейсы командной строки. Интерфейс командной строки Unix построен на псевдотерминалы (ptys), которые имитируют аппаратные текстовые терминалы, такие как VT100s. Pty управляется и настраивается, как если бы это было аппаратное устройство, используя ioctl звонки. Например, размер окна pty устанавливается с помощью параметра TIOCSWINSZ вызов. Функция ioctl TIOCSTI (управление вводом / выводом терминала, имитация ввода / вывода терминала) может помещать символ в поток устройства.[4]

Расширения ядра

Когда приложениям необходимо расширить ядро, например, для ускорения сетевой обработки, ioctl звонки обеспечивают удобный способ соединения пространство пользователя код для расширений ядра. Расширения ядра может предоставить место в файловой системе, которое можно открыть по имени, через которое произвольное количество ioctl вызовы могут быть отправлены, что позволяет программировать добавочный номер без добавления системных вызовов в операционную систему.

альтернатива sysctl

Согласно OpenBSD разработчик ioctl и sysctl два системные вызовы для расширения ядра, с sysctl возможно, самый простой из двух.[5]

В NetBSD, то sysmon_envsys рамки для аппаратный мониторинг использует ioctl через проплиб; в то время как OpenBSD и DragonFly BSD вместо этого используйте sysctl для их соответствующих hw.sensors рамки. Первоначальная редакция envsys в NetBSD был реализован с ioctl перед проплиб был доступен и содержал сообщение о том, что фреймворк является экспериментальным и его следует заменить на sysctl (8) интерфейс, если он будет разработан,[6][7] что потенциально объясняет выбор sysctl в OpenBSD с последующим введением hw.sensors в 2003 году. Однако когда envsys фреймворк был переработан в 2007 г. проплибсистемный вызов остался как ioctl, и сообщение было удалено.[8]

Реализации

Unix

В ioctl системный вызов впервые появился в Версия 7 Unix, как переименованный stty.[9] An ioctl звонок принимает как параметры:

  1. открытый дескриптор файла
  2. номер кода запроса
  3. либо целочисленное значение, возможно, без знака (передается драйверу), либо указатель к данным (либо переход к драйверу, либо возвращение от драйвера, либо и то, и другое.

В ядро обычно отправляет ioctl вызовите прямо к драйверу устройства, который может интерпретировать номер запроса и данные любым необходимым способом. Авторы каждого документа драйвера запрашивают номера для этого конкретного драйвера и предоставляют их как константы в заголовочный файл.

Некоторые системы Unix, включая Linux, имеют соглашения, которые кодируют в номере запроса размер данных, которые должны быть переданы в / из драйвера устройства, направление передачи данных и идентификатор драйвера, реализующего запрос. Независимо от того, соблюдается ли такое соглашение, ядро ​​и драйвер взаимодействуют, чтобы предоставить единый код ошибки (обозначенный символической константой ENOTTY) приложению, которое запрашивает драйвер, который его не распознает.

Мнемоника ENOTTY (традиционно ассоциируется с текстовым сообщением "Не пишущая машинка ") происходит от самых ранних систем, которые включали ioctl звоните, где только телетайп (tty) устройство вызвало эту ошибку. Хотя символическая мнемоника фиксируется требованиями совместимости, некоторые современные системы более эффективно передают более общее сообщение, такое как "Несоответствующая операция управления устройством"(или локализация из них).

TCSETS служит примером ioctl позвонить на Серийный порт. Обычные вызовы чтения и записи через последовательный порт принимают и отправляют байты данных. An ioctl (fd, TCSETS, данные) вызов, отдельный от такого обычного ввода-вывода, управляет различными параметрами драйвера, такими как обработка специальных символы, или выходные сигналы порта (например, DTR сигнал).

Win32

Win32 DeviceIoControl принимает в качестве параметров:

  1. дескриптор открытого объекта (эквивалент дескриптора файла в Win32)
  2. номер кода запроса («контрольный код»)
  3. буфер для входных параметров
  4. длина входного буфера
  5. буфер для результатов вывода
  6. длина выходного буфера
  7. ан ПЕРЕСЕЧЕННЫЙ структура, если перекрывающийся ввод / вывод используется.

Управляющий код устройства Win32 учитывает режим выполняемой операции.

Существует 4 определенных режима работы, влияющих на безопасность драйвера устройства:

  1. METHOD_IN_DIRECT: Адрес буфера проверяется на возможность чтения вызывающей стороной пользовательского режима.
  2. METHOD_OUT_DIRECT: Адрес буфера проверяется на возможность записи вызывающей стороной пользовательского режима.
  3. METHOD_NEITHER: Виртуальные адреса пользовательского режима передаются драйверу без сопоставления и проверки.
  4. METHOD_BUFFERED: Управляемые диспетчером ввода-вывода общие буферы используются для перемещения данных в пользовательский режим и из него.

Альтернативы

Другие интерфейсы векторных вызовов

Устройства и расширения ядра могут быть связаны с пространство пользователя использование дополнительных новых системных вызовов, хотя этот подход применяется редко, потому что разработчики операционных систем стараются сохранить интерфейс системных вызовов сфокусированным и эффективным.

В операционных системах Unix популярны два других интерфейса векторных вызовов: fcntl ("управление файлами") системный вызов настраивает открытые файлы и используется в таких ситуациях, как включение неблокирующий ввод / вывод; и Setsockopt ("установить параметр сокета") системный вызов настраивает open сетевые розетки, средство, используемое для настройки ipfw межсетевой экран пакетов включен BSD Unix системы.

Отображение памяти

Unix
Интерфейсы устройств и возможности ввода / вывода иногда предоставляются с использованием файлы с отображением памяти. Приложения, которые взаимодействуют с устройствами, открывают место в файловой системе, соответствующее устройству, как и для ioctl вызов, но затем используйте системные вызовы отображения памяти, чтобы связать часть их адресного пространства с пространством ядра. Этот интерфейс - гораздо более эффективный способ обеспечить массовую передачу данных между устройством и пространство пользователя заявление; индивидуальный ioctl или системные вызовы чтения / записи вызывают накладные расходы из-за повторяющихся переходов от пользовательского пространства к ядру, когда доступ к диапазону адресов, отображаемых в памяти, не несет таких накладных расходов.
Win32
Могут использоваться буферизованные методы ввода-вывода или именованные объекты отображения файлов; однако для простых драйверов устройств стандартный DeviceIoControl МЕТОД_ доступов достаточно.

Netlink

Netlink подобный сокету механизм для межпроцессного взаимодействия (IPC), призванный стать более гибким преемником ioctl.

Подразумеваемое

Сложность

ioctl вызовы минимизируют сложность интерфейса системных вызовов ядра. Тем не менее, предоставляя разработчикам место для «спрятать» кусочки интерфейсов программирования ядра, ioctl вызовы усложняют общий API взаимодействия пользователя с ядром. Ядро, которое предоставляет несколько сотен системных вызовов, может обеспечивать несколько тысяч вызовов ioctl.

Хотя интерфейс к ioctl вызовы выглядят несколько иначе, чем обычные системные вызовы, на практике разница между ioctl звонок и системный звонок; ан ioctl call - это просто системный вызов с другим механизмом диспетчеризации. Поэтому многие аргументы против расширения интерфейса системного вызова ядра можно применить к ioctl интерфейсы.

Для разработчиков приложений системные вызовы не отличаются от подпрограмм приложения; это просто вызовы функций, которые принимают аргументы и возвращают значения. В время выполнения библиотеки ОС маскируют сложность, связанную с вызовом системных вызовов. К сожалению, библиотеки времени выполнения не делают ioctl называет прозрачным. Простые операции, такие как обнаружение IP-адреса для машины часто требуются запутанные беспорядки ioctl звонки, каждый из которых требует магические числа и структуры аргументов.[нужна цитата ]

Libpcap и libdnet являются двумя примерами сторонних библиотек-оболочек Unix, предназначенных для маскировки сложности ioctl интерфейсы для захвата пакетов и ввода-вывода пакетов соответственно.

Безопасность

Интерфейсы «пользователь-ядро» в основных операционных системах перед выпуском часто подвергаются тщательному аудиту на предмет ошибок кода и уязвимостей безопасности. Эти аудиты обычно фокусируются на хорошо задокументированных интерфейсах системных вызовов; например, аудиторы могут гарантировать, что конфиденциальные вызовы безопасности, такие как изменение идентификаторов пользователей, доступны только администраторам.

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

Поскольку обработчик ioctl вызов находится непосредственно в режиме ядра, вход от пространство пользователя следует тщательно проверять. Уязвимости в драйверах устройств могут использоваться локальными пользователями, передавая недопустимые буферы в ioctl звонки.

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

Некоторые современные операционные системы защищают ядро ​​от враждебных пространство пользователя код (например, приложения, зараженные переполнение буфера эксплойты) с использованием оболочки системных вызовов. Реализация оберток системных вызовов управление доступом на основе ролей указав, какие системные вызовы могут быть вызваны какими приложениями; Обертки могут, например, использоваться для "отзыва" права почтовой программы на порождение других программ. ioctl интерфейсы усложняют обертки системных вызовов, потому что их большое количество, каждая из которых принимает разные аргументы, некоторые из которых могут потребоваться для обычных программ.

дальнейшее чтение

  • В. Ричард Стивенс, Расширенное программирование в среде UNIX (Аддисон-Уэсли, 1992, ISBN  0-201-56317-7), раздел 3.14.
  • Общие операции управления вводом-выводом в онлайн-руководстве для Библиотека GNU C
  • ioctl (2) – Версия 7 Unix Программиста Руководство
  • ioctl (2) – Linux Программиста Руководство - Системные вызовы
  • ioctl (2) – FreeBSD Системные вызовы Руководство
  • ioctl (2) – OpenBSD Системные вызовы Руководство
  • ioctl (2) – Solaris 10 Справочник по системным вызовам Руководство
  • "Документация по DeviceIoControl на Сеть разработчиков Microsoft

Рекомендации

  1. ^ Никлас Халлквист (2002); Марко Перебум (2006). "bio (4) - псевдоустройство туннеля блочного ввода / вывода ioctl". Перекрестная ссылка BSD. OpenBSD. Сложить резюме.
  2. ^ Марко Перебум (2005). "bioctl (8) - интерфейс управления RAID". Перекрестная ссылка BSD. OpenBSD. Сложить резюме.
  3. ^ "sysmon (4) - интерфейс системного мониторинга и управления питанием". NetBSD. Интерфейс ioctl (2) доступен через / dev / sysmon.
  4. ^ Кристиансен, Том; Торкингтон, Натан (1998). «12: Пакеты, библиотеки и модули». Поваренная книга Perl: решения и примеры для программистов на Perl (2-е изд.). Севастополь, Калифорния: O'Reilly Media, Inc. (опубликовано в 2003 г.). п. 482. ISBN  9780596554965. Получено 2016-11-15. [...] TIOCSTI [...] означает «управление вводом / выводом терминала, имитация ввода терминала». В системах, которые реализуют эту функцию, он будет помещать один символ в поток вашего устройства, так что в следующий раз, когда какой-либо процесс будет читать с этого устройства, он получит введенный вами символ.
  5. ^ Федерико Бьянкуцци (2004-10-28). «OpenBSD 3.6 Live». ONLamp. O'Reilly Media. Получено 2019-03-20. Есть два системных вызова, которые можно использовать для добавления функций к ядру (без добавления еще одного системного вызова): ioctl (2) и sysctl (3). Последний был выбран потому, что реализовать новую функцию было очень просто.
  6. ^ Тим Райтнур; Билл Сквайер (19 декабря 2007 г.). "envsys - API экологических систем". NetBSD 4.0. Этот API является экспериментальным и может быть объявлен устаревшим в любой момент ... Весь этот API должен быть заменен интерфейсом sysctl (8) или механизмом событий ядра, если он будет разработан.
  7. ^ Константин Александрович Муренин (17.04.2007). «3.5. NetBSD sysmon (4)». Обобщенное взаимодействие с аппаратными мониторами микропроцессорной системы. Материалы Международной конференции IEEE 2007 г. по сетям, зондированию и контролю, 15–17 апреля 2007 г. Лондон, Соединенное Королевство: IEEE. С. 901–906. Дои:10.1109 / ICNSC.2007.372901. ISBN  978-1-4244-1076-7. IEEE ICNSC 2007, стр. 901–906.
  8. ^ Константин Александрович Муренин (21.05.2010). «6.1. Хронология разработки; 7.1. NetBSD envsys / sysmon». Аппаратные датчики OpenBSD - мониторинг окружающей среды и управление вентиляторами (MMath Тезис). Университет Ватерлоо: UWSpace. HDL:10012/5234. Идентификатор документа: ab71498b6b1a60 ff817 b29d56997a418.
  9. ^ Макилрой, М.Д. (1987). Читатель Research Unix: аннотированные выдержки из Руководства программиста, 1971–1986 (PDF) (Технический отчет). CSTR. Bell Labs. 139.