Этот пост подготовлен по материалам выступления Константина Игнатова, Qrator Labs, на партнёрской конференции «1С-Битрикс».

Допустим, на ваш сайт началась DDoS-атака. Как вы об этом узнаете? Как ваша система безопасности определяет, что вы подверглись нападению? Каковы способы защиты? Какая последовательность действий и событий должна произойти в случае атаки?

Как правило, владелец ресурса узнает об атаке только в тот момент, когда ему начинают звонить недовольные пользователи. Эту ситуацию большинство компаний встречают неподготовленными. В момент пожара разрабатывать план спасения поздно, и все бросаются на поиски универсального средства, которое окажется под рукой. Но «волшебной пилюли» против DDoS, которая мгновенно бы устранила проблему, нет. Готовиться необходимо заранее.

Научная статья опубликована в журнале Communications of the ACM, октябрь 2018, том 61, номер 10, стр. 68−77, doi: 10.1145/3230627

В феврале 2017 года со взлётной площадки «Боинга» в Аризоне поднялся вертолёт с обычным заданием: облёт ближайших холмов. Он летел полностью автономно. Согласно требованиям по технике безопасности Федерального управления авиации США, пилот не прикасался к органам управления. Это был не первый автономный полёт AH-6, которого в компании называют Беспилотной Птичкой (Unmanned Little Bird, ULB). Он так летает уже много лет. Однако на этот раз посреди полёта вертолёт подвергся кибератаке. Бортовой компьютер атаковало вредоносное программное обеспечение видеокамеры, а также вирус, доставленный через заражённую флэшку, которую вставили во время техобслуживания. Атака поставила под угрозу некоторые подсистемы, но не смогла повлиять на безопасную эксплуатацию воздушного судна.

Опять вернёмся в традиционную область разработки операционных систем (и приложений для микроконтроллеров) — написание драйверов.

Я попробую выделить некоторые общие правила и каноны в этой области. Как всегда — на примере Фантома.

Драйвер — функциональная компонента ОС, ответственная за отношения с определённым подмножеством аппаратуры компьютера.

С лёгкой руки того же Юникса драйвера делятся на блочные и байт-ориентированные. В былые времена классическими примерами были драйвер диска (операции — записать и прочитать сектор диска) и драйвер дисплея (прочитать и записать символ).

В современной реальности, конечно, всё сложнее. Драйвер — типичный инстанс-объект класса, и классов этих до фига и больше. В принципе, интерфейс драйверов пытаются как-то ужать в прокрустово ложе модели read/write, но это самообман. У драйвера сетевой карты есть метод «прочитать MAC-адрес карты» (который, конечно, можно реализовать через properties), а у драйвера USB — целая пачка USB-специфичных операций. Ещё веселее у графических драйверов — какой-нибудь bitblt( startx, starty, destx, desty, xsize, ysize, operation ) — обычное дело.

Цикл жизни драйвера, в целом, может быть описан так:

• Инициализация: драйвер получает ресурсы (но не доступ к своей аппаратуре)
• Поиск аппаратуры: драйвер получает от ядра или находит сам свои аппаратные ресурсы
• Активация — драйвер начинает работу
• Появление/пропадание устройств, если это уместно. См. тот же USB.
• Засыпание/просыпание аппаратуры, если это уместно. В контроллерах часто неиспользуемая аппаратура выключается для экономии.
• Деактивация драйвера — обслуживание запросов прекращается
• Выгрузка драйвера — освобождаются все ресурсы ядра, драйвер не существует.

(Вообще я написал в прошлом году черновик открытой спецификации интерфейса драйвера — см. репозиторий и документ.)

Мне известны три модели построения драйвера:

• Поллинг
• Прерывания
• Нити (threads)

Здравствуйте, хаброчитатели!

Введение

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



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

К сожалению, я не могу прикрепить исходный код драйвера, но мы рассмотрим все проблемы, с которыми я и вы можете столкнуться в процессе переноса. Далее будет рассмотрен пример переноса простого драйвера c версии ядра 2.6.25 на 4.12.5, который расположен в drivers/serial/name_uart.c. Также нам очень поможет следующий ресурс 2.6.25 и 4.12.5, где можно посмотреть структуру ядра, а также исходные коды.