Hacker News Reader

Comment by mich41 | Hacker News Reader

Unfortunately, giving userspace direct access to the hardware is quite common GPL-circumvention technique used by embedded vendors.

One creative example I've seen was an x86 mITX motherboard targeted at the embedded market whose "Linux driver package" included kernel module implementing a simple virtual machine which executed programs uploaded by userspace and gave them unrestricted access to the x86 IO space.

View on HN

It's not really about GPL violation, it's about laziness. There are plenty of things Samsung could have done to work around the GPL without opening a massive hole. For example, they could have created a user-space server, which either mapped /dev/mem directly (as root, and then dropped permissions) or mapped this special device but was only given permission to do so after some cryptographic check by the kernel: a simple hash of the text would have sufficed.

This is just a dumb mistake, on par with the original Android G1 release which ran everything you typed on the keyboard in a root shell.

Can you explain what this has to do with the GPL?

iirc, if you write a kernel module you have to release it under GPL, but if it's just a user space program you can keep its source closed.

Writing closed-source Linux kernel modules is legally "difficult". It is generally believed that modules which make use of highly Linux-specific internal infrastructure can be considered derived works of the kernel and thus required to be released under GPL. It's not always perfectly clear what is allowed and what is not and hardware vendors are reluctant to find it out in court. Some kernel APIs are explicitly marked as not callable from proprietary modules and the module loader enforces this. As a famous example, NVIDIA claims that inability to use one of these APIs prevents them from supporting Optimus in their video driver.

Hardware vendors who don't want to open their drivers need to work around these issues. They can either divide the driver into open-source Linux-specific part and closed-source "hardware support library" which avoids calling suspicious kernel APIs, or simply move the whole driver to a userspace shared library and give userspace processes access to the hardware.

So the userspace driver uses the same syscalls or they need to do the work around. I guess I am most interested in the workarounds.

Userspace components are expressly excluded from being considered derived works of the kernel by text at the top of its license. Within the kernel, individual symbols (e.g. function calls) are explicitly tagged with a bit that tells the kernel whether they can be used by non-GPL code, and the kernel checks this at runtime.

Reply on news.ycombinator.com