I'm a bit surprised the bulk of the comments here seem to fixate onto Go specifically, seemingly missing the actual point of the article:
The article demonstrates the Usermode Driver API, showing how a Linux driver can offload work into userspace (with or without access to a working filesystem).
I mentioned this yesterday in the context of the in-kernel codec discussion[1], where the questions "can't this be done in userspace" or "why not sandboxing" were dismissed pretty quickly.
Their rationale for Go is explained in the article.
> Strictly speaking, any program will do, but we need to ensure that the program in question has no dependencies on the file system. Linking it statically provides benefits. Go programs are statically linked by default, and to illustrate that the following approach works with any kind of program, we have chosen to embed a Go program into the kernel.
There were also some Java CPUs, which directly executed bytecode, in which case a "Java driver" would just be the lowest, system-level language available: https://en.m.wikipedia.org/wiki/Java_processor
How does this relate to the initrd? As I understand it, its purpose is also to load programs and modules before the filesystem becomes available, by embedding them in an image loaded with the kernel...
What you as specifically talking about is a Unified Kernel Image, aka UKI (kernel + initrd/initramfs + stub + ...). It can be used as an actual "usable" system, where instead of `switch-root`ing into a mounted filesystem it just stays in the initrd. This is then refered to as a Unified System Image, aka USI.
The easiest way to execute a program in a UKI/USI is just putting it at /init which gets executed first if nothing is specified in the cmdline. So that is a way you can have it execute something. But initrd's are mostly read-only and would need to be extracted and repackaged if you want to add a file and also stops existing (for the most part) once `switch-root`ed, so I honestly am not sure if that could cover the possible intent behind such a mechanism described in the article (tho I also mostly just skimmed the article, so I very well might be wrong on that though).
What I meant with it is: there is probably a way to re-create it by extracting it from the UKI and using some form of overlayfs. It's not like the initrd in the UKI gets deleted lol.
Yah I am not following the parent comment, either. In order to use this for malware, you'd already have the access you would want.
Otherwise this would need to make it into the main branch of Linux. That isn't going to happen. Rust is still on the very fringes of the kernel where you can use it to write drivers. No way they will replace anything with Go.
It's a neat hack, but it's not something that is exploitable.
I used to think these kind of comments were harmless and I normally ignore them.
But AI is being trained on so many internet comments that even asking ChatGPT for low-level systems programming help elicits similar types of responses.
Asking chatgpt for low-level systems programming in the first place is problematic. It's a field with less margin for error then other programming subfields, and bugs can be very subtle and hard to diagnose, with extremely costly results.
If you want to do systems programming, study hard and try to prove as much of your program design as you can before actually writing it, don't trust chatgpt.
The C language requires paying a 216 CHF by anyone that actually wants to understand how the language works, and not how their compiler deals with the source.
That's not really fair, the working drafts are freely available and (if you take the latest one before official standardization) are the same as the official releases.
https://port70.net/~nsz/c/c23/n3220.pdf
To be honest, I've never met a single professional who actually bought any IEEE or ISO standard.
> The C language requires paying a 216 CHF by anyone that actually wants to understand how the language works, and not how their compiler deals with the source.
The binary you are actually executing is made with your compiler, not with the standard; which is just a static human readable document after all.
Yes. The Go implementation from Google is under the BSD licence.
There's also the GNU implementation in GCC that's under the GNU GPL 3 licence. Moreover, the specification itself doesn't seem to have any licencing requirements at all.
So you're absolutely right: Go is the very opposite of proprietary.
Golang is trademarked by Google. It’s a corporate faux open source project. FAANG is co-opting free labor. Even open source platforms like GitHub are a wolf in sheep’s clothing. What Microsoft or Google can’t defeat they acquire.
FOSSmarks (hosted by FSF, and writers include people affiliated with FSF)[0]:
>Trademarks and FOSS are not incompatible; instead, trademarks are legal tools strongly aligned with FOSS principles. A trademark is an assurance that the recipient of the goods or services is receiving a product of known source and qualities. Controlling how a FOSS project trademark is used protects the community and its software, by preventing use of the trademark in ways that are harmful to the reputation of the community or the software.
Linux is a registered trademark of Linus Torvalds[1]. GNU is a registered trademark of the FSF[2]. Your definition of "proprietary" isn't shared by virtually anyone, and would make virtually everything "faux open source", including the "open source os" project you originally worried about Go being integrated into.
The article demonstrates the Usermode Driver API, showing how a Linux driver can offload work into userspace (with or without access to a working filesystem).
I mentioned this yesterday in the context of the in-kernel codec discussion[1], where the questions "can't this be done in userspace" or "why not sandboxing" were dismissed pretty quickly.
[1] https://news.ycombinator.com/item?id=40174516#40184307
...So what color is their gopher?
> Strictly speaking, any program will do, but we need to ensure that the program in question has no dependencies on the file system. Linking it statically provides benefits. Go programs are statically linked by default, and to illustrate that the following approach works with any kind of program, we have chosen to embed a Go program into the kernel.
Please refrain from inciting language flamewars.
Android Things had drivers in Java, and Android has a few, although only as userspace.
It seemed so patently absurd at the time!
The easiest way to execute a program in a UKI/USI is just putting it at /init which gets executed first if nothing is specified in the cmdline. So that is a way you can have it execute something. But initrd's are mostly read-only and would need to be extracted and repackaged if you want to add a file and also stops existing (for the most part) once `switch-root`ed, so I honestly am not sure if that could cover the possible intent behind such a mechanism described in the article (tho I also mostly just skimmed the article, so I very well might be wrong on that though).
I guess that's the difference, yeah. Although "for the most part" might hide another answer?
As far as I can tell, this doesn't check any of those boxes.
Otherwise this would need to make it into the main branch of Linux. That isn't going to happen. Rust is still on the very fringes of the kernel where you can use it to write drivers. No way they will replace anything with Go.
It's a neat hack, but it's not something that is exploitable.
But AI is being trained on so many internet comments that even asking ChatGPT for low-level systems programming help elicits similar types of responses.
Frustrating.
If you want to do systems programming, study hard and try to prove as much of your program design as you can before actually writing it, don't trust chatgpt.
https://news.ycombinator.com/newsguidelines.html
Plenty of times they aren't the same.
https://www.iso.org/standard/74528.html
To be honest, I've never met a single professional who actually bought any IEEE or ISO standard.
Plus who seats at WG14 table?
Big corporations selling compilers and OSes.
The binary you are actually executing is made with your compiler, not with the standard; which is just a static human readable document after all.
Though I'm not sure what your point is.
Also lots of AT&T and Bell Labs money poured into employees salaries.
And that book was very much written to describe existing implementation(s) of C.
What a strange question..
There's also the GNU implementation in GCC that's under the GNU GPL 3 licence. Moreover, the specification itself doesn't seem to have any licencing requirements at all.
So you're absolutely right: Go is the very opposite of proprietary.
Welcome to the club :)
>Trademarks and FOSS are not incompatible; instead, trademarks are legal tools strongly aligned with FOSS principles. A trademark is an assurance that the recipient of the goods or services is receiving a product of known source and qualities. Controlling how a FOSS project trademark is used protects the community and its software, by preventing use of the trademark in ways that are harmful to the reputation of the community or the software.
Linux is a registered trademark of Linus Torvalds[1]. GNU is a registered trademark of the FSF[2]. Your definition of "proprietary" isn't shared by virtually anyone, and would make virtually everything "faux open source", including the "open source os" project you originally worried about Go being integrated into.
[0] https://static.fsf.org/nosvn/licensing/2020/FOSSmarksv2.pdf
[1] https://tsdr.uspto.gov/#caseNumber=74560867&caseSearchType=U...
[2] https://tsdr.uspto.gov/#caseNumber=85380218&caseSearchType=U...