- Linux kernel community लंबे समय से proprietary kernel modules को पसंद नहीं करती रही है, और Christoph Hellwig का patch उस workaround को फिर से संकरा करने की कोशिश है
- kernel proprietary modules की loading को सीधे प्रतिबंधित नहीं करता; इसके बजाय GPL-only exports के जरिए कुछ kernel symbols तक access केवल GPL-compatible modules को देता है
- 2020 में यह तरीका सामने आया था जिसमें एक GPL module, proprietary module और kernel के बीच पुल की तरह काम करता था—इसे GPL condom कहा जाता है। इसके बाद proprietary symbols इस्तेमाल करने वाले modules को भी proprietary माना जाने लगा
- नया workaround
symbol_get()के जरिए proprietary module के अंदरूनी symbols के addresses को सामान्य import प्रक्रिया के बिना हासिल करने का है, और Hellwig का मानना है कि NVIDIA ने इसी तरीके का इस्तेमाल करने के लिए code बदला - प्रस्तावित patch
symbol_get()को GPL-only न होने वाले symbols की lookup में fail कराकर workaround को रोकता है, लेकिन जब तक modules kernel address space में चलते हैं, access control को पूरी तरह सुरक्षित बनाना कठिन है
Proprietary kernel modules को लेकर पुराना तनाव
- Linux kernel community का proprietary kernel modules उपलब्ध कराने वालों के साथ रिश्ता सहज नहीं रहा है
- ऐसे modules को उनके creators के अलावा debug या fix करना मुश्किल होता है
- कई developers इसे kernel license और code copyright का उल्लंघन मानते हैं
- फिर भी proprietary modules को एक निश्चित दायरे में अनुमति दी जाती रही है
- Christoph Hellwig का हालिया patch इसी अनुमति के दायरे को थोड़ा और कम करने की दिशा में कदम है
2006 में loading ban की कोशिश और GPL-only exports
- 2006 में proprietary kernel modules की loading पर पूरी तरह ban लगाने की एक छोटी कोशिश हुई थी
- Linus Torvalds ने कई कारणों से उस कोशिश को रोक दिया था
- proprietary module को केवल Linux kernel में load करना अपने-आप में copyright infringement नहीं है
- Linux users ऐसा कर सकते हैं
- Torvalds ने माना कि ऐसा ban technical improvement से ज्यादा license debate में रुचि का संकेत दे सकता है
- proprietary modules का distribution copyright infringement हो सकता है, अगर वह module kernel code का derivative work हो
- लेकिन derivative work है या नहीं, यह अस्पष्ट है, और kernel खुद वास्तव में यह फैसला आसानी से नहीं कर सकता
- kernel में संभावित infringement वाले modules को रोकने के लिए पुरानी व्यवस्था के रूप में GPL-only exports मौजूद हैं
- kernel modules को उपयोगी काम करने के लिए kernel द्वारा export किए गए functions और data structure symbols तक access चाहिए
- कई symbols केवल GPL-compatible license घोषित करने वाले modules को ही उपलब्ध होते हैं
- यह तरीका proprietary modules को kernel functionality के बड़े हिस्से से दूर रखता है
GPL-only marking का इरादा और वास्तविकता
- सिद्धांत रूप में GPL-only marking का मतलब है कि कोई symbol kernel internals से गहराई से जुड़ा है, इसलिए उसे इस्तेमाल करने वाला code अनिवार्य रूप से kernel का derivative work है
- असल में developers ऐसी legal analysis नहीं करते
- आमतौर पर उनके पास ऐसी analysis करने की qualification भी नहीं होती
- व्यवहार में symbols को GPL-only mark करना अक्सर proprietary modules को overall ज्यादा कठिन बनाने के साधन के रूप में इस्तेमाल होता है
2020 में सामने आया intermediary workaround
- proprietary module makers लंबे समय से GPL-only exports की सीमाओं को bypass करने के तरीके खोजते रहे हैं
- GPL-compatible license को झूठा declare करने का तरीका भी है, लेकिन यह स्पष्ट गलती स्वीकार करने जैसा दिखता है, इसलिए कंपनियां स्वाभाविक रूप से इससे बचती हैं
- ज्यादा subtle तरीकों में से एक 2020 में peer-to-peer DMA से जुड़े patch set के दौरान सामने आया
- इस structure में GPL-compatible license घोषित करने वाला module intermediary बनता है
- वह module kernel द्वारा export किए गए सभी symbols तक access कर सकता है
- फिर proprietary module के symbols को import करने पर proprietary code अपनी जरूरत की kernel functionality तक access पा सकता है
- यह आम तौर पर कहे जाने वाले GPL condom तरीके का एक variant है
2020 का response patch
- उस समय Hellwig ने इस तरीके को कठिन बनाने वाला patch merge किया था
- मौजूदा kernel में proprietary module के symbols इस्तेमाल करने वाले modules को भी proprietary माना जाता है
- वे तुरंत GPL-only symbols तक access की क्षमता खो देते हैं
- अगर GPL-only symbols पहले से इस्तेमाल करने की स्थिति में proprietary module symbols import करने की कोशिश की जाए, तो वह fail हो जाती है
- यह check GPL module को proprietary module और kernel के बीच intermediary बनने का रास्ता रोकता है
symbol_get() के जरिए नया workaround
- kernel
symbol_get()macro प्रदान करता है, और असली काम__symbol_get()करता है - यह feature kernel symbol से जुड़े address को ढूंढता है
symbol_get()February 2002 के 2.5.48 release से kernel में मौजूद है, और इसे module loader के बड़े replacement के दौरान जोड़ा गया था- इसकी कुछ महत्वपूर्ण सीमाएं भी हैं
- यह केवल loadable modules द्वारा उपलब्ध कराए गए symbols को lookup करता है
- इसका उपयोग उन closely linked modules के लिए है जिन्हें reference loops के बिना यह संभालना होता है कि कोई एक module अभी load न हुआ हो
- ऊपर से देखने पर यह GPL-only kernel symbols की location ढूंढने के लिए इस्तेमाल नहीं किया जा सकता, इसलिए नियमों को bypass करना चाहने वाले proprietary module vendors के लिए यह ज्यादा मददगार नहीं दिखता
symbol_get() 2020 की रक्षा को कैसे bypass करता है
symbol_get()को normal import mechanism और उसकी restrictions से गुजरे बिना proprietary module का address हासिल करने के लिए इस्तेमाल किया जा सकता है- इस वजह से 2020 का fix फिर bypass हो सकता है
- नाममात्र का GPL-licensed module proprietary module को call कर सकता है
- वह proprietary module जरूरी kernel functionality तक access कर सकता है
- Hellwig ने आकलन किया कि NVIDIA ने इस workaround का इस्तेमाल करने के लिए code बदला
नए patch set से behavior में बदलाव
- Hellwig ने इस loophole को फिर बंद करने के लिए patch set post किया, और बाद में revised version भी submit किया गया
- मुख्य बदलाव
symbol_get()के behavior को बदलना है- अगर lookup किया जाने वाला symbol GPL-only के रूप में mark नहीं है, तो यह fail होगा
- यह आमतौर पर GPL-only mark किए गए symbols तक access deny करने वाली जांच की उलटी दिशा की check है
- वजह यह है कि
symbol_get()मूल रूप से kernel के भीतर गहरे low-level cooperation के लिए feature है, और उस क्षेत्र में सब कुछ GPL-only होने की अपेक्षा की जाती है - kernel के अंदर इसके कुछ existing uses ऐसे symbols को target कर रहे थे जिन्हें GPL-only mark नहीं किया गया था
- patch set में उन मामलों के symbols को GPL-only में बदलने वाले changes भी शामिल हैं
अपेक्षित प्रभाव और सीमाएं
symbol_get()में यह बदलाव GPL-licensed kernel modules कोsymbol_get()के जरिए proprietary module के internal symbols resolve करने से असंभव बना देगा- अगर यह बदलाव mainline release में शामिल होकर distributions तक पहुंचता है, तो proprietary module developers को जरूरी kernel internal access पाने के लिए दूसरे तरीके खोजने होंगे
- module maintainer Luis Chamberlain ने यह बदलाव apply कर दिया है, इसलिए अंततः इसके mainline में जाने की संभावना काफी अच्छी दिखती है
- यह conflict लंबे समय से जारी है, और proprietary module authors के kernel community के इरादे को bypass करने का कोई और तरीका खोज लेने की संभावना कम नहीं है
- proprietary हों या नहीं, modules kernel address space में ही चलते हैं
- kernel की symbol access policy को bypass करने की कोशिश करने वाले modules के लिए attack surface बड़ा है
- इस क्षेत्र को पूरी तरह protect करना कठिन है
- व्यावहारिक रूप से सबसे अच्छा उपाय यही है कि binary-only kernel modules distribute करने वालों के लिए free-license solutions बनाना लगातार अधिक असुविधाजनक बनाया जाए
- यह तरीका perfect नहीं है, लेकिन पिछले वर्षों में यह अक्सर असरदार साबित हुआ है
1 टिप्पणियां
Hacker News टिप्पणियां
Linux kernel का linker code इस तरह design किया गया है कि GPL और system call exception कैसे काम करने चाहिए, इस पर Linus Torvalds की व्याख्या लागू हो; इसलिए ऐसा लगता है कि Nvidia के खिलाफ copyright protection circumvention (DMCA 1201) का दावा करने की कानूनी गुंजाइश हो सकती है
Linus शायद सच में ऐसा नहीं करेंगे, और ऐसा करना पूरे FOSS ecosystem के लिए भी काफी भयानक होगा, लेकिन Nvidia ने अब तक जो किया है उसे देखते हुए, एक बार ऐसा होते देखना मन भी करता है
अगर कमरे का 800-pound gorilla, Linux तक court जाने को तैयार नहीं है, तो बाकी projects का भविष्य भी उजला नहीं दिखता
अगर Linux बड़ी कंपनियों द्वारा खुलेआम license और copyright उल्लंघन पर सिर्फ “soft” technical pressure ही इस्तेमाल करने वाला है, तो लगता है कि GPL को खत्म मानकर BSD3 या MIT+Apache जैसी तरफ जाना बेहतर होगा
LLVM strong copyleft इस्तेमाल नहीं करता, और API changes व बहुत तेज development pace जैसे purely technical तरीकों से upstream collaboration को बढ़ावा देता है; चुने हुए license को dilute किए बिना भी यह काफी अच्छी तरह काम करता है
Nvidia के business opportunities को वास्तविक नुकसान पहुंचा सकने वाला counter-suit आगे की समस्याओं को रोकने के लिए deterrent की तरह अच्छी तरह काम कर सकता है
उसका आशय कुछ ऐसा है कि “symbol_get मूल रूप से केवल उन tightly cooperating modules के लिए था जो बहुत internal symbols इस्तेमाल करते हैं, इसलिए इसे सिर्फ EXPORY_SYMBOL_GPL के लिए सीमित करना और Nvidia को महंगा DMCA access control circumvention lawsuit टालने देना logical है”; यह Nvidia द्वारा मंशा और consideration को खुलेआम अनदेखा कर मनमानी करने पर बहुत बढ़िया तंज है
सपना तो देख ही सकते हैं :)
[1]: https://www.youtube.com/watch?v=tQIdxbWhHSM
Linus के पास कोई विशेष अधिकार नहीं है
इस patch के author की छोड़ी गई comment सचमुच अजीब है
https://lore.kernel.org/lkml/20230731083806.453036-6-hch@lst...
इसमें लिखा है कि “symbol_get मूल रूप से केवल उन tightly cooperating modules के लिए था जो बहुत internal symbols इस्तेमाल करते हैं, इसलिए इसे सिर्फ EXPORY_SYMBOL_GPL के लिए सीमित करना और nvidia को महंगा DMCA access control circumvention lawsuit टालने देना logical है”
यह सचमुच Linux kernel जैसे open source project के लिए, DRM circumvention को illegal बनाने वाले DMCA anti-circumvention provisions की protection का दावा करने की कोशिश है
साथ ही यह implicit रूप से स्वीकार करना भी है कि EXPORT_SYMBOL_GPL साफ तौर पर एक DRM system है
निजी तौर पर मुझे NVIDIA पसंद नहीं है और उनके व्यवहार का खास बचाव करने का मेरा कोई इरादा नहीं है, लेकिन Linux project का यह दावा करना हैरान करता है कि DRM anti-circumvention law open source projects पर भी लागू होता है
यह उन laws में से एक है जिनका open source community लगभग universal विरोध करती है, और कोई भी DRM system FOSS की values से काफी असंगत लगता है
GPL का मुख्य लक्ष्य ही copyright law को copyright law के खिलाफ इस्तेमाल करना था, यानी copyleft
copyright law जितना मजबूत होगा, GPL की protection भी उतनी मजबूत होगी; इसलिए open source software की रक्षा के लिए अतिरिक्त copyright law का उपयोग करना GPL spirit के काफी अनुरूप लगता है
GPL permissive license नहीं, बल्कि strong copyleft license है, और इसकी real enforceability है
taint mechanism hypocrisy नहीं बल्कि open source है, और अगर code GPL है तो आप जैसा चाहें वैसा कर सकते हैं
यह सचमुच GPL license के linking provisions को enforce करने वाला device है
जरूरत पड़ने पर उस law का उपयोग करना चाहिए, इसलिए यह बिल्कुल अजीब नहीं लगता
अगर किसी ने suspicious हरकत की हो और फिर भी उसे इतनी नरमी से इज्जत बचाने का मौका दिया जाए, तो यह उसकी किस्मत अच्छी है
GPL appropriation रोकने के लिए DRM logical next step लगता है
समझ नहीं आता कि proprietary driver को free kernel के साथ interact क्यों नहीं करना चाहिए
Linux सचमुच kernel-level DRM लागू कर रहा है, वही चीज़ जिसे free software ने नष्ट करने की कसम खाई थी
कम से कम proprietary driver को GPL-only code के साथ interact करने से रोकने की मांग, मेरे नज़रिए से EULA जैसी लगती है
अगर सिर्फ GPLv2 होता, तो proprietary modules शायद infringement होते
लेकिन Linus ने साफ कहा है कि system calls GPL copyleft को trigger नहीं करते, इसलिए system call के अंतर्गत आने वाले kernel symbols भी GPL copyleft को trigger नहीं करते
इसलिए Linus की GPL exception interpretation के हिसाब से license violation से बचने के लिए ऐसा loader चाहिए जो license data देखकर तय करे कि कौन-से symbols link किए जा सकते हैं और कौन-से नहीं
यह सचमुच kernel-level DRM है[0], और Linus के पास Nvidia के copy protection bypass पर legal claim करने की गुंजाइश भी हो सकती है
GPLv3 covered code में किसी भी copy protection को स्पष्ट रूप से अस्वीकार करता है, इसलिए theory में ऐसा lawsuit रोक सकता है, लेकिन उस clause की court में testing नहीं हुई है, और Linus GPLv3 को खास तौर पर TiVo clause जोड़ने की वजह से नापसंद करते हैं[1]
यह feature दशकों पहले implement हुआ था, और मूल लक्ष्य यह था कि unfixable proprietary modules की वजह से Linux kernel crash होने वाली bug reports न मिलें
GPL enforcement side effect था
[0] Kernel के अंदर मौजूद दूसरे DRM, Direct Rendering Manager, से confuse न करें
[1] TiVo clause खुद से नापसंदगी से ज़्यादा, v2 software पर retroactively शर्तें जोड़ने और deal की terms बदलने से नापसंदगी है। क्योंकि इससे लगता है जैसे Linux को FSF ने कब्ज़े में ले लिया हो
बस उन्हें ऐसे काफी सामान्य operating system features का इस्तेमाल करना चाहिए जो कई similar kernels में मिलते हैं
ऐसे drivers जो Linux-specific features पर निर्भर नहीं होते, उन्हें Linux kernel का “derivative work” नहीं माना जा सकता, इसलिए वे अपनी पसंद का license चुन सकते हैं
उल्टा, जो drivers Linux kernel-specific interfaces इस्तेमाल करते हैं जो दूसरे operating systems, यहां तक कि दूसरे Unix-like kernels में भी नहीं हैं, वे definition के हिसाब से kernel के “work based on the Program” के ज़्यादा करीब हैं, और इसलिए उन्हें मिलते-जुलते तरीके से license होना चाहिए
Kernel जिस GPL-2 text का पालन करता है, उसे देख सकते हैं
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
LGPL अलग से इसलिए मौजूद है ताकि free software और proprietary software की अलग linking की अनुमति दी जा सके, जो GPL में प्रतिबंधित है
लेकिन Linux GPL-2 है, इसलिए ऐसी अतिरिक्त अनुमति लागू नहीं होती
अगर Nvidia driver सिर्फ सामान्य kernel API इस्तेमाल करता, तो ठीक होता, लेकिन असल में ऐसा नहीं है
वह Linux-only APIs को non-GPL रूप में इस्तेमाल करने की कोशिश करता है, जिन्हें GPL-compatible licensed drivers के इस्तेमाल के लिए mark किया गया है, इसलिए यह Linux जिस free software license के तहत दिया जाता है, उसका साफ उल्लंघन है
Proprietary software को free software के सारे फायदे लेते हुए कोई rules न मानने की छूट क्यों होनी चाहिए, और free software बस सहता रहे?
Democratic societies में भी खुद को बचाने के लिए expression को कुछ हद तक limit करने की व्यवस्थाएं होती हैं
Proprietary operating systems पहले से बहुत हैं और उन्हें ऐसी बातों की बिल्कुल परवाह नहीं
तो क्या ऐसा operating system नहीं हो सकता जिसे उन principles की परवाह हो? क्या सब कुछ मानवीय संवेदना से खाली, ठंडा और industry-friendly tool ही होना चाहिए?
License का intent यह है कि kernel से link और load होने वाली हर चीज़ compatible copyleft license के तहत distribute हो
Proprietary code को GPL code “include” नहीं करना चाहिए, यह requirement खुद GPL है, और GPL का core purpose है
हालांकि केवल API से link करना किस हद तक infringement है, इस पर dispute की गुंजाइश है
दोनों तरफ का verdict संभव लगता है, और ऐसा फैसला GPL पर बड़ा असर डालेगा
Nvidia code ring0 में चलता है, इसलिए experience के हिसाब से Nvidia के पास इस्तेमाल करने के लिए कहीं ज़्यादा दिलचस्प tricks होंगी, लेकिन फिलहाल शायद वह restraint दिखा रहा है
Linux developers भी ऐसा ही कर रहे हैं
यह बेवकूफाना DRM लड़ाई किसी के काम नहीं आती, और सबका समय बर्बाद करने वाले cat-and-mouse game को ही बढ़ाती है
“दोस्तों, मिल-जुलकर रहो”
समझ नहीं आता कि Nvidia अपने drivers को proprietary binary blob बनाए रखने में इतनी मेहनत क्यों लगाता है
Software उनकी defensibility का core भी नहीं है, Nvidia एक hardware company है
Kernel module open करने से hardware sales पर असर नहीं पड़ेगा, उल्टा stability बेहतर होगी और उन developers की goodwill भी मिलेगी जो जानबूझकर AMD GPU खरीदने की ओर मुड़ जाते हैं
क्योंकि commoditization मोटे profit margins के बिल्कुल उलट है
GPU market का करीब 80% हिस्सा होने के बाद profit margins और बढ़ाने के लिए ज्यादा aggressive pricing करना, या पूरे stack की ऊंची layers को control करना आसान होता है
उदाहरण के लिए, अगर प्रमुख general-purpose GPU language उनके अपने GPU architecture के इर्द-गिर्द बनी हो, तो फायदा होता है
या फिर पूरी तरह दूसरे क्षेत्रों में expand करना होगा, और Nvidia का AI में जोरदार कदम रखना भी इसलिए है क्योंकि GPU dominance का लाभ उठाकर उस क्षेत्र में शुरुआती बढ़त हासिल की जा सकती है
हालांकि इसका कोई आधार नहीं है
“गैरकानूनी” होना अदालत में साबित होने तक सिर्फ़ एक थ्योरी ही है
यहां असल में बात kernel code के अंदर DRM की है, जिसका मकसद loadable kernel modules को यह अनुमान लगाने से रोकना है कि kernel data structures memory में कहां हैं
क्योंकि पता है कि लोग सीमाओं को push करने की कोशिश करेंगे, इसलिए deterrent के तौर पर इसे जितना हो सके उतना मुश्किल बनाया जा रहा है
लेकिन यह भी कहा जा सकता है कि “shim” हो या न हो, सभी closed-source loadable kernel modules GPL का समान रूप से उल्लंघन करते हैं; असल में ऐसा दावा किया भी गया है, मगर ज़्यादातर लोग उसे भूलकर इस DRM वाली कल्पना को कानूनी कल्पना के विकल्प की तरह इस्तेमाल कर रहे हैं
या अगर kernel के अंदर GPL-tagged functions, Google बनाम Oracle मामले में बताए गए अर्थ में API माने जाएं, तो यह पूरी बहस शायद बहुत मायने न रखे
ज़्यादातर loadable kernel modules kernel source tree में हैं और GPL के तहत उपलब्ध हैं
अगले कदम के तौर पर, user mode में binary blob load करने वाली एक छोटी virtual machine शामिल करके open-source loadable module बनाया जा सकता है
यह सिर्फ़ NVIDIA के private key से signed binary blob ही चलाए, और public key open-source module में शामिल हो
या फिर Linux को virtualize करने वाला hypervisor बनाकर kernel के ज़्यादातर हिस्से को bypass किया जा सकता है…
रास्ते हमेशा होते हैं
यह बस चीज़ों को परेशान करने वाला बनाता है और Linux के लिए ठीक-ठाक drivers पाने की लागत बढ़ाता है, इसलिए उस दिशा में लगने वाली मेहनत कम हो जाएगी
यह कोई बड़ा नुकसान है या नहीं, यह साफ़ नहीं है
उम्मीद है कि यह लड़ाई आखिर में Linux के लिए Nvidia drivers के खत्म होने या और खराब होने तक नहीं पहुंचेगी
उन drivers के बिना मेरा पसंदीदा operating system gaming और AI की वजह से अचानक कम उपयोगी हो जाएगा
10 साल पहले बात अलग थी
तब मुख्य रूप से कुछ Linux geeks को फ़र्क पड़ता था जो Linux पर games खेलना चाहते थे, और revenue में उनका हिस्सा छोटा था
अब असल में NVIDIA की पूरी enterprise value AI पर टिकी है, और उस hardware को बड़े पैमाने पर खरीदने वाले लगभग सभी बड़े players उसे Linux पर इस्तेमाल करते हैं
NVIDIA के लिए Linux छोड़ना कोई विकल्प नहीं है
ऐसा न हो, इसके लिए वह शायद जो भी करना पड़े करेगा
जब तक nVidia खुला न हो, सारी support हटा दी जाए
लेकिन आजकल Linux पर hardware कैसे इस्तेमाल और support किया जाए, इस पर हमसे ज़्यादा commercial companies की आवाज़ है
Nvidia ने driver, या उसका कुछ हिस्सा, open source कर दिया है और अब redistributable firmware binaries भी देता है
ऊपर से कुछ पुराने cards पर firmware authentication भी टूट चुका है
इसलिए उम्मीद है कि समय के साथ proprietary driver का महत्व घटेगा
kernel level पर यह “तुम्हारे bits किस रंग के हैं”[1] जैसा मामला हो गया है… अच्छा है?
[1] https://ansuz.sooke.bc.ca/entry/23