Re: Kernel support for peer-to-peer protection models...

From: Ivan Godard (igodard_at_pacbell.net)
Date: 03/29/04

  • Next message: Claudio Martins: "Re: usage of RealTek 8169 crashes my Linux system"
    To: "Andi Kleen" <ak@suse.de>
    Date:	Mon, 29 Mar 2004 00:09:22 -0800
    
    

    interlinear

    ----- Original Message -----
    From: "Andi Kleen" <ak@suse.de>
    To: "Ivan Godard" <igodard@pacbell.net>
    Cc: <linux-kernel@vger.kernel.org>
    Sent: Sunday, March 28, 2004 3:14 PM
    Subject: Re: Kernel support for peer-to-peer protection models...

    > On Sun, 28 Mar 2004 12:21:36 -0800
    > "Ivan Godard" <igodard@pacbell.net> wrote:
    >
    > >
    > > > Maybe you can give each process an different address range, but AFAIK
    > > > the only people who have done this before are users of non MMU
    > > architectures.
    > > > It will probably require som changes in the portable part of the code.
    > > > Also porting glibc's ld.so to this will be likely no-fun.
    > >
    > > Each process gets a different range because each process gets a
    different
    > > native space. Within that space processes can use the same offsets, and
    > > typically will so as to avoid pointless relocation.
    >
    > fork() will be hard and/or inefficient this way.

    Why? The load image for the new process does not require relocation, so all
    that's necessary to spawn a process is to allocate a spaceID, map the
    excutable to that ID in the page tables, push one entry into the TLB, set a
    couple of hardware registers, and insert it into the readyq. When it get's
    control it will prompty fault in its code pages (if not already present),
    and execution from there on is normal. This process is essentially identical
    to what happens on a conventional, except because there is no aliasing of
    addreses (flat unified 64-bit model) you don't have to scrub the cache or
    TLB.

    > > > Overall it sounds like your architecture is not very well suited to
    > > > run Linux.
    > >
    > > We believe we can adopt the Linux protection model (i.e. the 386
    protection
    > > model) with no more work than any other port to a new architectire
    (ahem).
    >
    > Just FYI - Linux has been ported to several architectures with similar
    SASOS
    > capabilities in hardware (IA64 or ppc64 on iseries) and they have all
    opted to use
    > an conventional protection model.

    Do you know why? Can you point me to the people who did these ports so I can
    ask?

    > > So long as 1) a driver has a driver-load-time defined region of working
    data
    > > space; 2) has a defined code region; 3) gets its buffer addresses etc.
    as
    >
    > Just (1) alone is a illusion - linux drivers generally work on the shared
    > page pool, just like all other subsystems.

    In 1) I'm talking about the driver's local state, not the pages it's trying
    to fill. That local state will be in the driver's space, and protected from
    interference by everybody else.

    The pages (I assume) are arguments to the driver, i.e. "Fill *here*", and
    the owner of the page will have exposed the page to the driver before or as
    part of making the call. Or the call was "Fill some page and return it", and
    the driver calls the physmem manager who allocates the page, exposes it to
    the driver, and reurns the address to the driver. When the driver is done it
    will hand off ownership of the page to the client. I fully expect that the
    present code for this mechanism will have to be mangled, but I suspect that
    the kernel already implements some concept of "owner" for a physpage and we
    can hook the ownership transfer into our model.

    I hope :-)

    Ivan

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


  • Next message: Claudio Martins: "Re: usage of RealTek 8169 crashes my Linux system"

    Relevant Pages

    • Re: OT: And so it begins...
      ... a protection scheme owned by ... driver. ... Player needed to be upgraded to play the CD. ... mandatory requirement to use godawful highschool-reject programmers to ...
      (comp.sys.ibm.pc.games.action)
    • Re: On my head be it if I dont wear a helmet
      ... So that they are better made and offer better protection to cyclists ... unreasonable speed for a fit cyclist), 30mph crashes (easily ... I can remember the days when if a driver gave you a lift and fastened his own seat-belt, it made you suspect that he was a nervous driver, lacking in confidence in his own skills and experience- because you perceived him as actively preparing to have a collision. ...
      (uk.rec.cycling)
    • Re: [PATCH] block: fix q->max_segment_size checking in blk_recalc_rq_segments about VMERGE
      ... performance degradation do you see (and what driver do you use and what is ... Normal I/O obviously can work ... it is only used on two architectures, one already outdated, the ...
      (Linux-Kernel)
    • [NT] Bypassing Pedestal Software Integrity Protection Driver (Time Vulnerability)
      ... This driver was created to provide protection against Rootkit ... To give administrator ability to uninstall IPD, ... which fixes this vulnerability. ...
      (Securiteam)
    • Re: how many win64?
      ... IA64 and the other with AMD64? ... Where can I read more about this two architectures? ... AMD64 compiler won't do that. ... > Software Engineer, NT Driver ...
      (microsoft.public.development.device.drivers)