[Open source, Разработка под Linux, Софт] «Проприетарному — нет»: драйверы-прослойки для доступа к GPL-вызовам ядра Linux предложили блокировать
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Проприетарные разработки глубоко проникли в код многих приложений и сервисов. В сложных системах избавиться от них очень непросто. Зачастую для этого используются обходные пути, которые скорее являются «костылями». В ядре Linux для работы с проприетарными драйверами используются драйверы-прослойки, которые предназначены практически исключительно для трансляции обращений драйвера к ядру. У прослойки код открытый, так что проблемы с GPL-лицензией нет, формальности соблюдены.
Но у такого подхода немало противников. Один из них — Кристоф Хелвиг (Christoph Hellwig), разработчик ядра Linux. Ранее он был членом управляющего технического комитета организации Linux Foundation. Также он выступал истцом в судебном процессе с VMware. Хелвиг предложил значительно ужесточить защиту от связывания проприетарных драйверов с компонентами ядра Linux.
Для этого он предлагает использовать патчи, которые дают возможность наследовать флаги, связанные с экспортом GPL-символов. В этом случае наследуется флаг TAINT_PROPRIETARY_MODULE во всех модулях, импортирующих символы из модулей с данным флагом. Суть защиты в том, что если драйвер-прослойка будет импортировать что-то не из GPL-модуля, то GPL-модуль унаследует метку TAINT_PROPRIETARY_MODULE и не сможет обращаться к компонентам ядра, доступным только для GPL-модулей.
Источник: 3dnews
В ходе обсуждения предложили и обратную блокировку. Так, если модуль импортирует EXPORT_SYMBOL_GPL, то в этом случае любые экспортируемые модулем символы не должны импортироваться теми модулями, которые не заявляют о совместимости с GPL. Предложение было сделано не Хелвигом, а другим участником дискуссии. Но Хелвиг согласился с ним. Скорее всего, Линус Торвальдс не пропустит это предложение, поскольку оно приведет к блокированию ряда подсистем ядра для проприетарных драйверов.
Весь сыр-бор разгорелся после публикации инженера из Facebook патчей с реализацией подсистемы netgpu. Эта подсистема дает возможность организовать прямой обмен данными между сетевой картой и GPU с выполнением обработки протокола силами CPU. На базе предложения можно сделать общую реализацию RDMA для обмена данными между GPU или внешней CXД. Многие разработчики выразили недовольство подобными нововведениями, поскольку реализация доступна лишь для проприетарных драйверов NVIDIA через предоставляемую этими драйверами прослойку. Хелвиг даже назвал разработчика троллем.
В свою очередь, автор патча возразил, что подсистема не привязана к NVIDIA, так что ее поддержка может быть обеспечена для программных интерфейсов к GPU AMD и Intel. В конечном итоге продвижение netgpu в ядре признали невозможным до появления рабочей поддержки на основе таких свободных драйверов, как AMDGPU, Intel i915 или Nouveau.
===========
Источник:
habr.com
===========
Похожие новости:
- [Системное администрирование, Софт, IT-компании] Microsoft Defender начал помечать файл hosts как зловредный, если там блокируется сбор телеметрии Windows 10
- [Open source, Реверс-инжиниринг] ReactOS 0.4.13 CE (Coronavirus Edition)
- [Open source, Разработка под Linux, Софт] Linux Kernel 5.8: что нового в ядре с самым большим количеством изменений за всю историю
- [*nix, Настройка Linux, Софт] NextCloud в качестве сервиса по созданию защищенных ссылок
- [Информационная безопасность, Системное администрирование, IT-инфраструктура, Софт] Включаем сбор событий о запуске подозрительных процессов в Windows и выявляем угрозы при помощи Quest InTrust
- Предложение по блокировке драйверов-прослоек, предоставляющих доступ к GPL-вызовам ядра Linux
- [Open source, .NET, Микросервисы] Как мы разрабатывали кроссплатформенную BPMS
- [Open source, Kubernetes] Будущее Prometheus и экосистемы проекта (2020) (перевод)
- [Ruby, Совершенный код, Компиляторы, Софт] Сложности работы с ANTLR: пишем грамматику Ruby
- [Open source, *nix] FOSS News №27 – обзор новостей свободного и открытого ПО за 27 июля – 2 августа 2020 года
Теги для поиска: #_open_source, #_razrabotka_pod_linux (Разработка под Linux), #_soft (Софт), #_proprietarnoe_po (проприетарное по), #_gpl, #_linux, #_open_source, #_blog_kompanii_selectel (
Блог компании Selectel
), #_open_source, #_razrabotka_pod_linux (
Разработка под Linux
), #_soft (
Софт
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 17:54
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Проприетарные разработки глубоко проникли в код многих приложений и сервисов. В сложных системах избавиться от них очень непросто. Зачастую для этого используются обходные пути, которые скорее являются «костылями». В ядре Linux для работы с проприетарными драйверами используются драйверы-прослойки, которые предназначены практически исключительно для трансляции обращений драйвера к ядру. У прослойки код открытый, так что проблемы с GPL-лицензией нет, формальности соблюдены. Но у такого подхода немало противников. Один из них — Кристоф Хелвиг (Christoph Hellwig), разработчик ядра Linux. Ранее он был членом управляющего технического комитета организации Linux Foundation. Также он выступал истцом в судебном процессе с VMware. Хелвиг предложил значительно ужесточить защиту от связывания проприетарных драйверов с компонентами ядра Linux. Для этого он предлагает использовать патчи, которые дают возможность наследовать флаги, связанные с экспортом GPL-символов. В этом случае наследуется флаг TAINT_PROPRIETARY_MODULE во всех модулях, импортирующих символы из модулей с данным флагом. Суть защиты в том, что если драйвер-прослойка будет импортировать что-то не из GPL-модуля, то GPL-модуль унаследует метку TAINT_PROPRIETARY_MODULE и не сможет обращаться к компонентам ядра, доступным только для GPL-модулей.  Источник: 3dnews В ходе обсуждения предложили и обратную блокировку. Так, если модуль импортирует EXPORT_SYMBOL_GPL, то в этом случае любые экспортируемые модулем символы не должны импортироваться теми модулями, которые не заявляют о совместимости с GPL. Предложение было сделано не Хелвигом, а другим участником дискуссии. Но Хелвиг согласился с ним. Скорее всего, Линус Торвальдс не пропустит это предложение, поскольку оно приведет к блокированию ряда подсистем ядра для проприетарных драйверов. Весь сыр-бор разгорелся после публикации инженера из Facebook патчей с реализацией подсистемы netgpu. Эта подсистема дает возможность организовать прямой обмен данными между сетевой картой и GPU с выполнением обработки протокола силами CPU. На базе предложения можно сделать общую реализацию RDMA для обмена данными между GPU или внешней CXД. Многие разработчики выразили недовольство подобными нововведениями, поскольку реализация доступна лишь для проприетарных драйверов NVIDIA через предоставляемую этими драйверами прослойку. Хелвиг даже назвал разработчика троллем. В свою очередь, автор патча возразил, что подсистема не привязана к NVIDIA, так что ее поддержка может быть обеспечена для программных интерфейсов к GPU AMD и Intel. В конечном итоге продвижение netgpu в ядре признали невозможным до появления рабочей поддержки на основе таких свободных драйверов, как AMDGPU, Intel i915 или Nouveau. =========== Источник: habr.com =========== Похожие новости:
Блог компании Selectel ), #_open_source, #_razrabotka_pod_linux ( Разработка под Linux ), #_soft ( Софт ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 17:54
Часовой пояс: UTC + 5