Page MenuHomeFreeBSD

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

Authored by bz on May 24 2018, 4:45 PM.
Tags
None
Referenced Files
F80211118: D15556.diff
Fri, Mar 29, 6:57 AM
Unknown Object (File)
Tue, Mar 19, 10:27 AM
Unknown Object (File)
Feb 14 2024, 5:24 AM
Unknown Object (File)
Jan 28 2024, 7:18 PM
Unknown Object (File)
Jan 28 2024, 4:14 PM
Unknown Object (File)
Dec 20 2023, 6:20 AM
Unknown Object (File)
Dec 11 2023, 9:24 PM
Unknown Object (File)
Dec 8 2023, 5:51 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.

Sponsored by: iXsystems, Inc.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 17949
Build 17704: arc lint + arc unit

Event Timeline

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

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.

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.

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 ;-)

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.
bz marked an inline comment as done.Jun 18 2018, 3:21 PM

Moved the VPS check for attach into do_jail_attach()

Update to more recent head.