Re: Jailed sysvipc implementation.

From: Max Khon (fjoe_at_iclub.nsu.ru)
Date: 06/26/03

  • Next message: Julian Elischer: "Re: Jailed sysvipc implementation." 
    Date: Thu, 26 Jun 2003 06:20:45 +0700
To: Dmitry Sivachenko <demon@freebsd.org>

    hi, there!

    On Wed, Jun 25, 2003 at 06:52:33PM +0400, Dmitry Sivachenko wrote:

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

    btw I know of two projects whose goal is IP stack virtualization for jail.
    Virtual IP stack (as well as virtualized sysvipc with separate
    memory zones) can be quite useful. Can provide two solutions?

    - with shared memory zone (for those who want "light" version)
    - with separate memory zones (for people who want to keep
    sysvipc fully separated, i.e. one user can't exhaust all sysvipc resources
    and make sysvipc unusable for second user)

    /fjoe

    _______________________________________________
    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: Julian Elischer: "Re: Jailed sysvipc implementation."

    Relevant Pages

    • Re: Shorter/better way to do this?
      ... And, finally, you could have a stack of growing/shrinking arrays in ... You would keep on a separate ... stack and the allocated bytes in some other memory area. ...
      (comp.lang.forth)
    • Re: RfD: Separate FP Stack
      ... And Forth Inc.'s product for Harris' RTX used a single stack so besides ... So putting FP on that stack was faster than in main memory ... Separate stacks would have negated ... Sure and machines with very small hardware stacks would not ...
      (comp.lang.forth)
    • Re: If Macs have no spyware....
      ... >had made a complete code review of its operating system and removed all ... and writing new data into those memory locations would ... >but when the data exists on the stack, it can cause very large problems. ... >location that needs to be written in place of the correct execution ...
      (comp.sys.mac.advocacy)
    • Re: If Macs have no spyware....
      ... First you yammer about being a Mac advocate, then bad mouth me for dumping XP in favor of a Mac. ... Supposedly Microsoft had made a complete code review of its operating system and removed all the buffers which could overflow. ... the fundamental problem is that the basic architecture of Windows has two fatal flaws in its memory management and while these remain in the software the ad hoc patches will never be enough to make Windows a secure operating system. ... These problems are bad enough when dealing with data in the one routine but when the data exists on the stack, it can cause very large problems. ...
      (comp.sys.mac.advocacy)
    • Re: Maybe we should stop "Paging Beth Stone" already...
      ... I'll want to work on my OS while running my OS, so the assembler that it's written with has to run under it. ... You have to swap CR3 if you want seperate memory spaces. ... The alternate stacks aren't used by the processor unless the task calls a different protection level, so they're not part of the TSS swap. ... This lets any application use up to a gigabyte of stack before Linux is forced to tell it that it's gone too far. ...
      (alt.lang.asm)