Suicide
04.08.2020, 20:14
Кристоф Хелвиг (Christoph Hellwig), известный разработчик ядра Linux, в своё время входивший в управляющий технический комитет организации Linux Foundation и выступавший истцом в связанном с GPL судебном разбирательстве (https://www.opennet.ru/opennews/art.shtml?num=50445) с VMware, предложил (https://lkml.org/lkml/2020/7/30/58) ужесточить защиту от связывания проприетарных драйверов с компонентами ядра Linux, экспортируемыми только для модулей под лицензией GPL. Для обхода ограничения на экспорт GPL-символов производители проприетарных драйверов используют модуль-прослойку, код которой открыт и распространяется под лицензией GPLv2, но функции сводятся к трансляции доступа проприетарного драйвера к необходимым API ядра, запрещённым для использования из проприетарного кода напрямую.
Для блокирования подобного манёвра Кристоф Хелвиг подготовил (https://lkml.org/lkml/2020/7/30/61) для ядра Linux патчи, обеспечивающие наследование флагов, связанных с экспортом GPL-символов. Предложение сводится к наследованию флага TAINT_PROPRIETARY_MODULE во всех модулях, импортирующих символы из модулей с данным флагом. Таким образом, если GPL модуль-прослойка попытается импортировать символы из не-GPL модуля, то GPL-модуль унаследует метку TAINT_PROPRIETARY_MODULE и не сможет обращаться к компонентам ядра, доступным только для модулей под лицензией GPL, даже если модуль ранее импортировал символы из категории "gplonly".
При обсуждении также было высказано (https://lkml.org/lkml/2020/7/31/902) предложение по обратной блокировке - если модуль импортирует символы EXPORT_SYMBOL_GPL, любые экспортируемые данным модулем символы не должны импортироваться модулями, явно не заявляющими о совместимости с GPL. Т.е. если модуль импортирует символы EXPORT_SYMBOL_GPL, то все его экспортируемые символы должны обрабатываться как EXPORT_SYMBOL_GPL. Кристоф Хелвиг написал (https://lkml.org/lkml/2020/8/1/35), что на 100% согласен с данным предложением, но такое изменение не пропустит Линус Торвальдс, так как оно приведёт к недоступности для проприетарных драйверов большей части подсистем ядра, из-за того, что при разработке драйверов подключаются базовые символы, экспортируемые под GPL.
Изменение предложено в ответ на публикацию (https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E32664C7569@fb.com/T/#m3e84063e82ba14b758873d6cdde6d342157c586c) инженером из Facebook серии патчей с реализацией новой подсистемы netgpu, позволяющей организовать прямой обмен данными (DMA zero-copy) между сетевой картой и GPU, при этом выполняя обработку протокола силами CPU. Недовольство (https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E32664C7569@fb.com/T/#m556b6b762195afbbaf2782ba9be96ef9cf5e2e5c) разработчиков вызвала доступность (https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E32664C7569@fb.com/T/#md514322fdfa212afe9f1d3eb4e5f7eaefece36eb) реализации только для проприетарных драйверов NVIDIA через предоставляемую данными драйверами GPL-прослойку. В ответ на критику (https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E32664C7569@fb.com/T/#m3a5cab5ac3b0d386718bf62bd27b51510675dce0) автор патчей указал (https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E32664C7569@fb.com/T/#m758386d335ee7b4e332c44675ff68be29c79ec88), что подсистема не привязана к NVIDIA и её поддержка может быть обеспечена в том числе для программных интерфейсов к GPU AMD и Intel. В итоге продвижение netgpu в ядро было признано невозможным до появления рабочей поддержки на основе свободных драйверов, таких как AMDGPU, Intel i915 или Nouveau.
04.08.2020
https://www.opennet.ru/opennews/art.shtml?num=53485
Для блокирования подобного манёвра Кристоф Хелвиг подготовил (https://lkml.org/lkml/2020/7/30/61) для ядра Linux патчи, обеспечивающие наследование флагов, связанных с экспортом GPL-символов. Предложение сводится к наследованию флага TAINT_PROPRIETARY_MODULE во всех модулях, импортирующих символы из модулей с данным флагом. Таким образом, если GPL модуль-прослойка попытается импортировать символы из не-GPL модуля, то GPL-модуль унаследует метку TAINT_PROPRIETARY_MODULE и не сможет обращаться к компонентам ядра, доступным только для модулей под лицензией GPL, даже если модуль ранее импортировал символы из категории "gplonly".
При обсуждении также было высказано (https://lkml.org/lkml/2020/7/31/902) предложение по обратной блокировке - если модуль импортирует символы EXPORT_SYMBOL_GPL, любые экспортируемые данным модулем символы не должны импортироваться модулями, явно не заявляющими о совместимости с GPL. Т.е. если модуль импортирует символы EXPORT_SYMBOL_GPL, то все его экспортируемые символы должны обрабатываться как EXPORT_SYMBOL_GPL. Кристоф Хелвиг написал (https://lkml.org/lkml/2020/8/1/35), что на 100% согласен с данным предложением, но такое изменение не пропустит Линус Торвальдс, так как оно приведёт к недоступности для проприетарных драйверов большей части подсистем ядра, из-за того, что при разработке драйверов подключаются базовые символы, экспортируемые под GPL.
Изменение предложено в ответ на публикацию (https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E32664C7569@fb.com/T/#m3e84063e82ba14b758873d6cdde6d342157c586c) инженером из Facebook серии патчей с реализацией новой подсистемы netgpu, позволяющей организовать прямой обмен данными (DMA zero-copy) между сетевой картой и GPU, при этом выполняя обработку протокола силами CPU. Недовольство (https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E32664C7569@fb.com/T/#m556b6b762195afbbaf2782ba9be96ef9cf5e2e5c) разработчиков вызвала доступность (https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E32664C7569@fb.com/T/#md514322fdfa212afe9f1d3eb4e5f7eaefece36eb) реализации только для проприетарных драйверов NVIDIA через предоставляемую данными драйверами GPL-прослойку. В ответ на критику (https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E32664C7569@fb.com/T/#m3a5cab5ac3b0d386718bf62bd27b51510675dce0) автор патчей указал (https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E32664C7569@fb.com/T/#m758386d335ee7b4e332c44675ff68be29c79ec88), что подсистема не привязана к NVIDIA и её поддержка может быть обеспечена в том числе для программных интерфейсов к GPU AMD и Intel. В итоге продвижение netgpu в ядро было признано невозможным до появления рабочей поддержки на основе свободных драйверов, таких как AMDGPU, Intel i915 или Nouveau.
04.08.2020
https://www.opennet.ru/opennews/art.shtml?num=53485