- Cộng đồng kernel Linux từ lâu đã không thiện cảm với các module kernel proprietary, và bản vá của Christoph Hellwig là động thái tiếp tục thu hẹp các đường lách luật đó
- Thay vì cấm hẳn việc nạp module proprietary, kernel dùng GPL-only exports để chỉ cho phép module tương thích GPL truy cập một số symbol của kernel
- Năm 2020, cách làm GPL condom trong đó một module GPL đóng vai trò cầu nối giữa module proprietary và kernel đã bị lộ, sau đó kernel được thay đổi để cả module dùng symbol proprietary cũng bị xem là proprietary
- Đường lách mới dùng
symbol_get()để lấy địa chỉ symbol bên trong module proprietary mà không đi qua quy trình import thông thường; Hellwig cho rằng NVIDIA đã sửa mã để dùng cách này - Bản vá được đề xuất sẽ khiến
symbol_get()thất bại khi tra cứu các symbol không phải GPL-only, từ đó chặn đường lách này, nhưng khi module vẫn chạy trong không gian địa chỉ của kernel thì rất khó khiến việc kiểm soát truy cập an toàn tuyệt đối
Căng thẳng kéo dài quanh các module kernel proprietary
- Cộng đồng kernel Linux từ lâu không có quan hệ suôn sẻ với các nhà cung cấp module kernel proprietary
- Những module như vậy rất khó để người ngoài tác giả gốc gỡ lỗi hoặc sửa chữa
- Nhiều nhà phát triển xem đó là hành vi vi phạm giấy phép kernel và bản quyền mã nguồn
- Dù vậy, các module proprietary vẫn được cho phép trong một phạm vi nhất định
- Bản vá gần đây của Christoph Hellwig là nỗ lực thu hẹp thêm phạm vi cho phép đó
Nỗ lực cấm nạp năm 2006 và GPL-only exports
- Năm 2006 từng có một nỗ lực ngắn nhằm cấm hoàn toàn việc nạp module kernel proprietary
- Linus Torvalds đã ngăn nỗ lực đó vì nhiều lý do
- Chỉ riêng việc nạp một module proprietary vào kernel Linux không tự thân là hành vi vi phạm bản quyền
- Người dùng Linux có thể làm điều đó
- Torvalds cho rằng lệnh cấm như vậy có thể phát đi tín hiệu rằng dự án quan tâm đến tranh cãi giấy phép hơn là cải tiến kỹ thuật
- Việc phân phối module proprietary có thể là hành vi xâm phạm bản quyền nếu module đó là tác phẩm phái sinh của mã kernel
- Tuy nhiên, việc có phải tác phẩm phái sinh hay không vẫn mơ hồ, và bản thân kernel khó có thể thực sự đưa ra phán định đó
- Trong kernel có cơ chế lâu đời là GPL-only exports để chặn các module có khả năng vi phạm
- Module kernel phải truy cập được các function và symbol cấu trúc dữ liệu mà kernel export thì mới làm được việc hữu ích
- Nhiều symbol chỉ được phép dùng bởi các module khai báo giấy phép tương thích GPL
- Cách này tách các module proprietary khỏi một phần đáng kể chức năng của kernel
Ý đồ và thực tế của nhãn GPL-only
- Về lý thuyết, việc gắn nhãn GPL-only có nghĩa là một symbol gắn bó quá sâu với nội bộ kernel, đến mức mã sử dụng nó tất yếu là tác phẩm phái sinh của kernel
- Nhưng trên thực tế các nhà phát triển không thực hiện kiểu phân tích pháp lý đó
- Và thường họ cũng không đủ tư cách để làm việc đó
- Trong thực tế, việc đánh dấu symbol là GPL-only thường được dùng như một cách khiến mọi module proprietary trở nên khó làm việc hơn
Cách lách qua trung gian bị lộ năm 2020
- Các nhà làm module proprietary từ lâu đã tìm cách vượt qua hạn chế của GPL-only exports
- Một cách là khai báo gian dối giấy phép tương thích GPL, nhưng các công ty thường né tránh theo bản năng vì điều đó trông như tự thừa nhận sai phạm rõ ràng
- Một cách tinh vi hơn đã lộ ra trong quá trình thảo luận một loạt bản vá liên quan đến peer-to-peer DMA năm 2020
- Trong cấu trúc này, một module khai báo giấy phép tương thích GPL đóng vai trò trung gian
- Module đó có thể truy cập mọi symbol mà kernel export
- Sau đó nếu nó import symbol của module proprietary, mã proprietary sẽ có thể tiếp cận các chức năng kernel cần thiết
- Đây là một biến thể của cách thường được gọi là GPL condom
Bản vá đối phó năm 2020
- Khi đó Hellwig đã hợp nhất một bản vá để khiến cách này khó dùng hơn
- Trong kernel hiện nay, module dùng symbol của module proprietary cũng bị xem là proprietary
- Nó lập tức mất khả năng truy cập các symbol GPL-only
- Nếu đã dùng symbol GPL-only rồi mới định import symbol của module proprietary thì thao tác đó sẽ thất bại
- Kiểm tra này chặn con đường để module GPL làm trung gian giữa module proprietary và kernel
Đường lách mới qua symbol_get()
- Kernel cung cấp macro
symbol_get(), còn phần xử lý thực tế do__symbol_get()thực hiện - Tính năng này tìm địa chỉ gắn với một symbol kernel
symbol_get()đã có trong kernel từ bản phát hành 2.5.48 năm 2002 và được thêm vào trong quá trình thay thế lớn hệ thống module loader- Nó cũng có những giới hạn quan trọng
- Chỉ tra cứu các symbol do module có thể nạp cung cấp
- Mục đích là để các module gắn bó chặt chẽ có thể xử lý trường hợp một phía chưa được nạp mà không tạo vòng tham chiếu
- Nhìn bề ngoài, nó không thể dùng để tìm vị trí các symbol kernel GPL-only, nên có vẻ không giúp ích nhiều cho các hãng module proprietary muốn lách luật
symbol_get() lách qua lớp phòng thủ năm 2020 như thế nào
symbol_get()có thể được dùng để lấy địa chỉ của module proprietary mà không đi qua cơ chế import bình thường cùng các ràng buộc của nó- Vì vậy, sửa đổi năm 2020 lại có thể bị vượt qua
- Một module danh nghĩa mang giấy phép GPL có thể gọi vào module proprietary
- Module proprietary đó sau đó có thể truy cập các chức năng kernel mà nó cần
- Hellwig cho rằng NVIDIA đã sửa mã để dùng cách lách này theo đánh giá của ông
Thay đổi hành vi trong loạt bản vá mới
- Hellwig đã gửi một loạt bản vá để bịt lại lỗ hổng này, và sau đó còn có bản sửa đổi
- Thay đổi cốt lõi là điều chỉnh hành vi của
symbol_get()- Nếu symbol cần tra cứu không được đánh dấu GPL-only thì sẽ thất bại
- Đây là kiểu kiểm tra theo hướng ngược lại với cách thường thấy là từ chối truy cập symbol GPL-only
- Lý do là
symbol_get()vốn là tính năng phục vụ hợp tác mức thấp ở sâu trong kernel, nơi người ta kỳ vọng mọi thứ đều là GPL-only - Một số chỗ dùng hiện có trong kernel lại nhắm đến các symbol chưa được đánh dấu GPL-only
- Loạt bản vá cũng bao gồm thay đổi chuyển các symbol trong những trường hợp đó sang GPL-only
Tác động dự kiến và giới hạn
- Thay đổi lần này với
symbol_get()sẽ khiến module kernel giấy phép GPL không thể dùngsymbol_get()để phân giải các symbol nội bộ của module proprietary - Nếu thay đổi này vào mainline và được các bản phân phối đưa xuống, các nhà phát triển module proprietary sẽ phải tìm cách khác để có được quyền truy cập nội bộ kernel mà họ cần
- Vì người bảo trì module là Luis Chamberlain đã áp dụng thay đổi này, khả năng nó vào mainline cuối cùng có vẻ khá cao
- Xung đột này đã kéo dài từ lâu, và khả năng các tác giả module proprietary tiếp tục tìm ra cách khác để lách ý định của cộng đồng kernel là không nhỏ
- Dù proprietary hay không, module vẫn chạy trong không gian địa chỉ kernel
- Bề mặt tấn công dành cho module muốn vượt qua chính sách truy cập symbol của kernel là rất lớn
- Khu vực này rất khó được bảo vệ hoàn toàn
- Trên thực tế, điều tốt nhất có thể làm là tiếp tục khiến các nhà phân phối module kernel chỉ có bản nhị phân cảm thấy bất tiện đến mức họ phải tạo ra các giải pháp giấy phép tự do
- Cách này không hoàn hảo, nhưng qua nhiều năm nó thường đã tỏ ra hiệu quả
1 bình luận
Các ý kiến trên Hacker News
Mã linker của nhân Linux được thiết kế để buộc thực thi cách diễn giải của Linus Torvalds về việc GPL và ngoại lệ lời gọi hệ thống nên hoạt động như thế nào, nên có vẻ có cơ sở pháp lý để cho rằng Nvidia đã lách biện pháp bảo vệ bản quyền (DMCA 1201)
Linus có lẽ sẽ không thực sự làm vậy, và nếu làm thì cũng sẽ khá tệ hại cho toàn bộ hệ sinh thái FOSS, nhưng xét những gì Nvidia đã làm bấy lâu nay thì cũng muốn được thấy một lần
Nếu ngay cả “con gorilla 800 pound trong phòng” là Linux cũng không sẵn sàng ra tòa, thì triển vọng của các dự án còn lại cũng không mấy sáng sủa
Nếu Linux chỉ dùng áp lực kỹ thuật “mềm” trước những vi phạm giấy phép và bản quyền trắng trợn của các tập đoàn lớn, thì cũng có thể nghĩ rằng GPL coi như đã hết thời, và tốt hơn nên chuyển sang những thứ như BSD3 hoặc MIT+Apache
LLVM không dùng copyleft mạnh, mà khuyến khích hợp tác upstream bằng các phương tiện thuần kỹ thuật như biến động API và tốc độ phát triển rất nhanh; cách này hoạt động khá tốt mà không làm loãng giấy phép đã chọn
Một đơn kiện ngược có thể gây thiệt hại thực chất cho cơ hội kinh doanh của Nvidia có thể đóng vai trò răn đe tốt để ngăn các vấn đề về sau
Đại ý là “symbol_get vốn chỉ dành cho các module hợp tác chặt chẽ dùng những symbol rất nội bộ, nên việc giới hạn nó chỉ dùng với EXPORY_SYMBOL_GPL và giúp Nvidia tránh một vụ kiện tốn kém về lách biện pháp kiểm soát truy cập theo DMCA là hợp lý”; đây là một cách châm biếm rất hay việc Nvidia trắng trợn phớt lờ ý định và sự cân nhắc rồi muốn làm gì thì làm
Cứ mơ thôi :)
[1]: https://www.youtube.com/watch?v=tQIdxbWhHSM
Linus không có quyền hạn đặc biệt nào cả
Bình luận mà tác giả bản vá này để lại thật sự rất lạ
https://lore.kernel.org/lkml/20230731083806.453036-6-hch@lst...
Trong đó viết rằng “symbol_get vốn chỉ dành cho các module hợp tác chặt chẽ dùng những symbol rất nội bộ, nên việc giới hạn nó chỉ dùng với EXPORY_SYMBOL_GPL và giúp nvidia tránh một vụ kiện tốn kém về lách biện pháp kiểm soát truy cập theo DMCA là hợp lý”
Nói thẳng ra, đây là một nỗ lực nhằm khẳng định sự bảo vệ của điều khoản chống lách DMCA, vốn khiến việc lách DRM trở thành bất hợp pháp, đối với nhân Linux là một dự án nguồn mở
Đồng thời, điều đó cũng ngầm thừa nhận rằng EXPORT_SYMBOL_GPL rõ ràng là một cơ chế DRM
Cá nhân tôi không thích NVIDIA và cũng không có ý định đặc biệt bênh vực hành vi của họ, nhưng việc dự án Linux lập luận rằng luật chống lách DRM cũng áp dụng cho dự án nguồn mở thì thật đáng ngạc nhiên
Đây là một trong những luật mà cộng đồng nguồn mở gần như phản đối rộng rãi, và bất kỳ cơ chế DRM nào cũng có vẻ khá trái với các giá trị của FOSS
Mục tiêu cốt lõi của GPL vốn là dùng luật bản quyền để chống lại luật bản quyền, tức là copyleft
Luật bản quyền càng mạnh thì sự bảo vệ của GPL cũng càng mạnh, nên việc tận dụng thêm các chế định bản quyền để bảo vệ phần mềm nguồn mở theo tôi khá phù hợp với tinh thần GPL
GPL không phải là giấy phép permissive mà là giấy phép copyleft mạnh, và có khả năng thực thi thực sự
Cơ chế taint không phải là đạo đức giả mà là nguồn mở; nếu mã là GPL thì bạn có thể làm theo ý mình
Nói đúng nghĩa, đó là thiết bị để cưỡng chế điều khoản liên kết của giấy phép GPL
Khi cần thì phải dùng luật đó, nên tôi không thấy lạ chút nào
Nếu đã làm chuyện đáng ngờ mà vẫn được giữ thể diện nhẹ nhàng như thế này thì là khá may mắn rồi
DRM để ngăn việc chiếm dụng GPL có vẻ là bước tiếp theo hợp lý
Tôi không hiểu vì sao driver độc quyền lại không được tương tác với kernel tự do
Linux đúng nghĩa đang triển khai DRM ở cấp kernel, chính là thứ mà phần mềm tự do từng thề sẽ phá bỏ
Ít nhất, yêu cầu không cho driver độc quyền tương tác với mã chỉ dành cho GPL, theo góc nhìn của tôi, gần giống EULA hơn
Nếu chỉ có GPLv2 thì các module độc quyền có lẽ đã là vi phạm
Nhưng vì Linus đã nói rõ rằng system call không kích hoạt copyleft của GPL, nên các symbol kernel tương ứng với system call cũng không kích hoạt copyleft của GPL
Vì vậy, để tránh vi phạm giấy phép theo cách diễn giải ngoại lệ GPL của Linus, cần có một loader kiểm tra dữ liệu giấy phép để biết symbol nào có thể link và symbol nào không
Đây đúng là DRM ở cấp kernel[0], và có thể Linus vẫn có dư địa đưa ra lập luận pháp lý về việc Nvidia vượt qua biện pháp bảo vệ sao chép
GPLv3 phủ nhận rõ ràng mọi biện pháp bảo vệ sao chép trong mã được áp dụng, nên về lý thuyết có thể ngăn một vụ kiện như vậy, nhưng điều khoản đó chưa được kiểm chứng tại tòa, và Linus đặc biệt ghét GPLv3 vì nó thêm điều khoản TiVo[1]
Tính năng này đã được triển khai từ nhiều thập kỷ trước, và mục tiêu ban đầu là không phải nhận các báo cáo lỗi rằng kernel Linux bị crash vì những module độc quyền không thể sửa
Việc thực thi GPL chỉ là tác dụng phụ
[0] Không nên nhầm với DRM khác trong kernel là Direct Rendering Manager
[1] Không hẳn là ghét bản thân điều khoản TiVo, mà ghét việc thêm điều kiện hồi tố vào phần mềm v2 và thay đổi điều kiện giao dịch. Vì điều đó tạo cảm giác Linux bị FSF chiếm quyền kiểm soát
Chỉ là chúng phải dùng các tính năng hệ điều hành khá phổ biến có thể tìm thấy trong nhiều kernel tương tự
Những driver không phụ thuộc vào các tính năng đặc thù của Linux như vậy không thể bị xem là “tác phẩm phái sinh” của kernel Linux, nên có thể chọn giấy phép tùy ý
Ngược lại, một driver dùng các giao diện đặc thù của kernel Linux không có trong các hệ điều hành khác, thậm chí không có trong các kernel họ Unix khác, theo định nghĩa gần với “tác phẩm dựa trên Chương trình” của kernel, và do đó nên được cấp phép theo cách tương tự
Chỉ cần xem câu chữ GPL-2 mà kernel tuân theo
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
LGPL tồn tại riêng để cho phép liên kết tách biệt giữa phần mềm tự do và phần mềm độc quyền, điều bị cấm trong GPL
Nhưng Linux là GPL-2, nên sự cho phép bổ sung đó không áp dụng
Nếu driver Nvidia chỉ dùng các API kernel thông thường thì sẽ ổn, nhưng thực tế không phải vậy
Vì họ cố dùng các API dành riêng cho Linux, được đánh dấu để driver có giấy phép tương thích GPL sử dụng, trong trạng thái không phải GPL, nên đó là vi phạm rõ ràng giấy phép phần mềm tự do theo đó Linux được cung cấp
Tại sao phần mềm độc quyền lại được hưởng mọi lợi ích của phần mềm tự do mà không phải tuân theo bất kỳ quy tắc nào, còn phần mềm tự do thì cứ phải chịu đựng?
Ngay cả các xã hội dân chủ cũng có những cơ chế hạn chế biểu đạt ở mức độ nhất định để tự bảo vệ mình
Hệ điều hành độc quyền đã có rất nhiều rồi, và chúng hoàn toàn không bận tâm đến những điều đó
Không lẽ không được có một hệ điều hành quan tâm đến những nguyên tắc như vậy sao? Có phải mọi thứ đều phải là công cụ lạnh lùng, thân thiện với công nghiệp và không có sự cân nhắc nhân văn không?
Ý định của giấy phép là mọi thứ được link và load vào kernel phải được phân phối dưới một giấy phép copyleft tương thích
Yêu cầu mã độc quyền không được “bao gồm” mã GPL chính là bản thân GPL, và là mục đích cốt lõi của GPL
Tuy nhiên, việc chỉ link tới API thì ở mức nào mới là vi phạm vẫn còn có thể tranh luận
Phán quyết theo hướng nào cũng có vẻ khả dĩ, và nhận định như vậy sẽ có ảnh hưởng lớn đến GPL
Vì mã Nvidia chạy ở ring0, theo kinh nghiệm thì Nvidia còn có nhiều trò lách thú vị hơn mà họ có thể dùng, nhưng có lẽ hiện giờ đang kiềm chế
Các nhà phát triển Linux cũng vậy
Cuộc chiến DRM ngớ ngẩn này chẳng giúp ích cho ai, chỉ càng thúc đẩy trò mèo vờn chuột lãng phí thời gian của tất cả
“Mấy bạn à, sống hòa thuận đi”
Tôi không hiểu vì sao Nvidia lại bỏ nhiều công sức đến vậy để giữ driver dưới dạng một cục binary độc quyền
Phần mềm đâu phải cốt lõi năng lực phòng thủ của họ, Nvidia là công ty phần cứng mà
Việc công khai module kernel không những không ảnh hưởng đến doanh số phần cứng, mà còn cải thiện độ ổn định và giành được thiện cảm từ các developer vốn cố tình quay sang mua GPU AMD
Vì hàng hóa hóa đối nghịch trực tiếp với biên lợi nhuận dày
Khi đã nắm khoảng 80% thị trường GPU, để tăng biên lợi nhuận hơn nữa thì dễ nhất là tính giá mạnh tay hơn, hoặc kiểm soát các tầng cao hơn của toàn bộ stack
Ví dụ, nếu ngôn ngữ GPU đa dụng chủ chốt được xây dựng xoay quanh kiến trúc GPU của chính họ thì sẽ có lợi
Hoặc họ phải mở rộng sang lĩnh vực hoàn toàn khác, và việc Nvidia lao mạnh vào AI cũng là vì có thể tận dụng thế thống trị GPU để giành lợi thế ban đầu trong lĩnh vực đó
Nhưng không có căn cứ
Việc gọi là “bất hợp pháp” cho đến khi được chứng minh trước tòa thì rốt cuộc cũng chỉ là lý thuyết
Điều đang được nói ở đây về bản chất là DRM trong mã kernel, nhằm ngăn các kernel module có thể nạp đoán được các cấu trúc dữ liệu của kernel nằm ở đâu trong bộ nhớ
Vì biết mọi người có khả năng sẽ đẩy giới hạn đi xa, nên họ muốn làm cho việc đó khó nhất có thể như một biện pháp răn đe
Nhưng cũng có thể lập luận rằng mọi kernel module nguồn đóng có thể nạp đều vi phạm GPL như nhau, dù có “shim” hay không; thực tế đã từng có lập luận như vậy, nhưng phần lớn mọi người đã quên mất và đang dùng hư cấu DRM này như một thứ thay thế cho hư cấu pháp lý đó
Hoặc nếu các hàm được gắn thẻ GPL trong kernel là API theo nghĩa được nói trong vụ Google kiện Oracle, thì toàn bộ cuộc thảo luận này cũng có thể chẳng còn nhiều ý nghĩa
Phần lớn kernel module có thể nạp nằm trong cây mã nguồn kernel và được cung cấp theo GPL
Bước tiếp theo là tạo một module có thể nạp mã nguồn mở, chứa một máy ảo nhỏ để nạp một cục binary ở user mode
Nó chỉ chạy những cục binary được ký bằng khóa riêng của NVIDIA, còn khóa công khai thì đưa vào module mã nguồn mở
Hoặc tạo một hypervisor ảo hóa Linux để đi vòng qua phần lớn kernel, hay gì đó…
Luôn luôn có cách
Việc này chỉ khiến mọi thứ khó chịu hơn và làm tăng chi phí để có driver tốt cho Linux, nên nỗ lực đổ vào phía đó sẽ giảm đi
Không rõ đó có phải là một mất mát lớn hay không
Hy vọng cuộc chiến này cuối cùng không dẫn đến việc driver Nvidia cho Linux biến mất hoặc trở nên tệ hơn
Không có driver đó thì hệ điều hành tôi yêu thích bỗng kém hữu dụng hơn vì game và AI
10 năm trước thì khác
Khi đó chủ yếu chỉ một nhóm nhỏ các geek Linux muốn chơi game trên Linux quan tâm, và họ chỉ chiếm một phần nhỏ doanh thu
Bây giờ về cơ bản toàn bộ giá trị doanh nghiệp của NVIDIA được xây trên AI, và gần như mọi tay chơi lớn mua lượng lớn phần cứng đó đều dùng nó trên Linux
NVIDIA cắt bỏ Linux không phải là một lựa chọn
Họ rất có thể sẽ làm mọi thứ để chuyện đó không xảy ra
Tức là gỡ bỏ mọi hỗ trợ cho đến khi nVidia mở mã
Nhưng ngày nay không phải chúng ta, mà các công ty thương mại mới có tiếng nói lớn hơn về việc phần cứng được dùng và hỗ trợ trên Linux như thế nào
Nvidia đã mở mã nguồn driver, hoặc một phần của nó, và giờ cũng cung cấp binary firmware có thể phân phối lại
Hơn nữa, xác thực firmware trên một số card cũ cũng đã bị phá
Vì vậy hy vọng theo thời gian tầm quan trọng của driver độc quyền sẽ giảm đi
Ở cấp kernel, đây có phải đã thành chuyện “bit của anh có màu gì”[1] không… hay đấy?
[1] https://ansuz.sooke.bc.ca/entry/23