Re: Jailed sysvipc implementation.
Next message: Pawel Jakub Dawidek: "Re: Jailed sysvipc implementation."
Date: Wed, 25 Jun 2003 19:21:19 +0400
To: Pawel Jakub Dawidek <nick@garage.freebsd.pl>
On Wed, Jun 25, 2003 at 05:02:21PM +0200, Pawel Jakub Dawidek wrote:
> On Wed, Jun 25, 2003 at 06:52:33PM +0400, Dmitry Sivachenko wrote:
> +> > But you got still *one* memory zones for every jail and main host.
> +>
> +> Yes, that is exactly what I want.
> +> This is similar to separate IP stack for each jail: this is more powerful
> +> solution, but more expensive (uses more kernel memory).
>
> But note that my implementation allocates memory "on demand".
This is part of the problem: with single memory zone for all jails,
less memory is allocated. With private memory zones, if m jails use IPC,
you need to allocate m*M kbytes (for some value of M you consider
sufficient for one jail).
With one memory zone for all jails, it is enough to allocate N kbytes where
M < N < m*M, because every jail will not use all M kbytes at the same time.
> If IPC syscall will not be used inside of jail memory will not be allocated.
> If think also that this will be trivial to add value to jail struct
> that will thell if we want separate IPC memory zones for this jail or not.
>
> +> Jail is not a true virtual machine.
> +> Let's keep it a *light* virtual machine replacement, with single IP stack,
> +> one memory zones for all jails and host, etc.
>
> I think it should be and it isn't now because of implementaion problems.
> Am I wrong? Poul? Robert?
>
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Next message: Pawel Jakub Dawidek: "Re: Jailed sysvipc implementation."
Relevant Pages
- Re: new feature: private IPC for every jail
... Do we go out and create new name spaces for jails already started, because it implies System V IPC will have pretty intimate knowledge of jails, and know how to walk lists, etc), do we deny access to System V IPC for jails not present when it was loaded? ... but why does a namespace need to be created prior to a process in the jail needing it? ... In principle, it can be done any time, but there are some nice simplifying assumptions about doing it up-front: among these is that the point of jail creation is very useful from a security perspective because you're not running contained code at that point, only code that's sufficiently privileged to perform the jail creation operation, and that you can avoid extra synchronization of the name space reference to make sure it's acessed and allocated with reasonable atomicity. ... It should be possible to allocate on demand, although there could be catches I haven't thought of by virtue of not trying it. ...
(freebsd-stable) - Re: new feature: private IPC for every jail
... Do we go out and create new name spaces for jails already started, because it implies System V IPC will have pretty intimate knowledge of jails, and know how to walk lists, etc), do we deny access to System V IPC for jails not present when it was loaded? ... but why does a namespace need to be created prior to a process in the jail needing it? ... In principle, it can be done any time, but there are some nice simplifying assumptions about doing it up-front: among these is that the point of jail creation is very useful from a security perspective because you're not running contained code at that point, only code that's sufficiently privileged to perform the jail creation operation, and that you can avoid extra synchronization of the name space reference to make sure it's acessed and allocated with reasonable atomicity. ... It should be possible to allocate on demand, although there could be catches I haven't thought of by virtue of not trying it. ...
(freebsd-current) - Re: new feature: private IPC for every jail
... What happens now, if I load ipc, start up postgresql and then try to unload ipc? ... There are two general ways to approach adding virtualization to the System V IPC name spaces: ... Key virtualization to the identity of the jail. ... This is a nice piece of behavior, as it means file system subsetting is a facility available to be used regardless of the use of jail, and avoids hard-coding jail instrumentation throughout the file system code. ...
(freebsd-current) - Re: new feature: private IPC for every jail
... What happens now, if I load ipc, start up postgresql and then try to unload ipc? ... There are two general ways to approach adding virtualization to the System V IPC name spaces: ... Key virtualization to the identity of the jail. ... This is a nice piece of behavior, as it means file system subsetting is a facility available to be used regardless of the use of jail, and avoids hard-coding jail instrumentation throughout the file system code. ...
(freebsd-stable) - Re: [HACKERS] semaphore usage "port based"?
... We don't use ftok() to determine the keys, and I'm disinclined to think that doing so would improve the situation: you could still have key collisions, they'd just be unpredictable and there'd be no convenient mechanism for escaping one if you hit it. ... We specifically disable System V IPC in jails because it is known to have undesirable properties. ... When configuring systems in that state, the responsibility falls on the administrator to disambiguate the configuration by specifying which resources must be used in order to prevent a conflict, because software operating in that environment will not be able to do so properly. ... The goal of the switch to enable System V IPC is to allow IPC to be enabled for a single jail at a time, where it can be used to its full capabilities, without violating the security model. ...
(freebsd-stable) |
|
