Re: /dev/kmem

From: Tigran Aivazian (tigran@veritas.com)
Date: Fri May 05 2000 - 09:38:39 EDT

  • Next message: Tigran Aivazian: "Re: Unresolved symbol mystery"

    On Fri, 5 May 2000, Michal Kosek wrote:
    > On Fri, 5 May 2000, Tigran Aivazian wrote:
    >
    > > On Fri, 5 May 2000, Michal Kosek wrote:
    > > > I want to learn something about using of /dev/kmem.
    > >
    > > The idea of /dev/kmem is that file "offsets" in it correspond to kernel
    > > virtual addresses, so seeking to the addresses of "well-known" symbols and
    > > reading values off there gives you the values of kernel data
    > > structures. Of course, these values are not 100% self-consistent because
    > > the kernel data structures change while you are reading/writing them.
    > Yes, but how can I know what is offset of any specific structure I want to
    > read??

    generally, under UNIX you would use nlist(3C) on /stand/unix. Under Linux
    you get the offset by looking at System.map file or, much better, by
    using:

    ksymoops -s map < /dev/null

    and examining the map file which contains addresses of the modules'
    symbols also. If you look at lsof(8) source code, I vaguely remember it
    has some very nice interface that does the symbol manipulation for you
    which can be cut-and-pasted into your own program. Also, the MCL crash I
    mentioned contains a useful set of functions that manipulate kernel
    symbols - can be "borrowed" too as all this stuff is GPL.

    >
    > >
    > > Linux version of /dev/kmem has one limitation - you cannot write to
    > > vmalloc'd range of addresses but you can read from them. Amit Kale (of
    > > VERITAS) solved this problem and sent a patch so if you need this ability
    > > - look for it in archives.
    > Does it mean that even if I left /dev/kmem world-writable noone would be
    > able to do anything with my system????????
    >

    no, it does not mean that at all. It only means nobody would be able to
    write to areas of memory allocated by means of vmalloc() or PCI memory
    remapped via ioremap().

    > >
    > > As for examples of usage of /dev/kmem - some old (and also non-Linux)
    > > versions of ps(1) used to use /dev/kmem - nowadays it is much better to
    > > access kernel data structures via well-defined interfaces exported by
    > > /proc.
    > Yes, but as I wrote in my previous mail: using /dev/kmem for process list
    > may be useful in finding some well-hidden backdoors - so I'd like to know
    > how to do it...
    >

    your question is strange. Having access to /dev/kmem allows one to write
    garbage to kernel data structures which will render system useless - what
    can be worse than that?

    Besides, /dev/kmem is not the only way to access kernel data structures.
    It is quite convenient to -g compile the kernel and use 'gdb -q vmlinux
    /proc/kcore' command to analyze them manually. But if you need to do it
    from a program then /dev/kmem is easier, of course, because you don't need
    to parse the ELF headers.

    Regards,
    Tigran.

    -
    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/



    This archive was generated by hypermail 2b29 : Fri May 05 2000 - 10:02:10 EDT