Kernel+Userland: Introduce containers

[supercomputer7]

This is the thing I worked on for the last 2 weeks - containers, which consist of combining 4 main features:

• Jail restrictions
• PID isolation in Process lists
• VFS root contexts
• Hostname contexts

The concept of VFS root context is very similar to the Linux mount namespace idea. I still have to write all the reasoning behind what I do, so this is a draft, for now.
In the next couple of days I will try to land the last commits of bringing it all up with a new shiny userspace utility called runc (for "run container").

Please note that although this is not finished yet, there are many good bits in the PR which will benefit the system in so many ways, and because I use them as foundations for the end goal, I rather keep them in this PR.

[supercomputer7]

Now this is mostly done in terms of finishing the design, I still need to fix CI and ensure proper commit messages are in place.

As for future development, we should aim for adding sysfs nodes for unshared resources. This will probably require us to also keep a list of attached process to a resource (like with the ScopedProcessList class) if we want to do something meaningful.
In addition to that, I searched on how we could access VFS root context filesystem view, and this serverfault question has some interesting answers.

Adding more features is of course possible. I thought about adding a way to set a limit on how many processes can be created within a ScopedProcessList, to help ensuring fork-bombs can't actually spawn limitless amount of processes. A special prctl option can be defined to set this limit (and if the process isn't attached to a scoped process list, we could return ESRCNOTFOUND).

[supercomputer7]

More ideas that came to my mind:

• Adding separation to SlavePTY devices so we can mount devpts filesystems within a container, and based on the VFS root context (which could hold a list instead of the global list), the processes can share a new set of devices contained in their own filesystem instance in such VFS root context.
• Instantiate separation for other devices so maybe attach each device to certain VFS root context so it could be opened only within the same VFS root context. If you open a device node before moving to other VFS root context, then you keep that device node being opened in a file descriptor. This will allow creating device nodes without the fear of processes trying to open them to bypass the container isolation (so you can't open the main disk device node and read from it).
  This also means that we could basically use access tokens for devices across multiple contexts as well, so it means that each re-presentable device has its own major and minor numbers which are of course shared across the multiple contexts (and are unique for the whole OS, but not for each context), and only if you have access to them through your context (which should be given by a special syscall), then you can actually open the device. Ofc, once you have a device being opened in the context, there's no meaning to allow revoking access so there'll be no syscall to do so.

[supercomputer7]

Another clever idea - we could take leverage of the VFS root context idea to implement lazily-unmount feature - essentially we can allow the user to ask the kernel to move the filesystem out of its context, attaching it to the kernel VFS root context which is not visible for userspace, and then add some kernel process worker that will clean it up once the last references to the filesystem inodes are cleaned.

[supercomputer7]

This is blocked until #23138 is merged, since I plan on expanding on loop devices for containers as well.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

[OfficialPixelBrush]

Any updates on this front?

[supercomputer7]

Any updates on this front?

Not yet. PR #23814 should be merged first so containers could be used efficiently - currently it takes hot 2-3 seconds to fire-up a fully functional BuggieBox based container, so we should aim to build container images and use them with loop devices.

[supercomputer7]

Let's make this a non-draft PR, as loop devices will take some time (I found that I need to do more fixes there to make it usable, so it will wait).
This PR is not perfect, but it gives a reasonable structure to what I want containers to look alike, so let's try to merge this as-is.
It takes hot 2-3 seconds to fire-up a full-fledged BuggieBox container, but it works correctly - complete filesystem isolation, together with process isolation, gives the impression that the general idea of this PR is doing a thing in the right direction. We should aim at keeping everything simple as possible, including the configuration of the actual containers.
Putting more complicated applications, like the Browser, in a containerized environment, is ofc another goal. but we need to ensure that creating containers could be done almost instantly beforehand.

[supercomputer7]

This should be ready for review again :)

[timschumi]

Let's get this conflict magnet out of the way.