Re: Jailed sysvipc implementation.

From: Pawel Jakub Dawidek (nick_at_garage.freebsd.pl)
Date: 06/25/03

  • Next message: Dmitry Sivachenko: "Re: Jailed sysvipc implementation."
    Date: Wed, 25 Jun 2003 14:25:39 +0200
    To: Max Khon <fjoe@iclub.nsu.ru>
    
    
    

    On Wed, Jun 25, 2003 at 06:21:30PM +0700, Max Khon wrote:
    +> > Some time ago I've implemented private memory zones for IPC mechism.
    +> > Every jail and main host got its own memory for IPC operations.
    +> > It was implemented for FreeBSD 4.x. Avaliable at:
    +> >
    +> > http://garage.freebsd.pl/privipc.tbz
    +> > http://garage.freebsd.pl/privipc.README
    +> >
    +> > I want to port this to FreeBSD 5.x, but with many improvements.
    +> > Because of that there are few things to talk about and I'm curious if
    +> > anyone will be interested in answering my questions and at the end
    +> > commiting this to -CURRENT.
    +> >
    +> > Patch will not be a "fast hack" so the best way will be commiting this
    +> > in parts. I got already working sysvipv_msg mechanism.
    +> >
    +> > So if anyone is interested in, please inform me and I'll ask my
    +> > questions and I'll send also what I got now.
    +>
    +> I'm interested in reviewing and committing this stuff

    Thanks.

    So first of all, I implemented something like allocate-on-demand.
    Memory zones are allocated only if IPC syscall will be called
    from inside of jail. This is the best way, I think, because:
    1. We don't allocate memory if this isn't needed.
    2. We don't have to fight with locking prisons list when loading
       IPC as kld module (allocating memory when lock is holded, ehh).

    I'm also proposing to create mirror of those values:

            security.jail.ipc.msgmax
            security.jail.ipc.msgmni
            security.jail.ipc.msgmnb
            security.jail.ipc.msgtql
            security.jail.ipc.msgssz
            security.jail.ipc.msgseg

    They will be always read-write and used to calculate memory that
    will be allocated for newly created jails.

    Is everything what I'm saying sounds reasonable I'll send patch
    for sysvipc_msg.

    -- 
    Pawel Jakub Dawidek                       pawel@dawidek.net
    UNIX Systems Programmer/Administrator     http://garage.freebsd.pl
    Am I Evil? Yes, I Am!                     http://cerber.sourceforge.net
    
    


    • application/pgp-signature attachment: stored

  • Next message: Dmitry Sivachenko: "Re: Jailed sysvipc implementation."

    Relevant Pages

    • Re: Jailed sysvipc implementation.
      ... > Some time ago I've implemented private memory zones for IPC mechism. ... > Every jail and main host got its own memory for IPC operations. ...
      (freebsd-arch)
    • Re: Shared Memory for Application/Communication decoupling
      ... different IPC methods within a single task will introduce a lot of ... memory techniques are just a nice way of saying 'global data'. ... A messaging based interface is generally more elegant and arguably more ...
      (comp.arch.embedded)
    • FreeBSD 4.9 goes boom!
      ... FreeBSD 4.9 load average quickly goes to high levels such as 300. ... System becomes unusable and HOPEFULLY reboots. ... avail memory = 257400832 ... jail 8 - a ssh jail for people to manage the sites ...
      (freebsd-questions)
    • Re: memory locking in a jail?
      ... it has to do with memory locking ... ... > that can't be done inside of a jail? ... privilege check does not allow mlockto be used in a jail. ...
      (freebsd-stable)
    • Re: WriteProcessMemory
      ... WriteProcessMemory was designed to be used for debugging not ... IPC, and using it as an IPC mechanism is a bit unusual to say the ... The next closest thing are memory ...
      (microsoft.public.platformsdk.security)