Опасно ли давать возможность создавать и устанавливать новое ядро и драйвер Linux при перезагрузке?

Question

Обычной практикой является добавление драйверов ядра Linux (объектов объектов ядра) в исходный код, а также сборка и установка их на целевой компьютер. Например, драйверы дисплея NVIDIA и гостевые надстройки Oracle VirtualBox устанавливаются таким образом. Также часто получают новые версии ядра (с соответствующими заголовками) через обновление системы. Это требует перестройки и переустановки KO, иначе устройство перестанет работать после обновления.

В нашем скрипте запуска установки продукта мы хотим добавить шаг, чтобы сделать и установить KO при каждой загрузке. Пользователь может отказаться, и ему придется собирать и устанавливать KO вручную. Драйвер устройства связывается с устройством USB.

Уместные детали:

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

2. Пересборка драйвера занимает около двух секунд, а пропускает сборку во время обычной загрузки (не после обновления ядра), а за миллисекунды.

3. В маловероятном случае сбоя сборки она не должна приводить к сбою системы или ее нестабильной работе. Однако наше аппаратное устройство не будет работать.

4. Некоторые дистрибутивы могут позволять регистрировать хуки, выполнять действия с определенными событиями, например, обновление ядра. Тем не менее, мы пытаемся реализовать то, что будет работать в большинстве дистрибутивов единообразным способом. Наш установщик это скрипт +tar или скрипт +rpm. К сожалению, для этого выпуска у нас нет пропускной способности для подготовки собственных пакетов для всех дистрибутивов (например, в стиле Debian).

Вопросы:

1. Это приемлемое решение? Если нет, то почему?

2. Каковы потенциальные риски, связанные с этим подходом?

3. Какое правильное / предпочтительное место для запуска сделать во время запуска? rc.local или скрипт под init.d или другой? Цель состоит в том, чтобы заставить его работать на большинстве дистрибутивов, используя один и тот же метод (если это вообще возможно).

Answer 1

Этот правильный ответ был предоставлен Rosco вчера на ServerFault.

1. Да, но вы должны добавить четкое руководство, описывающее, как мы можем запустить ваш скрипт вручную, чтобы мы могли убедиться, что скрипт будет возвращаться нормально. В случае VirtualBox в CentOS они добавляют скрипт в /etc/init.d с именем vboxdrv:

   /etc/init.d/vboxdrv {start|stop|stop_vms|restart|force-reload|status|setup}
   

   Это понятно; мы можем запустить / остановить скрипт и получить его состояние, поэтому риск возникновения проблем во время перезагрузки минимален, поскольку мы можем проверить скрипт на новом ядре перед его развертыванием. Вы не можете иметь больше стандартов, чем это, для меня это идеально.

2. Систематический сбой процесса компиляции и модуль недоступен. Это трагично? Я так не думаю. Пока ваш скрипт не зависает на машине и вы ведете полный журнал неудачи компиляции в / var / log / mymodule, вы не можете сделать это лучше.

3. См. 1. - в CentOS / RHEL / Fedora) vboxdrv запускается из /etc/init.d/vboxdrv и проверяет имя дистрибутива, а затем создает соответствующие сценарии. /etc/init.d - это первое место, которое я проверяю, когда мне нужна дополнительная информация о демоне. Со мной все в порядке.