lkml.org 
[lkml]   [2000]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Endless overcommit memory thread.
    Grendel wrote:

    > > If you allow overcommit, you can have *either* the SEGFAULT behavior
    > > *or* the no-mem/locked out (process touches everything up front). If you
    > > disallow overcommit, you reduce the possible behaviors to 1. The problem is
    > > that suppose the process allocates it's memory -- with the 'overcommit'
    > > you have a system where it is hard to predict *what* will fail. Will it be
    > > a system process? A deamon? It's a low-integrity system because you can't
    > > figure out the behavior of failure in advance.
    > And what if the processes are prioritized in respect of memory?
    ---
    So...scenario...suppose we have a Compartmented Mode Computer that
    enforces Mandatory Access. Users who log in don't know about each other and
    users at different clearance levels can't access the data of those above
    them. The sysadmin may administer's data but isn't rated to read or know
    about processes own by those with higher sensitivity levels. How can
    anyone -- the sysadmin know that the President was logged in writing his
    latest top-secret whatchamajigger. Now mr. President doesn't know about
    memory, but tries to read into an edit buffer a very large and secret file.
    The viewer allocs
    alot of space to hold the document in memory -- and it triggers *the memory
    killer*. "Prez" ain't running as SYSADMIN, he hasn't been running long, has
    low CPU value...is maybe the largest process on the system. Bang -- real
    good candidate for being an evil memory hog targeted for termination by
    the auto-killer. Um...gee, sorry mr. prez. But lets say in reading his
    large file, the "reader" program is smart enough to know..."hmmm, I got
    a NULL pointer from that malloc, maybe I'll page the rest of the file in
    from disk later". ...

    The point is you don't necessarily to hard code in memory "policy"
    that kills processes. Optional option? Maybe yes... But default behavior?
    Yuck. If we want Linux to become a "most trusted OS", having the kernel
    automatically take non-requested actions on user-programs isn't a great idea.

    -l

    --
    Linda A Walsh | Trust Technology, Core Linux, SGI
    law@sgi.com | Voice: (650) 933-5338

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:57    [W:4.901 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site