Предлагаем заблокировать драйверы, которые предоставляют доступ к GPL-вызовам ядра Linux

Логотип ядра Linux, Tux

Кристоф Хеллвиг, известный разработчик ядра Linux, который когда-то был членом технического руководящего комитета Linux Foundation и подал иск в рамках судебного процесса GPL против VMware.

Он предложил ужесточить защиту против связывания проприетарные драйверы к экспортированным компонентам ядра Linux только для модулей под лицензией GPL.

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

Чтобы заблокировать такой маневр, Кристоф Хельвиг подготовил патчи для ядра Linux, обеспечивающие наследование флагов, связанных с экспортом символов GPL.

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

Предложение сводится к наследованию индикатора TAINT_PROPRIETARY_MODULE во всех модулях, которые импортируют символы модулей с этим флагом.

Следовательно, если модуль среднего уровня GPL пытается импортировать символы из модуля без GPL, модуль GPL унаследует тег TAINT_PROPRIETARY_MODULE и не сможет получить доступ к компонентам ядра, доступным только для модулей с лицензией GPL, даже если модуль ранее был импортирован символы от "gplonly".

Патч Hellwig теперь пытается усложнить эту задачу. Модули, которые импортируют проприетарные символы, помечаются как проприетарные и не имеют доступа к символам GPL. 

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

Это позволит избежать метода, первоначально запланированного Джонатаном Лемоном. для ваших патчей и заставит разработку промежуточных слоев опустить символ GPL быть намного сложнее, даже если есть небольшой зазор, как указано.

В настоящее время они обсуждают также различные разработчики ядра Linux была предложена обратная блокировка: если модуль импортирует символы EXPORT_SYMBOL_GPL, символы, экспортируемые этим модулем, не должны импортироваться модулями, которые явно не заявляют о совместимости с GPL.

Те, у кого нет модуля, импортируют символы EXPORT_SYMBOL_GPL, все их экспортированные символы должны обрабатываться как EXPORT_SYMBOL_GPL.

Кристоф Хельвиг написал, что согласен на 100% с этим предложением, но Линус Торвальдс не пропустит это изменение, поскольку оно сделает большую часть подсистем ядра недоступной для проприетарных драйверов из-за того, что при разработке драйверов базовые символы экспортируются под лицензией GPL.

Разработчиков не удовлетворила доступность реализации только для проприетарных драйверов NVIDIA через уровень GPL, предоставляемый этими драйверами.

В ответ на критику, автор патча указал, что подсистема не связана с NVIDIA и его поддержка может быть предоставлена, среди прочего, для программных интерфейсов для графических процессоров AMD и Intel.

В результате продвижение netgpu в ядре было сочтено невозможным до появления рабочей поддержки на основе бесплатных драйверов, таких как AMDGPU, Intel i915 или Nouveau.

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

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

источник: https://lkml.org/


Оставьте свой комментарий

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

*

*

  1. Ответственный за данные: AB Internet Networks 2008 SL
  2. Назначение данных: контроль спама, управление комментариями.
  3. Легитимация: ваше согласие
  4. Передача данных: данные не будут переданы третьим лицам, кроме как по закону.
  5. Хранение данных: база данных, размещенная в Occentus Networks (ЕС)
  6. Права: в любое время вы можете ограничить, восстановить и удалить свою информацию.

  1.   Давид сказал

    Может, лучше будет написать статью на английском, а не пользоваться переводчиком. Есть много частей, которые мне непонятны.