[lkml]   [2004]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] pid randomness
    On Mon, 27 Dec 2004 19:39:01 GMT, "Pedro Venda (SYSADM)" said:

    > I don't know if this has been discussed before... but I'd like to ask
    > why isn't the pids randomized by default?

    It's a pretty easy thing to do, actually. There's a patch for that
    in Grsecurity, and I did one up myself a while ago...

    One big problem that remains beyond my technical skill to fix - for the
    32 bit machines, there's some funkiness in the /proc filesystem code
    where it invents inode numbers based in the process ID that restrict the
    effective value of max_pid to 64K. Unfortunately, if you're in the camp that
    believes that randomizing the PID is useful at *all*, you probably want a
    bigger space for the random number. So you can either fix that issue (and
    whatever *OTHER* issues lurk after that one) or only deploy on 64 bit boxen...

    A secondary issue that I've never been able to test is whether over time,
    a "randomized" PID ends up sparsely dirtying the list of pidmap pages (so
    you have enough pages to hold 4M PID bits, but only 1 or 2 bits per page
    are actually set), or do the occasional long-lived processes end up essentially
    leaving at least one process on each page anyhow? Any operational experience
    on that one from the big-system guys?

    At worst, 4M pids will take 128 4K pages (or equivalent for other page sizes) -
    is that considered "unacceptable" on 64-bit boxes that want to do this?

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-03-22 14:09    [W:0.042 / U:37.460 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site