Initial vps (virtual process space) framework for jails.
Needs ReviewPublic
Actions

Authored by bz on May 24 2018, 4:45 PM.

Details

Reviewers

jamie
zec

Summary

Add the vps (virtual process space) framework for jails.
This is going to give a jail its own process space (own pids, ..).

For now add an #ifdef around various parts in kern_jail.c so that
it cannot accidentally be invoked possibly leading to a system
shutdown on jail removal.

This work is heavily derived from the "vnet" implementation.

Diff Detail

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 16813
Build 16696: arc lint + arc unit

Event Timeline

bz created this revision.May 24 2018, 4:45 PM

Herald added a subscriber: ae. · View Herald TranscriptMay 24 2018, 4:45 PM

Harbormaster completed remote builds in B16813: Diff 42936.May 24 2018, 4:45 PM

kbowling added a subscriber: kbowling.May 24 2018, 4:50 PM

I have already committed the noise to HEAD. Seems the git export was too slow to pick it up and merge it out.

sys/kern/kern_jail.c
2759	This is in HEAD already; ignore.
3650	This line is in HEAD already as well; ignore.

Update the static asserts to match again.
Merge branch 'master' into p0

Harbormaster completed remote builds in B16816: Diff 42941.May 24 2018, 5:37 PM

What does this buy us? What I can come up with is:

1: Virtual init. This is a long-standing need and would make jails run much smoother. I used to do something similar at Verio, but that never made it into FreeBSD. Is that complete here? I see a comment that mentions a need to do something in reboot(2), but no chages to reboot(2) itself (or did I miss that?).

2: Security in the process space. I'm not sure this is a need, since I think we already hide the existence of out-of-jail processes (i.e. not just EPERM but ESRCH).

3: Prevent pid exhaustion for many-jail systems. Is this a problem?

My best guess is the reasoning is mostly about virtual init. But perhaps there's something else that I'm missing? Since it comes at a cost of no longer being able to attach to a jail, it has to be something worth that hurdle.

jamie added inline comments.May 24 2018, 7:18 PM

sys/kern/kern_jail.c
2419	This takes out jail_attach(2), but not the JAIL_ATTACH flag to jail_set(2). Presumably, if we don't want to attach via one method we also don't want to via the other. That implies that VPS jails will always need "persist" set. But we should probably relax that to allow for VPS jails that go away when their last process (init) dies in a virtual shutdown.

In D15556#328503, @jamie wrote:

What does this buy us? What I can come up with is:

Hi @jamie

1: Virtual init. This is a long-standing need and would make jails run much smoother. I used to do something similar at Verio, but that never made it into FreeBSD. Is that complete here? I see a comment that mentions a need to do something in reboot(2), but no chages to reboot(2) itself (or did I miss that?).

No, this is only the jail/vps framework; there will be more follow-up changes coming but breaking them down will make it easier to review. Yes, I have init inside jails.

2: Security in the process space. I'm not sure this is a need, since I think we already hide the existence of out-of-jail processes (i.e. not just EPERM but ESRCH).

3: Prevent pid exhaustion for many-jail systems. Is this a problem?

My best guess is the reasoning is mostly about virtual init. But perhaps there's something else that I'm missing? Since it comes at a cost of no longer being able to attach to a jail, it has to be something worth that hurdle.

Initially virtual init and separate process space.

Then eventually own VM space bits.

Lastly migration of jails between machines as the original VPS work did, which I have been updating the last months; so this is basically a first step in migrating that work to the jail management interface.

There's still plenty of fish to fry in that area; even the virtual process space shutdown has shown various invariants not to be true in other places; it's the "vnet shutdown" story again getting all the resources and references sorted properly.

I also think kern_jail.c indeed might need your suggested cleanup and reduction to single interfaces finally breaking lose of the v1/v2 things after 3 major versions; I didn't see any "burn bridges" in the code yet. Maybe I should move this part of the conversation to email ;-)

bz mentioned this in D15570: Virtualization of basic variables and locks for jail+vps..May 25 2018, 11:06 AM

bz added a child revision: D15570: Virtualization of basic variables and locks for jail+vps..

Prevent attaching to a jail both from jail_attach() and from
jaiL_set() by moving the check into the first thing of
do_jail_attach().

Pointed out by:         jamie
Sponsored by:           iXsystems, Inc.

Harbormaster completed remote builds in B17409: Diff 44007.Jun 18 2018, 3:20 PM

Moved the VPS check for attach into do_jail_attach()

freqlabs added a subscriber: freqlabs.Jun 22 2018, 6:13 PM