This was super educational. I just learned about OpenBSD's system-call-origin verification this week, so I was super excited to see you adding it to Serenity too!
I heard about the syscall origin in OpenBSD in a thread about Go on HN a few days ago where they talked about how Go has been doing syscalls directly on many platforms, but starting with version 1.16 of Go on OpenBSD, Go will go through libc in order to ensure forward compatibility with OpenBSD. The timing of this makes me think maybe you also read that thread Andreas 😊 Very nice to see this video about the implementation of such feature into SerenityOS 👌🏻
This is weird and goes against certain unix principles that are that libc is just a detail of the separation between userland and the kernel. For instance in this environment it would be impossible for an unpriv'd (or any?) user to develop there own libc, or write user programs just in assembler etc. I GET the security advantages but this is unpleasant. Some practical questions: what about fully statically linked binaries? What about chroots?
It's somewhat opt-in, at least for programs not using the system linker. If you provide your own libc with the system linker, it can make whatever syscalls it likes, too. Statically linked programs have to ask for this feature to get it. So much like the pledge system, it's a program opting into some extra memory corruption defenses.
Hey Andreas, I accidentally deleted my original comment. I obviously know that syscalls are necessary to switch from user-mode to kernel-mode, but that isn't really the point. The question was really about why you would force users to use the LibC syscall wrappers and why you would disallow them from making the syscalls themselves. What if a different language uses a different calling convention than C, for example? Why would you rather have that language implement the C calling convention, than implement the syscall "calling conention"?
For the reasons discussed in the video. Furthermore, there is no need to support direct syscalls on SerenityOS as there is no stable ABI anyway. Anyone building software for it should target the API, not the ABI.
Since Serenity has ASLR now, would it be possible for libc/libpthread to be randomly assigned to base address 0, causing msystemcall(nullptr) to be called prematurely?
@@awesomekling Only because of things like this. Why should libc have such a privileged position? If libc is being de-facto treated as the syscall interface, what benefit would knowing the syscall came from libc even provide? All this does is make C more difficult to replace. Is the goal here to ensure that C's misfeatures such as memory leaks can still occur?
I'm addicted to these videos
same
Same
This was super educational. I just learned about OpenBSD's system-call-origin verification this week, so I was super excited to see you adding it to Serenity too!
I heard about the syscall origin in OpenBSD in a thread about Go on HN a few days ago where they talked about how Go has been doing syscalls directly on many platforms, but starting with version 1.16 of Go on OpenBSD, Go will go through libc in order to ensure forward compatibility with OpenBSD. The timing of this makes me think maybe you also read that thread Andreas 😊 Very nice to see this video about the implementation of such feature into SerenityOS 👌🏻
I did see that thread, which got me interested in the technique! :)
This one was very interesting.
Also it's impressive how you remember almost everything about OS 😅
This is weird and goes against certain unix principles that are that libc is just a detail of the separation between userland and the kernel. For instance in this environment it would be impossible for an unpriv'd (or any?) user to develop there own libc, or write user programs just in assembler etc. I GET the security advantages but this is unpleasant. Some practical questions: what about fully statically linked binaries? What about chroots?
It's somewhat opt-in, at least for programs not using the system linker. If you provide your own libc with the system linker, it can make whatever syscalls it likes, too. Statically linked programs have to ask for this feature to get it. So much like the pledge system, it's a program opting into some extra memory corruption defenses.
Hey Andreas, I accidentally deleted my original comment. I obviously know that syscalls are necessary to switch from user-mode to kernel-mode, but that isn't really the point. The question was really about why you would force users to use the LibC syscall wrappers and why you would disallow them from making the syscalls themselves. What if a different language uses a different calling convention than C, for example? Why would you rather have that language implement the C calling convention, than implement the syscall "calling conention"?
For the reasons discussed in the video. Furthermore, there is no need to support direct syscalls on SerenityOS as there is no stable ABI anyway. Anyone building software for it should target the API, not the ABI.
@@awesomekling Makes sense, thanks :)
Since Serenity has ASLR now, would it be possible for libc/libpthread to be randomly assigned to base address 0, causing msystemcall(nullptr) to be called prematurely?
ASLR will never place something at 0, that’s outside of the allowed addresses range :)
What about other language runtimes? Not everything uses libc, for example Go's runtime
The next version of Go will support calling through libc: utcc.utoronto.ca/~cks/space/blog/programming/Go116OpenBSDUsesLibc
@@awesomekling Only because of things like this. Why should libc have such a privileged position? If libc is being de-facto treated as the syscall interface, what benefit would knowing the syscall came from libc even provide? All this does is make C more difficult to replace. Is the goal here to ensure that C's misfeatures such as memory leaks can still occur?
I'm not interested in bad faith arguments.
@@awesomekling I also had read that article (and the one it linked to) just before watching your video :)
A few of your recent videos have been touching the Region class. Is a Region in Serenity synonymous with an Arena in glibc malloc?
Region in Serenity is roughly the same as VMA (Virtual Memory Area) in the Linux kernel. It’s a kernel space thing, lower level than malloc :)
oh didn't know you could say "à la" in English
Aren’t loan words fun?
@@NoTraceOfSense lol they really are
as a French speaker it's like so funny to hear things like fiancé, touché, raison d'être etc in English
came from liveoverflow
Welcome, friends of LiveOverflow :)
You should probably add a exceptionlist like "/etc/regions", so that other people can easily add other objects and regions to the list :^)
The list of exceptions should only shrink, not grow :) I've already removed the libkeyboard.so exception.
If the list of exceptions grows then you have bad rule in the first place.