동작하다

ioctl


컴퓨팅에서는ioctl(input/output control의 약자)는 디바이스 고유의 입출력 조작 및 일반 시스템콜로는 표현할 수 없는 기타 조작을 위한 시스템콜입니다요청 코드를 지정하는 파라미터를 사용합니다.콜의 효과는 요청 코드에 따라 완전히 달라집니다.요청 코드는 대부분의 경우 디바이스에 고유합니다.예를 들어 CD-ROM 디바이스 드라이버는 물리 디바이스에 디스크 이젝트를 지시할 수 있습니다.ioctl이를 위한 코드를 요청합니다.디바이스에 의존하지 않는 요구 코드는 코어 시스템소프트웨어에 의해서만 사용되고 있거나 아직 개발중인 커널 기능에 대한 사용자 공간의 액세스를 제공하기 위해서도 사용됩니다.

그ioctl시스템 콜은 Unix 버전7에서 이 이름으로 처음 등장했습니다.Linux 및 MacOS를 포함한 대부분의 Unix 및 Unix 유사 시스템에서 지원되지만 사용 가능한 요청 코드는 시스템에 따라 다릅니다.Microsoft Windows 에서는, 「」라고 하는 같은 기능을 제공하고 있습니다.DeviceIoControl", Win32 API에 포함되어 있습니다.

배경

기존 운영체제는 사용자 공간과 커널의 두 계층으로 나눌 수 있습니다.텍스트 에디터와 같은 응용 프로그램코드는 사용자 공간에 존재하며 네트워크 스택과 같은 운영체제의 기본설비는 커널에 존재합니다.커널 코드는 기밀 리소스를 처리하고 애플리케이션 간의 보안 및 신뢰성의 장벽을 구현합니다.이 때문에 운영체제는 사용자 모드 애플리케이션을 커널 리소스에 직접 액세스하지 못하게 합니다.

사용자 공간 애플리케이션은 일반적으로 시스템 호출을 통해 커널에 요청을 합니다. 시스템 호출의 코드는 커널 계층에 있습니다.시스템 콜은 보통 "시스템 콜 벡터"의 형태를 취하며, 여기서 원하는 시스템콜은 인덱스 번호로 표시됩니다.예를 들어.exit()시스템 콜 번호1 이 될 수 있습니다.write()4번입니다.그런 다음 시스템 콜 벡터를 사용하여 요청에 필요한 커널 함수를 찾습니다.이와 같이 기존 운영체제는 일반적으로 수백 개의 시스템 호출을 사용자 공간에 제공합니다.

표준 커널 퍼실리티에 액세스하기 위한 편리한 설계이지만 시스템콜은 비표준 하드웨어 주변기기에 액세스하기에 부적절한 경우가 있습니다.대부분의 하드웨어 주변기기(일명 디바이스)는 커널 내에서만 직접 주소를 지정할 수 있습니다.단, 사용자 코드는 디바이스와 직접 통신해야 할 수 있습니다.예를 들어 관리자가 이더넷인터페이스로 미디어 타입을 설정할 수 있습니다.최신 운영 체제는 다양한 장치를 지원하며, 그 중 많은 장치가 다양한 기능을 제공합니다.이러한 기능 중 일부는 커널 설계자에 의해 예측되지 않을 수 있으며, 그 결과 커널이 디바이스 사용에 대한 시스템 호출을 제공하기가 어렵습니다.

이 문제를 해결하기 위해 커널은 확장 가능하도록 설계되어 있으며 커널 공간에서 실행되며 디바이스를 직접 주소 지정할 수 있는 디바이스 드라이버라고 불리는 추가 모듈을 수용할 수 있습니다.한ioctlinterface는 사용자 공간이 디바이스 드라이버와 통신할 수 있는 단일 시스템콜입니다디바이스 드라이버의 요구는, 이것에 관해서 벡터 됩니다.ioctl시스템 콜(통상은, 디바이스에의 핸들 및 요구 번호에 의해서).따라서 기본 커널을 통해 사용자는 디바이스에서 지원되는 기능에 대해 아무것도 알지 못하고 관리 불가능한 대규모 시스템콜 컬렉션을 필요로 하지 않고 디바이스 드라이버에 액세스 할 수 있습니다.

사용하다

하드웨어 디바이스 설정

의 일반적인 용도ioctl하드웨어 디바이스를 제어하는 것입니다.

예를 들어 Win32 시스템에서는ioctl콜은 USB 디바이스와 통신하거나 연결된 스토리지 디바이스의 드라이브 지오메트리 정보를 검색할 수 있습니다.

OpenBSD 및 NetBSD에서는ioctl에 의해 사용됩니다.bio(4)의사 디바이스 드라이버 및bioctlRAID 볼륨 관리를 벤더에 의존하지 않는 통합 인터페이스로 구현하기 위한 유틸리티는 다음과 같습니다.ifconfig를 클릭합니다.[1][2]

NetBSD에서는,ioctl에 의해서도 사용됩니다.sysmon를 [3]참조할 수 있습니다.

터미널

의 1회 사용ioctl최종 사용자 애플리케이션에 노출되는 코드는 터미널 I/O입니다.

Unix 운영체제는 전통적으로 명령줄 인터페이스를 많이 사용해 왔습니다.Unix 명령줄 인터페이스는 VT100 등의 하드웨어 텍스트 단말기를 에뮬레이트하는 의사 단말기(ptys) 상에 구축되어 있습니다.pty는 하드웨어 디바이스인 것처럼 제어 및 설정됩니다.ioctl예를 들어 pty의 윈도 사이즈는 pty를 사용하여 설정합니다.TIOCSWINSZ호출. TIOCSTI(단말 I/O 제어, 단말기 입력 시뮬레이션) ioctl 함수는 문자를 디바이스 [4]스트림에 푸시할 수 있습니다.

커널 확장

예를 들어 네트워크 처리를 가속화하기 위해 애플리케이션이 커널을 확장해야 하는 경우,ioctl콜을 사용하면 사용자 공간 코드를 커널 확장자에 브리지할 수 있습니다.커널 확장자는 파일 시스템에서 이름으로 열 수 있는 위치를 제공할 수 있으며, 이 위치를 통해 임의의 개수의 파일 시스템이ioctl콜을 디스패치 할 수 있기 때문에 시스템콜을 오퍼레이팅시스템에 추가하지 않고 내선번호를 프로그래밍 할 수 있습니다.

sysctl 대체물

OpenBSD 개발자에 따르면ioctl그리고.sysctl커널을 확장하기 위한 두 가지 시스템 호출입니다.sysctl아마도 [5]둘 중 더 단순할 것이다.

NetBSD에서는sysmon_envsys하드웨어 모니터링 사용을 위한 프레임워크ioctl통해.proplib대신 OpenBSD와 DragonFly BSD는sysctl그들의 통신에 대하여.hw.sensors를 참조할 수 있습니다.의 최초 개정판envsysnetBSD가 구현되었습니다.ioctl전에proplib이 프레임워크는 실험적인 것으로 대체되어야 한다는 메시지가 표시되었습니다.sysctl(8)개발되어야 하는 경우,[6][7] 이는 잠재적으로 선택 사항을 설명합니다.sysctl오픈B에서SD는, 그 후의 도입으로,hw.sensors2003년에.단, 이 경우envsys프레임워크는 2007년에 재설계되었습니다.proplib시스템 콜은 그대로입니다.ioctl메시지가 [8]삭제되었습니다.

실장

유닉스

그ioctl시스템 콜은 버전7 Unix에서 처음 등장하여 이름이 변경되었습니다.stty.[9] ANioctlcall takes as parameter:

  1. 오픈 파일 기술자
  2. 요청 코드 번호
  3. 데이터에 대한 입력되지 않은 포인터(드라이버로 이동하거나 드라이버에서 돌아오거나 둘 다)

일반적으로 커널은 다음 명령어를 디스패치합니다.ioctl디바이스 드라이버에 직접 콜합니다.디바이스 드라이버는, 요구 번호와 데이터를 필요한 방법으로 해석할 수 있습니다.각 드라이버의 라이터는, 그 특정의 드라이버의 번호를 요구해, 헤더 파일에 상수로 제공합니다.

Linux를 포함한 일부 Unix 시스템에는 디바이스 드라이버와의 사이에서 전송되는 데이터의 크기, 데이터 전송 방향 및 요청을 구현하는 드라이버의 ID를 요구 번호 내에서 인코딩하는 규칙이 있습니다.이러한 규칙을 따르는지 여부에 관계없이 커널과 드라이버는 (심볼 상수로 나타남) 균일한 에러 코드를 제공하기 위해 협력합니다.ENOTTY이를 인식하지 못하는 운전자에게 요청을 하는 응용 프로그램에 대한 정보입니다.

니모닉ENOTTY(전통적으로 "타자기 아님"이라는 텍스트 메시지와 관련지어짐)는 다음 시스템을 통합한 최초의 시스템에서 파생됩니다.ioctlteletype(teletype만)tty) 디바이스가 이 에러를 발생시켰습니다.심볼릭 니모닉은 호환성 요건에 의해 고정되지만 일부 최신 시스템은 "부적절한 디바이스 제어 조작"(또는 그 현지화)과 같은 보다 일반적인 메시지를 더 유용하게 렌더링합니다.

TCSETS의 예를 나타냅니다.ioctl시리얼 포트를 호출합니다.시리얼 포트상의 통상의 읽기 및 쓰기 콜은, 데이터 바이트를 송수신 합니다.안ioctl(fd,TCSETS,data)콜은, 이러한 통상의 I/O와는 별도로, 특수 문자 처리나 포토상의 출력 신호(DTR 신호등)등의 다양한 드라이버 옵션을 제어합니다.

Win32

A Win32DeviceIoControl파라미터로서 취득합니다.

  1. 오픈 오브젝트 핸들(파일 기술자와 동등한 Win32)
  2. 요청 코드 번호('제어 코드')
  3. 입력 파라미터의 버퍼
  4. 입력 버퍼 길이
  5. 출력 결과의 버퍼
  6. 출력 버퍼 길이
  7. 한 사람OVERLAPPED구조(중복 I/O가 사용되는 경우)

Win32 디바이스 제어 코드는 실행 중인 동작의 모드를 고려합니다.

디바이스 드라이버의 보안에 영향을 주는 4가지 동작 모드가 정의되어 있습니다.

  1. METHOD_IN_DIRECT: 사용자 모드 발신자가 버퍼 주소를 읽을 수 있는지 확인합니다.
  2. METHOD_OUT_DIRECT: 버퍼 주소가 사용자 모드 발신자에 의해 쓰기 가능한 것을 확인합니다.
  3. METHOD_NEITHER: 사용자 모드의 가상 주소는 매핑 또는 검증 없이 드라이버에 전달됩니다.
  4. METHOD_BUFFERED: IO Manager 제어 공유 버퍼는 사용자 모드 간에 데이터를 이동하기 위해 사용됩니다.

대체 수단

기타 벡터된 콜인터페이스

운영체제 개발자는 시스템콜인터페이스에 초점을 맞추고 효율적으로 유지하려고 하기 때문에 이 접근방식은 거의 채택되지 않지만 디바이스와 커널 확장을 새로운 시스템콜을 사용하여 사용자 공간에 링크할 수 있습니다.

UNIX 운영체제시스템에서는 다른 2개의 벡터된 콜인터페이스가 널리 사용되고 있습니다.fcntl('파일 제어') 시스템콜은 오픈파일을 설정하고 비블로킹 I/O를 활성화하는 등의 상황에서 사용됩니다.setsockopt("set socket option") 시스템콜은 오픈 네트워크 소켓을 설정합니다.오픈 네트워크 소켓은,ipfw패킷 방화벽을 설정합니다.

메모리 매핑

유닉스
디바이스 인터페이스와 입출력 기능은 메모리 매핑된 파일을 사용하여 제공되는 경우가 있습니다.디바이스와 상호작용하는 어플리케이션은 파일 시스템 상에서 디바이스와 대응하는 위치를 엽니다.이러한 로케이션은,ioctl메모리 매핑시스템 콜을 사용하여 주소 공간의 일부를 커널에 연결합니다.이 인터페이스는 디바이스와 사용자 공간 응용 프로그램 간에 벌크 데이터 전송을 제공하는 훨씬 효율적인 방법입니다.개별은ioctl또는 읽기/쓰기 시스템콜은, 유저 스페이스에서 스탭으로의 이행이 반복되기 때문에, 오버헤드가 발생합니다.이 경우, 메모리 부족 범위의 주소에의 액세스에는 오버헤드가 발생하지 않습니다.
Win32
버퍼링된 IO 메서드 또는 이름 있는 파일 매핑 개체를 사용할 수 있습니다.단, 단순한 디바이스 드라이버의 경우 표준 사양입니다.DeviceIoControl METHOD_액세스로 충분합니다.

네트워크 링크

Netlink는 Inter-Process Communication(IPC; 프로세스 간 통신)을 위한 소켓과 같은 메커니즘으로 보다 유연한 후계 제품으로 설계되었습니다.ioctl.

시사점

복잡성

ioctl콜은 커널의 시스템콜 인터페이스의 복잡성을 최소화합니다.그러나 개발자들이 커널 프로그래밍 인터페이스의 비트와 조각을 "스테이시"할 수 있는 장소를 제공함으로써,ioctl콜은 사용자-커널 API 전체를 복잡하게 만듭니다.수백 개의 시스템 콜을 제공하는 커널은 수천 개의 ioctl 콜을 제공할 수 있습니다.

의 인터페이스이지만,ioctl콜은 기존의 시스템콜과 다소 다른 것으로 보입니다만, 실제로는 다른 콜의 차이는 거의 없습니다.ioctl콜 및 시스템콜;ioctl콜은 단순히 디스패치 메커니즘이 다른 시스템콜입니다따라서 커널 시스템콜인터페이스 확장에 반대하는 대부분의 인수는ioctl인터페이스입니다.

응용 프로그램 개발자에게 시스템콜은 응용 프로그램서브루틴과 다를 바 없이 단순히 인수를 사용하여 값을 반환하는 함수콜입니다OS 의 런타임 라이브러리는, 시스템 콜의 호출에 수반하는 복잡함을 은폐합니다.유감스럽게도 런타임 라이브러리는ioctl투과적인 콜입니다.머신의 IP 주소의 검출과 같은 간단한 조작에는, 복잡한 작업이 필요하게 되는 경우가 많습니다.ioctl각 콜에는 매직 번호와 인수 [citation needed]구조가 필요합니다.

Libpcap과 libdnet은 서드파티제의 래퍼 Unix 라이브러리의 두 가지 예입니다.ioctl패킷 캡처용 인터페이스와 패킷 I/O용 인터페이스입니다.

보안.

메인스트림 운영 체제의 사용자 간 인터페이스는 출시 전에 코드 결함 및 보안 취약성에 대해 많은 감사를 받습니다.이러한 감사는 일반적으로 잘 문서화되어 있는 시스템콜인터페이스에 초점을 맞춥니다.예를 들어 감사자는 사용자 ID 변경 등의 중요한 보안 콜을 관리 사용자만 사용할 수 있도록 하는 경우가 있습니다.

ioctl인터페이스는 시스템콜보다 복잡하고 다양하기 때문에 감사하기가 어렵습니다.게다가ioctl대부분의 경우 핵심 운영 체제가 출시된 후에 서드파티 개발자가 콜을 제공할 수 있습니다.ioctl콜의 실장에서는, 정밀도가 낮아지기 때문에, 취약성이 높아지는 일이 있습니다.마지막으로 많은 분들이ioctl특히 서드파티제 디바이스 드라이버의 콜은 문서화되어 있지 않습니다.

그 이유는, 의 핸들러이기 때문입니다.ioctl콜은 커널 모드로 직접 존재하므로 사용자 공간으로부터의 입력은 신중하게 검증해야 합니다.디바이스 드라이버의 취약성은 로컬 사용자에 의해 유효하지 않은 버퍼를 전달함으로써 부정 이용될 수 있습니다.ioctl콜을 클릭합니다.

Win32 및 Unix 운영체제는 특정 접근컨트롤이 적용된 어플리케이션에 의한 사용자 공간 디바이스 이름 접근을 보호할 수 있습니다.디바이스 드라이버 개발자가 사용자 공간 액세스 가능 개체에 적절한 액세스 제어를 적용하지 않을 경우 보안 문제가 발생할 수 있습니다.

일부 최신 운영 체제시스템은 시스템콜 래퍼를 사용하여 적대적인 사용자 공간 코드(버퍼 오버플로우 악용에 의해 감염된 응용 프로그램 등)로부터 커널을 보호합니다.시스템 콜 래퍼는 어떤 응용 프로그램에 의해 호출될 수 있는 시스템콜을 지정함으로써 역할 기반 접근컨트롤을 구현합니다.예를 들어 래퍼를 사용하여 메일프로그램의 권한을 "취소"하여 다른 프로그램을 생성할 수 있습니다. ioctl인터페이스에는 다수의 시스템콜 래퍼가 있어 복잡합니다.각각 다른 인수를 사용합니다.이 중 일부는 일반 프로그램에서 필요할 수 있습니다.

추가 정보

  • W. Richard Stevens, UNIX 환경의 Advanced Programming (Addison-Wesley, 1992), ISBN0-201-56317-7) 섹션 3.14.
  • GNU C 라이브러리용 온라인 매뉴얼의 일반 I/O Control 조작
  • ioctl(2) – 버전 7 Unix 프로그래머 매뉴얼
  • ioctl(2) – Linux 프로그래머 매뉴얼– 시스템 콜
  • ioctl(2) – FreeBSD 시스템 콜 매뉴얼
  • ioctl(2) – OpenBSD 시스템 콜 매뉴얼
  • ioctl(2) – Solaris 10 시스템콜 레퍼런스 매뉴얼
  • "Microsoft Developer Network의 DeviceIoControl 문서

레퍼런스

  1. ^ Niklas Hallqvist (2002); Marco Peereboom (2006). "bio(4) — block I/O ioctl tunnel pseudo-device". BSD Cross Reference. OpenBSD.
  2. ^ Marco Peereboom (2005). "bioctl(8) — RAID management interface". BSD Cross Reference. OpenBSD.
  3. ^ "sysmon(4) — system monitoring and power management interface". NetBSD. An ioctl(2) interface available via /dev/sysmon.
  4. ^ Christiansen, Tom; Torkington, Nathan (1998). "12: Packages, Libraries, and Modules". Perl Cookbook: Solutions & Examples for Perl Programmers (2 ed.). Sebastopol, California: O'Reilly Media, Inc. (published 2003). p. 482. ISBN 9780596554965. Retrieved 2016-11-15. [...] TIOCSTI [...] stands for 'terminal I/O control, simulate terminal input.' On systems that implement this function, it will push one character into your device stream so that the next time any process reads from that device, it gets the character you put there.
  5. ^ Federico Biancuzzi (2004-10-28). "OpenBSD 3.6 Live". ONLamp. O'Reilly Media. Archived from the original on 2004-10-29. Retrieved 2019-03-20. There are two system calls that can be used to add functionality to the kernel (without adding yet another system call): ioctl(2) and sysctl(3). The latter was chosen because it was very simple to implement the new feature.
  6. ^ Tim Rightnour; Bill Squier (2007-12-19). "envsys -- Environmental Systems API". NetBSD 4.0. This API is experimental and may be deprecated at any time ... This entire API should be replaced by a sysctl(8) interface or a kernel events mechanism, should one be developed.
  7. ^ Constantine A. Murenin (2007-04-17). "3.5. NetBSD's sysmon(4)". Generalised Interfacing with Microprocessor System Hardware Monitors. Proceedings of 2007 IEEE International Conference on Networking, Sensing and Control, 15–17 April 2007. London, United Kingdom: IEEE. pp. 901–906. doi:10.1109/ICNSC.2007.372901. ISBN 978-1-4244-1076-7. IEEE ICNSC 2007, pp. 901—906.
  8. ^ Constantine A. Murenin (2010-05-21). "6.1. Framework timeline; 7.1. NetBSD envsys / sysmon". OpenBSD Hardware Sensors — Environmental Monitoring and Fan Control (MMath thesis). University of Waterloo: UWSpace. hdl:10012/5234. Document ID: ab71498b6b1a60ff817b29d56997a418.
  9. ^ McIlroy, M. D. (1987). A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986 (PDF) (Technical report). CSTR. Bell Labs. 139.