Processes and mmap - openssh

This is a discussion on Processes and mmap - openssh ; Hello, For a key exchange algorithm I'm working on, I would like to keep a little bit of shared state between the main server process and the processes that clients connect to. So far, I'm considering mmap for the purpose. ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Processes and mmap

  1. Processes and mmap

    Hello,

    For a key exchange algorithm I'm working on, I would like to keep a little bit
    of shared state between the main server process and the processes that
    clients connect to. So far, I'm considering mmap for the purpose.

    But I cannot figure out where I need to put the mmap initialization call,
    where it would be called at server startup (before any fork()s/exec()s), and
    never again.

    Could someone please briefly explain how OpenSSH manages its various
    processes - such as when processes are created and where in the code that
    happens?

    Thanks in advance!

    Georgi

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBIanqoMFAGrRS91BsRAp9/AKChnhFcjEZIin1V9Ol7kBCJXf8jdwCfZv2A
    rlOx2RknfUW3rAG6pUNmBAE=
    =0tTq
    -----END PGP SIGNATURE-----


  2. Re: Processes and mmap

    Georgi Chulkov wrote:
    > Hello,
    >
    > For a key exchange algorithm I'm working on, I would like to keep a little bit
    > of shared state between the main server process and the processes that
    > clients connect to. So far, I'm considering mmap for the purpose.
    >
    > But I cannot figure out where I need to put the mmap initialization call,
    > where it would be called at server startup (before any fork()s/exec()s), and
    > never again.
    >
    > Could someone please briefly explain how OpenSSH manages its various
    > processes - such as when processes are created and where in the code that
    > happens?


    Try Neils Provos' paper on privsep:
    http://www.citi.umich.edu/u/provos/ssh/privsep.html

    If you still have questions after reading that, then please feel free to
    ask here.

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  3. Re: Processes and mmap

    > Try Neils Provos' paper on privsep:
    > http://www.citi.umich.edu/u/provos/ssh/privsep.html
    >
    > If you still have questions after reading that, then please feel free to
    > ask here.


    Thanks for the reference, that was a very good read. Unfortunately I cannot
    quite understand the paragraph that stars at the end of page 4 ("Figure 3
    shows an overview..."). In particular, I do not understand:

    1) Why is the shared address space "back" necessary?
    2) What does mm_share_sync do?
    3) What is the difference between mm using libc's malloc, as opposed to mm
    using back which itself uses libc's malloc?

    I will now try to figure out the source code that implements privilage
    separation, and I will post any other questions I might have.

    Thanks!

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (GNU/Linux)

    iEYEABECAAYFAkhtS4IACgkQMFAGrRS91Bu+JACfVYy25Q+7ia yzn0jHsMvmlA1T
    r5QAn2LSTLu46FGWCN3IEN76XuBDItKz
    =qw2r
    -----END PGP SIGNATURE-----


  4. Re: Processes and mmap

    Georgi Chulkov wrote:
    >> Try Neils Provos' paper on privsep:
    >> http://www.citi.umich.edu/u/provos/ssh/privsep.html
    >>
    >> If you still have questions after reading that, then please feel free to
    >> ask here.

    >
    > Thanks for the reference, that was a very good read. Unfortunately I cannot
    > quite understand the paragraph that stars at the end of page 4 ("Figure 3
    > shows an overview..."). In particular, I do not understand:
    >
    > 1) Why is the shared address space "back" necessary?


    For handling things like the zlib compression state. This state
    includes things like compression dictionaries that are needed to
    decompress the data from the client, and their content changes over time.

    Since zlib compression can be negotiated before the connection is
    authenticated, it means that the compression state has to be available
    to both the preauth and post-auth privsep slaves.

    > 2) What does mm_share_sync do?


    The shared memory allocator keeps accounting records of its allocations.
    For the most part these are held in normal dynamically allocated memory.

    When the first privsep process exits, it copies these accounting records
    to the shared memory area in a format that the new (post-auth) privsep
    process can unpack and use to continue managing the shared memory area.

    > 3) What is the difference between mm using libc's malloc, as opposed to mm
    > using back which itself uses libc's malloc?


    I'm not sure I follow this question. If you allocate memory from "back"
    the memory you allocated is in the shared memory area. The information
    about the allocation (the metadata) is in non-shared memory, and this
    metadata is what is copied by mm_share_sync.

    > I will now try to figure out the source code that implements privilage
    > separation, and I will post any other questions I might have.


    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  5. Re: Processes and mmap

    > > 1) Why is the shared address space "back" necessary?
    >
    > For handling things like the zlib compression state. This state
    > includes things like compression dictionaries that are needed to
    > decompress the data from the client, and their content changes over time.
    >
    > Since zlib compression can be negotiated before the connection is
    > authenticated, it means that the compression state has to be available
    > to both the preauth and post-auth privsep slaves.


    I understand that there are things that need to remain between the slaves. I
    do not understand why mm is not sufficient by itself.

    > > 2) What does mm_share_sync do?

    >
    > The shared memory allocator keeps accounting records of its allocations.
    > For the most part these are held in normal dynamically allocated memory.
    >
    > When the first privsep process exits, it copies these accounting records
    > to the shared memory area in a format that the new (post-auth) privsep
    > process can unpack and use to continue managing the shared memory area.


    I'm sorry, I still don't get it. So shared memory is kept in mm. mm itself was
    created by the monitor process, so nothing in there goes away when the first
    privsep slave exits. Why can't the monitor just pass mm back to the second
    slave?

    Also, if mm_share_sync copies shared memory allocator metadata, where does it
    copy it to?

    > > 3) What is the difference between mm using libc's malloc, as opposed to
    > > mm using back which itself uses libc's malloc?

    >
    > I'm not sure I follow this question. If you allocate memory from "back"
    > the memory you allocated is in the shared memory area. The information
    > about the allocation (the metadata) is in non-shared memory, and this
    > metadata is what is copied by mm_share_sync.


    This question directly addresses the paragraph I pointed to in my last e-mail.
    You say "If you allocate memory from 'back' the memory you allocated is in
    the shared memory area." Is this not true of 'mm' too?

    To paraphrase my question, why do we use mm_share_sync to save back's metadata
    (which holds mm's metadata), as opposed to using mm_share_sync to save mm's
    metadata directly and not having back at all?

    Thanks again.

    Georgi

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (GNU/Linux)

    iEYEABECAAYFAkhtWmoACgkQMFAGrRS91BulgACbBZZAE+zk2V/bVOAhie77M+3D
    Yf8Ani4Qg/zNrmuyNSHJ6F6tT408nb8R
    =Zlyz
    -----END PGP SIGNATURE-----


  6. Re: Processes and mmap

    Hello again,

    I have noticed that when a connection is made to the main sshd process, it
    first forks, and then execv()s itself, thur restarting itself completely.
    What is the reason for the execv()?

    My other concern is that I would like to have some global state inherited from
    the main sshd process to all forked processes, which is however sensitive
    data. Is it safe to pass it as a command-line argument during the execv()
    call?

    Thanks.

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (GNU/Linux)

    iEYEABECAAYFAkhtbiwACgkQMFAGrRS91BvpygCgq85Ftp5vDr De+f6N5g14D5GU
    FWwAoKhAQ0+FmEJWZs1dSw0KB/1PQq5c
    =82/2
    -----END PGP SIGNATURE-----


  7. Re: Processes and mmap

    Georgi Chulkov wrote:
    > Hello again,
    >
    > I have noticed that when a connection is made to the main sshd process, it
    > first forks, and then execv()s itself, thur restarting itself completely.
    > What is the reason for the execv()?


    Some security measures, in particular address space layout
    randomization, are only applied at exec time. Doing this means that
    each connection gets a unique layout rather than a clone of the original
    sshd. See:

    http://www.openbsd.org/papers/openss...bsdcon2007.pdf
    http://www.openbsd.org/papers/ven05-deraadt/index.html

    > My other concern is that I would like to have some global state inherited from
    > the main sshd process to all forked processes, which is however sensitive
    > data. Is it safe to pass it as a command-line argument during the execv()
    > call?


    No, command line arguments are visible to all users on many systems.
    See sshd.c:send_rexec_state() for how sshd sends some state to the new
    copy (via a pipe).

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


+ Reply to Thread