Re: i486 emu in mainline?

[Arjan van de Ven <arjanv@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1518 bytes --]


On Sun, May 23, 2004 at 11:48:53AM +0200, Willy Tarreau wrote:
> On Sun, May 23, 2004 at 11:13:56AM +0200, Arjan van de Ven wrote:
> > On Sun, May 23, 2004 at 10:44:15AM +0200, Willy Tarreau wrote:
> > > Hi Arjan,
> > > 
> > > On Sun, May 23, 2004 at 09:13:20AM +0200, Arjan van de Ven wrote:
> > > > on first look it seems to be missing a bunch of get_user() calls and
> > > > does direct access instead....
> > > 
> > > It was intentional for speed purpose. The areas are checked once with
> > > verify_area() when we need to access memory, then data is copied directly
> > > from/to memory. I don't think there's any risk, but I can be wrong.
> > 
> > it's an oopsable offence; nothing is making sure the memory is actually
> > present for example.
> 
> You mean like when a user does a malloc() and the memory is not physically
> allocated because not used yet ? or even in case memory has been swapped
> out ? 

Well both. Or even a stray invalid userspace pointer.

copy_from_user/get_user will catch the trap the cpu will cause in such a
case, and the VM will swap in the page, allocate a new page in case of the
malloc-but-never-used-yet or throw a segmentation fault if the userspace
pointer is broken.

If there is no protection (eg there is no exception handler defined) then
the kernel will throw an oops since it's an uncaught/unhandled kernel mode
exception. Obviously copy_from_user/get_user and co have such exception
handlers defined and will do the expected (right) thing. Direct access does
not.



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]