Разработка системы автоматизированного тестирования UEFI-драйверов с пользовательским интерфейсом

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Разработка системы автоматизированного тестирования UEFI-драйверов с пользовательским интерфейсом

Александра Артамонова

Московский государственный технический университет имени Н.Э. Баумана, Москва, Россия,

Андрей В. Куров

Московский государственный технический университет имени Н.Э. Баумана, Москва, Россия

Аннотация

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

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

Ключевые слова: UEFI, UEFI-приложение, автоматизированное тестирование

Abstract

Development of an automated testing system for the user interface UEFI drivers

Aleksandra A. Artamonova

Bauman Moscow State Technical University, Moscow, Russia,

Andrei V. Kurov

Bauman Moscow State Technical University, Moscow, Russia,

Software testing is one of the most critical stages of development that is necessary to ensure the quality of the final product. Automated testing tools can significantly simplify and speed up the development process. But in low-level context such as UEFI-BIOS drivers and applications development, automated testing systems are not widely used. That is mainly due to the fact that the software runtime and the developer's workstation are different, as well as to the lack of ready-made universal solutions. The paper presents the hardware and software implementation of a universal system for automated tests of UEFI drivers with a user interface, which allows to perform functional testing of the developed software directly on the target hardware platform. The main idea of the proposed method is to create an UEFI application that replaces the standard input and output consoles by custom ones before running the test driver. Those custom consoles copy the complete functionality of standard consoles and also provide duplication of information between the target motherboard and the associated additional device. Using the system will allow testing in an environment that is sufficiently isolated from the software runtime environment. In addition, the software implementation of the system does not depend on the driver under test that ensures its versatility. The offered method is applicable for testing the user interface UEFI drivers that use input and output consoles and allow checking those drivers for errors by analyzing the state of the consoles.

Keywords: UEFI, UEFI-application, automated testing

Введение

Тестирование программного обеспечения представляет собой один из самых критически важных этапов разработки и является необходимым для обеспечения качества конечного продукта. В течение многих лет по мере хода развития программной сферы и эволюции цикла разработки предлагались различные методики тестирования и создавались разнообразные инструменты, автоматизирующие те или иные фазы тестирования. Такие инструменты позволяют существенно ускорить и упростить процесс разработки, так как избавляют от необходимости проводить рутинную работу, обеспечивают воспроизводимость сценариев тестирования и не имеют риска допустить случайные ошибки. Однако при создании низкоуровневых систем, например при разработке драйверов устройств и приложений, работающих под UEFI-BIOS, системы автоматизированного тестирования используются достаточно редко [Gomes 2016]. Основной причиной можно назвать несоответствие среды, в которой должен выполняться код, и платформы, используемой при его разработке. Хотя многие компоненты низкоуровневых программных систем зачастую однозначно определяются спецификацией используемых протоколов, что может существенно снизить сложность проектирования, проведение тестирования все еще остается необходимым процессом для своевременного выявления ошибок и обеспечения корректной работы системы. Кроме того, функциональность низкоуровневых систем нередко отличается в зависимости от используемого аппаратного оборудования, что заставляет проводить один и тот же набор тестовых сценариев на разных платформах. Отсюда вытекает актуальность создания автоматизированной системы для проведения функциональных тестов на целевом оборудовании.

Можно выделить два основных подхода к проведению автоматического тестирования UEFI-приложений и драйверов [Gomes 2016]: создание тестового приложения, которое будет выполняться на целевой аппаратной платформе для непосредственной проверки функционала системы, или разработка утилиты, которая будет имитировать базовые функции UEFI-среды, что позволит проводить тестирование на платформе, отличной от целевой. Хотя второй подход предполагает меньшее время проведения тестирования, обеспечивая при этом проверку логической корректности функционала, в данной работе отдается предпочтение первому варианту, так как только выполнение полноценных сценариев тестирования непосредственно на целевом оборудовании может с удовлетворительной точностью гарантировать работу разрабатываемого программного обеспечения на этой аппаратной платформе при реальной эксплуатации.

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

Основная идея предлагаемого метода заключается в разработке UEFI-приложения, заменяющего перед запуском тестируемого UEFI-драйвера стандартные консоли ввода и вывода в глобальной системной таблице (global System Table, gST) на пользовательские, которые сохраняют функционал стандартных консолей в полном объеме и в дополнение к этому обеспечивают дублирование информации между целевой материнской платой и связанным с ним вспомогательным устройством. Таким образом, вся информация, отправляемая тестируемым драйвером на стандартную консоль ввода, будет приниматься этим устройством, а посылаемые с устройства данные будут обрабатываться драйвером так, как будто бы они были введены непосредственно с клавиатуры, подключенной к целевой материнской плате. Понятно, что такая система подходит только для тестирования UEFI-драйверов с пользовательским интерфейсом, т. е. использующих консоли ввода и вывода и позволяющих оценить свою работоспособность по анализу их состояния, и не будет пригодна для проверки функциональности программного обеспечения другого типа (например, драйверов устройств).

Аппаратная реализация системы

Основными аппаратными компонентами системы являются: материнская плата, на которой проводится запуск тестируемого программного обеспечения, плата преобразователя интерфейса USB-UART и плата с USB-входом, на которой будет происходить получение информации о текущем состоянии консоли вывода целевой материнской платы и отправка сценариев тестирования.

В данной работе для реализации аппаратной составляющей системы были использованы: материнская плата отечественного производителя AQH310CM, одноплатный компьютер Raspberry Pi 3 Model B v1.2 и плата расширения ARPI600 для подключения к Raspberry Pi. Выбор этих компонентов осуществлялся из соображений доступности - они могут быть заменены на аналогичные с минимальными изменениями программного кода разрабатываемого UEFI-приложения. ARPI600 подключается к материнской плате посредством кабеля USB - microUSB, а к Raspberry Pi - посредством GPIO-интерфейса. На ARPI600 устанавливаются перемычки P_RX и CP_TX, P_TX и CP_RX соответственно для подключения USB-UART к последовательному порту Raspberry Pi (рис. 1).

Рис. 1. Установка перемычек на ARPI600 [Waveshare n.d.]

Перед началом работы на SD-карту, используемую в Raspberry Pi, устанавливается операционная система Raspbian Raspbian [Электронный ресурс]. (дата обращения 14 января 2020)., производится ее необходимая конфигурация и устанавливаются требуемые драйвера в соответствии с руководством пользователя ARPI600 [Waveshare n.d.].

Программная реализация системы

Программный код UEFI-BIoS является модульным и состоит из различных пакетов, включающих в себя набор модулей и связанных с ними определений [Tianocore 2018], [Kedlaya 2014]. Такая структура удобна для восприятия и облегчает повторное использование кода. Каждый пакет может включать в себя следующие корневые каталоги: Include, Library, Application, Drivers. Каталог Include содержит все заголовочные файлы, предоставляемые этим пакетом, которые могут быть использованы в других проектах. Каталог Library включает в себя каталоги каждой из библиотек модуля. В каталоге Application находятся, соответственно, каталоги для каждого UEFI-приложения в составе пакета, и, наконец, каталог Drivers содержит каталоги для каждого UEFI-драйвера в составе пакета.

UEFI-приложение представляет собой бинарный файл, который может быть загружен для выполнения определенной задачи и выгружен по завершении выполнения этой задачи [Tianocore n.d.].

В данном случае UEFI-приложение после запуска будет заменять стандартные консоли ввода и вывода в глобальной системной таблице, обеспечивая дублирование информации между вспомогательным устройством и средой выполнения приложения, загружать тестируемый драйвер и выгружать его после завершения тестирования. Файл исходного кода ConsoleSwapperApp.c написан на языке С; он содержит основную точку входа в приложение и вызов необходимых функций для его работы. Информационный файл ConsoleSwapperApp.inf используется инструментами сборки для получения информации о пакете [Tianocore 2019].

Библиотеки ConInAdapterLib, ConOutAdapterLib, IoLib и UsbIo DevLib предоставляют, соответственно, функционал для работы с экземплярами пользовательской консолью ввода и вывода, экземпляром устройства ввода-вывода и экземпляром устройства USB. Схема работы приложения представлена на рис. 3 и рис. 4.

Рис. 2. Схема работы приложения ConsoleSwapperApp. Часть

Рис. 3. Схема работы приложения ConsoleSwapperApp. Часть 2

Поиск USB-устройства осуществляется по идентификатору производителя (Vendor Identifier, VID) и идентификатору продукта (Product Identifier, PID). В зависимости от выбранных аппаратных компонентов системы автоматизированного тестирования может потребоваться произвести конфигурацию найденного USB-устройства. Конфигурация ARPI600 включает в себя отправку команды активации интерфейса CP2102 в соответствии со спецификацией установленного на нем чипсета CP2010 [Silicon Labs 2010] путем вызова функции UsbControlTransfer() с необходимыми параметрами.

Если USB-устройство было успешно найдено и сконфигурировано, приложение может продолжить свою работу, создав экземпляр устройства ввода-вывода IoDev. Для IoDev определены две функции - чтения и записи. Для работы с единственным поддерживаемым USB-устройством реализация чтения и записи заключается в вызове функции UsbBulkTransferQ с необходимыми параметрами. Такая структура упрощает добавление при необходимости поддержки других физических интерфейсов (например, COM-порта).

ConInAdapter является реализацией пользовательской консоли ввода, основанной на EFI_SIMPLE_TEXT_INPUT_PROTOCOL, а ConOutAdapter, соответственно, реализацией пользовательской консоли вывода, основанной на EFI_SIMPLE_TEXT_OUTPUT_ PRoToCoL.

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

Пользовательская реализация функций ConOutAdapter главным образом относится к переводу сообщений, выводимых на консоль тестируемым программным обеспечением, в управляющие последовательности ANSI в соответствии со спецификацией UEFI 2.7 [Unified Extensible Firmware 2017] и отправке их на вспомогательное устройство посредством вызова функции записи созданного экземпляра IoDev, а пользовательская реализация функций ConInAdapter касается чтения управляющих последовательностей в том же формате из буфера, связанного со вспомогательным устройством посредством вызова функции чтения экземпляра IoDev, переводе их в соответствующие скан-коды и символы клавиш и отправки их на стандартную консоль ввода для имитации нажатия клавиш пользователем.

Файл образа UEFI-драйвера должен располагаться на доступном носителе, например на USB-накопителе или подключенном жестком диске, после чего он может быть загружен в системную память при помощи службы загрузки LoadImage() и запущен c использованием службы загрузки StartImage() [Wei- min 2008]. Таким образом, после замены консолей в системной таблице UEFI-приложение может выполнить попытку поиска драйвера на доступных накопителях, в случае успеха загрузить и запустить его, а после завершения работы драйвера осуществить его выгрузку из памяти и освободить остальную выделенную память.

Опытная проверка

Для проверки системы автоматизированного тестирования был подготовлен простой UEFI-драйвер, который после загрузки и запуска выводит на стандартную консоль вывода сообщение “Hello”, после чего переходит в режим ожидания нажатия клавиши. При нажатии клавиши Enter драйвер очищает стандартную консоль вывода, отправляет на нее сообщение “World”, ждет 5 секунд и завершает свою работу; нажатие остальных клавиш игнорируется. Тестовый драйвер с расширением.efi был помещен на USB-накопитель, подключенный к тестируемой материнской плате AQH310CM, после чего на ней было запущено приложение ConsoleSwapperApp.efi, программная реализация которого была описана ранее.

Кроме того, было создано небольшое приложение на языке Python, запускаемого на Raspberry Pi. При помощи библиотеки pyserial PyPi: Pyserial Project [Электронный ресурс] // Python Software Foundation. (дата обращения 14 января 2020). оно определяет наличие устройства по адресу /dev/ ttyAMAO, которым является ARPI600, отправляет заранее заготовленное сообщение, содержащее инструкцию нажатия клавиши Enter в виде управляющей последовательности ANSI на это устройство, а затем читает данные, выведенные драйвером после обработки полученной команды на стандартную консоль и отправленные на ARPI600. Эта информация сравнивается с также заранее подготовленным «эталонным» состоянием консоли. Если в ответе содержится сообщение “World”, можно сделать вывод о том, что тестируемый драйвер работает корректно, в обратном же случае можно заключить, что его функциональность нарушена. Результат сравнения выводится на экран (“oK” или “ERRoR”).

Результат проверки системы автоматизированного тестирования оказался успешным. Приложение на языке Python отправило на материнскую плату с загруженным тестовым драйвером и запущенным приложением ConsoleSwapperApp команду нажатия клавиши Enter, убедилось в выводе на стандартную консоль сообщения “World” и вывело на экран результат проверки (“oK”).

Заключение

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

Использование системы позволит проводить тестирование в среде, достаточно изолированной от среды выполнения программного обеспечения. Кроме того, программная реализация системы не зависит от тестируемого драйвера, что обеспечивает ее универсальность. Однако она подходит только для испытания UEFI-драйверов с пользовательским интерфейсом, позволяющих оценить их работоспособность по анализу состояния консолей ввода-вывода, и не будет пригодна для проверки функциональности программного обеспечения другого типа (например, драйверов устройств).

Литература

1. Gomes, Amora, Teixeira, Lima, Brito, Ciocari, Machado 2016 - Gomes E.C., Amora P.R., Teixeira E.M., Lima A.G., Brito F.T., Ciocari J.F, Machado J.C. UTTOS: A Tool for Testing UEFI Code in OS Environment // 28^th International Conference on Testing Software and Systems (ICTSS-2016), 17-19 October, 2016. Graz, 2016. P. 218-224.

2. Kedlaya, Bhagyalakshmi 2014 - Kedlaya G., Bhagyalakshmi H.R. Design and Implementation of GPIO Enumeration Library and Application for UEFI-BIOS // International Journal of Scientific Engineering and Technology. 2014. Vol. 3, no. 5. P. 524-528.

3. Silicon Labs 2010 - Silicon Labs, AN571: CP210x Virtual COM Port Interface [Электронный ресурс]. (дата обращения 14 января 2020).

4. Tianocore n.d. - Tianocore, Creating a Shell Application [Электронный ресурс] // GitHub, Inc. (дата обращения 14 января 2020).

5. Tianocore 2018 - Tianocore, EDK II Driver Writer's Guide for UEFI 2.3.1 [Электронный ресурс]. (дата обращения 14 января 2020).

6. Tianocore 2019 - Tianocore, EDK II Module Information (INF) File Specification [Электронный ресурс]. (дата обращения 14 января 2020).

7. Unified Extensible Firmware 2017 - Unified Extensible Firmware Interface Specification Version 2.7. [Электронный ресурс]. (дата обращения 14 января 2020).

8. Waveshare n.d. - Waveshare, ARPI600 User Manual [Электронный ресурс]. (дата обращения 14 января 2020).

9. Wei-min, Peng, Han 2008 - Wei-min T., Peng S., Han Z. Design and implementation of UsbKey device driver based on Extensible Firmware Interface // 9^th International Conference on Signal Processing, Beijing, 26-29 October 2008. Beijing, 2008. P. 2833-2836.

References

1. Gomes, E.C., Amora, P.R., Teixeira, E.M., Lima, A.G., Brito, F.T., Ciocari, J.F. and Machado, J.C. (2016), “UTTOS: A Tool for Testing UEFI Code in OS Environment”, 28^th International Conference on Testing Software and Systems (ICTSS-2016), 17-19 October 2016, Graz, Austria, pp. 218-224.

2. Kedlaya, G. and Bhagyalakshmi, H.R. (2014), “Design and Implementation of GPIO Enumeration Library and Application for UEFI-BIOS”, International Journal of Scientific Engineering and Technology, vol. 3, no. 5, pp. 524-528.

3. Silicon Labs, AN571: CP210x Virtual COM Port Interface (2010), [Online], available at: (Accessed 14 Jan 2020).

4. Tianocore, Creating a Shell Application, GitHub, Inc. [Online], (Accessed 14 Jan 2020).

5. Tianocore, EDK II Driver Writer's Guide for UEFI 2.3.1 (2018), [Online], available at: (Accessed 14 Jan 2020).

6. Tianocore, EDK II Module Information (INF) File Specification (2019), [Online], available at: (Accessed 14 Jan 2020).

7. Unified Extensible Firmware Interface Specification Version 2.7 (2017 EFI_Spec_2_7.pdf (Accessed 14 Jan 2020).

8. Waveshare, ARPI600 User Manual (n.d.), [ (Accessed 14 Jan 2020).

9. Wei-min, T., Peng, S. and Han, Z. (2008), “Design and implementation of UsbKey device driver based on Extensible Firmware Interface”, 2008 9^th International Conference on Signal Processing, 26-29 October 2008, Beijing, China, pp. 28332836.

Размещено на Allbest.ru