Re: [uml-devel] [PATCH] fix writing into /dev/kmem

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

Alle 02:31, martedì 2 marzo 2004, Jeff Dike ha scritto:
> blaisorblade_spam@yahoo.it said:
> > This patch is like the one for the read from /dev/kmem (i.e. the one
> > fixing  the panic when one does "cat /dev/kmem": you can reproduce
> > this panic on  Uml2.6): it makes it behave like /dev/mem (man 4 mem is
> > indeed helpful!). So  it is basically not *the right way*.
>
> Well, if you look at read_kmem, the thing that it reads is physical memory
> plus kernel virtual memory.  I.e. /dev/kmem is /dev/mem + the kernel
> virtual memory areas.

No, I do not agree (and man 4 mem agrees with me; I've quoted it below). As 
you later say after reading the code (which contains The Truth), the address 
passed to /dev/kmem as already been __va'ed. I.e., if those devices were 
array we could say:

 /dev/kmem[ __va (address) ] == /dev/mem [ address ];

> Addmittedly, I don't see how x86 gets away with dereferencing address 0

Well, physical address 0 does exist, for /dev/mem; /dev/kmem instead returns 
-EFAULT (try cat /dev/kmem), because copy_to_user returns a fault state.
Actually, 0 is derefereced, and the CPU throws an exception; but thanks to the 
__extable section and "search_exception_table", that exception is "caught". 
Read Documentation/exception.txt. I.e., copy_to_user actually checks both the 
"to" and "from" addresses.

Instead, in UML skas mode, possibly because the process VMA's are not mapped 
in the kernel thread, the page tables for the user are checked by hand (by 
um_virt_to_phys); but the check is done only for the userspace address (i.e. 
the "to" address for copy_to_user; everything applies even to copy_from_user, 
of course).

In tt mode it uses actually exception, even if they are coded by hand without 
using __extable (I see a flag here, probably set while catching SIGSEGV).

So, probably (to check), the kernel panic would happen only in tt mode.

Anyway, here comes that copy_{to,from}_user are buggy. Since fixing those 
would have a good performance hit (to test, but that will probably be 
sensitive; Documentation/exception.txt says exactly this, because most 
programs have no bug so checking the page tables has a big cost) and klogd 
would not work anyway, add an XXX comment, add it on your TODO and make 
/dev/kmem always return -EFAULT, as a workaround; or make it check the 
address with maybe_map (and #ifdef the change; even other archs have 
arch-specific code there).

> but I don't see what's wrong with my fixes.
[From below]
> The only out that I can see is that readers of kmem are supposed to pass in
> kernel virtual addresses, 0xc0000000 and up.
Yes, this is the reality.

So, __va(p) will overflow. That has *actually* happened (in fact I studied 
what I say in these mails when someone got a fault if he loaded the LVM 
modules). In fact, in the read_mem there is a check against the overflow:
       if (p >= end_mem)
                return 0;

Well, I said you to read mem(4), you didn't, so I quote:

       Mem  is  a character device file that is an image of the main memory of
       the computer.  It may be used, for example, to examine (and even patch)
       the system.

       Byte  addresses  in  mem  are interpreted as *physical* memory 
addresses.
[...]
       The file kmem is the same as mem, except that the kernel virtual memory
       rather than physical memory is accessed.

In fact, see this:

# cat /dev/kmem
cat: /dev/kmem: Bad address

> > To read the physical address  0x1with /dev/kmem, you are supposed to
> > read 0xc0000001; so with that patch  any proper user of /dev/kmem will
> > overflow p.
>
> 0xa0000001, actually, which is what __va does.

Well, on *i386* that is 0xc0000001; since klogd is built with i386 kernel 
headers, it will use those.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel