mapping physical memory to a non-root process - Linux

This is a discussion on mapping physical memory to a non-root process - Linux ; I'd like to map a _specific_ portion of physical memory and make it available to a non-root process. No other semantics like ioctl are needed. The issues I see include making sure the kernel doesn't use this memory for other ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: mapping physical memory to a non-root process

  1. mapping physical memory to a non-root process

    I'd like to map a _specific_ portion of physical memory and make it
    available to a non-root process. No other semantics like ioctl are
    needed. The issues I see include making sure the kernel doesn't use
    this memory for other purposes (like page buffering, etc) beforehand.
    ISTM this will need to be some kind of general device driver that
    can be memory mapped. I'm thinking it could have multiple minor
    numbers each of which could be set to a specific address range by
    root which would then also set permissions/ownership to allow the
    non-root processes access. Launching the non-root process first
    through root to get and inherit access won't work as I might need
    to do the open within the non-root process. Are any device drivers
    already in existance that could be adapted easily to this, or does
    this sound like a start from scratch project?


    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-01-05-1351@ipal.net |
    |------------------------------------/-------------------------------------|

  2. Re: mapping physical memory to a non-root process

    phil-news-nospam@ipal.net writes:

    > I'd like to map a _specific_ portion of physical memory and make it
    > available to a non-root process. No other semantics like ioctl are
    > needed. The issues I see include making sure the kernel doesn't use
    > this memory for other purposes (like page buffering, etc) beforehand.
    > ISTM this will need to be some kind of general device driver that
    > can be memory mapped. I'm thinking it could have multiple minor
    > numbers each of which could be set to a specific address range by
    > root which would then also set permissions/ownership to allow the
    > non-root processes access. Launching the non-root process first
    > through root to get and inherit access won't work as I might need
    > to do the open within the non-root process. Are any device drivers
    > already in existance that could be adapted easily to this, or does
    > this sound like a start from scratch project?


    I'm not aware of any such hacks. However, my immediate thought on how
    to do it go something like this:

    - Register some (configurable) number of devices, each corresponding
    to one region.
    - To set the region for each of these devices, use an ioctl() call as
    root. Make this call fail if any page in the range is already in
    use.
    - Make a simple tool to configure the regions.
    - Allow non-root users access according to device file permissions.
    - Perhaps some code from /dev/mem could be reused.

    As you say, care must be taken to make sure the kernel doesn't go and
    use those pages for something else. I'm afraid I don't know how to do
    that, although I'm sure there's a way.

    --
    Måns Rullgård
    mru@inprovide.com

  3. Re: mapping physical memory to a non-root process

    On Fri, 05 Jan 2007 21:49:37 +0000 M?ns Rullg?rd wrote:
    | phil-news-nospam@ipal.net writes:
    |
    |> I'd like to map a _specific_ portion of physical memory and make it
    |> available to a non-root process. No other semantics like ioctl are
    |> needed. The issues I see include making sure the kernel doesn't use
    |> this memory for other purposes (like page buffering, etc) beforehand.
    |> ISTM this will need to be some kind of general device driver that
    |> can be memory mapped. I'm thinking it could have multiple minor
    |> numbers each of which could be set to a specific address range by
    |> root which would then also set permissions/ownership to allow the
    |> non-root processes access. Launching the non-root process first
    |> through root to get and inherit access won't work as I might need
    |> to do the open within the non-root process. Are any device drivers
    |> already in existance that could be adapted easily to this, or does
    |> this sound like a start from scratch project?
    |
    | I'm not aware of any such hacks. However, my immediate thought on how
    | to do it go something like this:
    |
    | - Register some (configurable) number of devices, each corresponding
    | to one region.
    | - To set the region for each of these devices, use an ioctl() call as
    | root. Make this call fail if any page in the range is already in
    | use.
    | - Make a simple tool to configure the regions.
    | - Allow non-root users access according to device file permissions.
    | - Perhaps some code from /dev/mem could be reused.
    |
    | As you say, care must be taken to make sure the kernel doesn't go and
    | use those pages for something else. I'm afraid I don't know how to do
    | that, although I'm sure there's a way.

    Possibly by making the minor=0 device be initially set up at driver init
    time to be the usable memory like or similar to /dev/kmem. Then with the
    range overlap test including that one, other minors can't hit that memory.

    My concern now is file permissions could live across reboots while range
    settings don't. The uninitialized state would need to be something that
    can access nothing at all in case the non-root process reaches it first
    (such as the rc file setting it up didn't run).

    There should also be an ioctl() to read back the range. Should non-root
    be able to read that? I don't see much harm.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-01-05-1556@ipal.net |
    |------------------------------------/-------------------------------------|

  4. Re: mapping physical memory to a non-root process

    phil-news-nospam@ipal.net writes:

    > On Fri, 05 Jan 2007 21:49:37 +0000 M?ns Rullg?rd wrote:
    > | phil-news-nospam@ipal.net writes:
    > |
    > |> I'd like to map a _specific_ portion of physical memory and make it
    > |> available to a non-root process. No other semantics like ioctl are
    > |> needed. The issues I see include making sure the kernel doesn't use
    > |> this memory for other purposes (like page buffering, etc) beforehand.
    > |> ISTM this will need to be some kind of general device driver that
    > |> can be memory mapped. I'm thinking it could have multiple minor
    > |> numbers each of which could be set to a specific address range by
    > |> root which would then also set permissions/ownership to allow the
    > |> non-root processes access. Launching the non-root process first
    > |> through root to get and inherit access won't work as I might need
    > |> to do the open within the non-root process. Are any device drivers
    > |> already in existance that could be adapted easily to this, or does
    > |> this sound like a start from scratch project?
    > |
    > | I'm not aware of any such hacks. However, my immediate thought on how
    > | to do it go something like this:
    > |
    > | - Register some (configurable) number of devices, each corresponding
    > | to one region.
    > | - To set the region for each of these devices, use an ioctl() call as
    > | root. Make this call fail if any page in the range is already in
    > | use.
    > | - Make a simple tool to configure the regions.
    > | - Allow non-root users access according to device file permissions.
    > | - Perhaps some code from /dev/mem could be reused.
    > |
    > | As you say, care must be taken to make sure the kernel doesn't go and
    > | use those pages for something else. I'm afraid I don't know how to do
    > | that, although I'm sure there's a way.
    >
    > Possibly by making the minor=0 device be initially set up at driver init
    > time to be the usable memory like or similar to /dev/kmem. Then with the
    > range overlap test including that one, other minors can't hit that memory.


    The way to go of course depends on why you need this functionality in
    the first place. Normally you wouldn't want to let any random process
    access memory that might be used by another process. In some special
    cases that might still make sense though. Another aspect is memory
    mapped PCI devices and the like.

    > My concern now is file permissions could live across reboots while range
    > settings don't. The uninitialized state would need to be something that
    > can access nothing at all in case the non-root process reaches it first
    > (such as the rc file setting it up didn't run).


    Yes, that makes sense.

    > There should also be an ioctl() to read back the range. Should non-root
    > be able to read that? I don't see much harm.


    I don't see any harm either. That's the usual Unix philosophy of
    allowing read access when the information obtained can't be reasonably
    used for malicious purposes.

    --
    Måns Rullgård
    mru@inprovide.com

  5. Re: mapping physical memory to a non-root process

    phil-news-nospam@ipal.net writes:

    > I'd like to map a _specific_ portion of physical memory and make it
    > available to a non-root process.

    ....
    > Are any device drivers
    > already in existance that could be adapted easily to this, or does
    > this sound like a start from scratch project?


    The driver for the Matrox Meteor frame grabber in version 2.2.x (look
    for meteor-2.2.x.tar.gz) had a module called himemfb that almost does
    what you want. AFAICR, you had to chop off a part of memory at the
    end by specifying "mem=xM" at kernel boot time. At one time I have
    updated himemfb to linux-2.4.x, but I have no idea how hard it would
    be to get it to work with current kernels.

    Regards,
    Wolfram

+ Reply to Thread