linux-mips-fnet
[Top] [All Lists]

Re: Kernel/User Memory Access and Original Sin

To: "Kevin D. Kissell" <kevink@mips.com>
Subject: Re: Kernel/User Memory Access and Original Sin
From: Philip Blundell <Philip.Blundell@pobox.com>
Date: Mon, 28 Feb 2000 13:03:13 +0000
Cc: "Linux/MIPS fnet" <linux-mips@fnet.fr>, "Linux/MIPS algor" <linux-porters@algor.co.uk>, "Linux SGI" <linux@cthulhu.engr.sgi.com>
In-reply-to: Message from "Kevin D. Kissell" <kevink@mips.com> of "Mon, 28 Feb 2000 13:23:17 +0100." <010101bf81e6$9c546120$0ceca8c0@satanas.mips.com>
References: <010101bf81e6$9c546120$0ceca8c0@satanas.mips.com>
>the x86 VM implementation.   In the MIPS 2.2 and 2.3
>kernels, the check, __access_ok, is a simple heuristic
>that verifies that the access does not reference kernel
>memory, nor is it greater than 2GB in size.  That's cheap,
>but not reliable.  The primary failure mode I observed was 
>where signal.c blows up when trying to set up a signal context 
>on a corrupted user stack, but the problem is more pervasive.

The access_ok check is not supposed to be complete.  You need to also trap 
exceptions in get_user, put_user and so on - this goes for all architectures, 
not just MIPS.  Take a look at the hairy macros in asm/uaccess.h.

It sounds like this isn't working, but it's not cause for a complete redesign 
of the user-access mechanism.  In fact, what you are proposing sounds rather 
like the way these things were done in pre-2.2 days.

p.


<Prev in Thread] Current Thread [Next in Thread>