Re: [TRIVIAL] Warn users about machines with non-working WP bit

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[Pavel Machek]

Hi!

> >   From: Manfred Spraul <manfred@colorfullife.com>
> >   Date: Tue, 06 Aug 2002 11:17:33 +0200
> >
> >   > -		printk("No.\n");
> >   > +		printk("No (that's security hole).\n");
> >   >  #ifdef CONFIG_X86_WP_WORKS_OK
> >   
> >   Could you explain the hole?
> >   WP works for user space apps, only ring0 (or ring 0-2?) code
> >   ignores the WP bit on i386.
> >
> >So copy_to_user() could write to user areas that are write-proteced.
> >
> >verify_area() checks aren't enough, consider a threaded application
> >calling mprotect() while the copy is in progress.

> Then we should either fix copy_to_user(), or mark 80386 unsupported, or 
> disable multi-threading on 80386. It's a random memory corruption, far 
> worse than a security hole.

Fortunately app has to be seriously missbehaving for this to happen. Fixing
copy_to_user would be nicest; I do not think dropping 386 because of *this*
is good idea... [But it might force 386 users to fix copy_to_user ;-)]

									Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[Pavel Machek]

Hi!

> >I just get another idea, that might be easier to get right. If
> >the only problem is one process changing the mm while another
> >process is doing a copy_to_user, we should be able to fix it by
> >placing a readlock on the mm while the copy_to_user is in progress.
> >  
> >
> Yes, that would work. copy_to_user is never called with the mmap 
> semaphore locked, i.e.
> 
> #define copy_to_user(...) >         down(&current->mm->mmap_sem); >         check_wp_bit(); >         real_copy_to_user(); >         up(&current->mm->mmap_sem)
> 
> verify_area would just check that the pointer is below TASK_SIZE, and 
> the wp bit is checked within copy_to_user().
> 
> But how many 80386 Linux systems that run the 2.4 kernel exist?

Many embedded boxes, I beieve, have modern 386 CPUs.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

[TRIVIAL] Warn users about machines with non-working WP bit

[Rusty Trivial Russell]

[ Truth in advertising? ]

From:  Pavel Machek <pavel@ucw.cz>

  Hi!
  
  This might be good idea, as those machines are not safe for multiuser
  systems.
  

--- trivial-2.5.30/arch/i386/mm/init.c.orig	2002-08-06 13:18:12.000000000 +1000
+++ trivial-2.5.30/arch/i386/mm/init.c	2002-08-06 13:18:12.000000000 +1000
@@ -397,7 +397,7 @@
 	local_flush_tlb();
 
 	if (!boot_cpu_data.wp_works_ok) {
-		printk("No.\n");
+		printk("No (that's security hole).\n");
 #ifdef CONFIG_X86_WP_WORKS_OK
 		panic("This kernel doesn't support CPU's with broken WP. Recompile it for a 386!");
 #endif
-- 
  Don't blame me: the Monkey is driving

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[Manfred Spraul]

> -		printk("No.\n");
> +		printk("No (that's security hole).\n");
>  #ifdef CONFIG_X86_WP_WORKS_OK

Could you explain the hole?
WP works for user space apps, only ring0 (or ring 0-2?) code ignores the WP bit on i386.

--
	Manfred

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[David S. Miller]

   From: Manfred Spraul <manfred@colorfullife.com>
   Date: Tue, 06 Aug 2002 11:17:33 +0200

   > -		printk("No.\n");
   > +		printk("No (that's security hole).\n");
   >  #ifdef CONFIG_X86_WP_WORKS_OK
   
   Could you explain the hole?
   WP works for user space apps, only ring0 (or ring 0-2?) code
   ignores the WP bit on i386.

So copy_to_user() could write to user areas that are write-proteced.

verify_area() checks aren't enough, consider a threaded application
calling mprotect() while the copy is in progress.

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[Manfred Spraul]

David S. Miller wrote:

>   From: Manfred Spraul <manfred@colorfullife.com>
>   Date: Tue, 06 Aug 2002 11:17:33 +0200
>
>   > -		printk("No.\n");
>   > +		printk("No (that's security hole).\n");
>   >  #ifdef CONFIG_X86_WP_WORKS_OK
>   
>   Could you explain the hole?
>   WP works for user space apps, only ring0 (or ring 0-2?) code
>   ignores the WP bit on i386.
>
>So copy_to_user() could write to user areas that are write-proteced.
>
>verify_area() checks aren't enough, consider a threaded application
>calling mprotect() while the copy is in progress.
>  
>
Then we should either fix copy_to_user(), or mark 80386 unsupported, or 
disable multi-threading on 80386. It's a random memory corruption, far 
worse than a security hole.

--
    Manfred

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[David S. Miller]

   From: Kasper Dupont <kasperd@daimi.au.dk>
   Date: Tue, 06 Aug 2002 16:03:34 +0200

   "David S. Miller" wrote:
   > verify_area() checks aren't enough, consider a threaded application
   > calling mprotect() while the copy is in progress.
   
   Couldn't we just freeze all other processes with the same mm while
   a copy_to_user is in progress?

What if we have to sleep and page in some memory from disk?

Your idea could lead to deadlock in a multi-threaded app.

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[Kasper Dupont]

"David S. Miller" wrote:
> 
> verify_area() checks aren't enough, consider a threaded application
> calling mprotect() while the copy is in progress.

Couldn't we just freeze all other processes with the same mm while
a copy_to_user is in progress?

Of course this should only be done if CONFIG_X86_WP_WORKS_OK is
not enabled, so systems with a working wp doesn't have to take a
performance hit.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razrep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[David S. Miller]

   From: Kasper Dupont <kasperd@daimi.au.dk>
   Date: Tue, 06 Aug 2002 16:16:03 +0200

   "David S. Miller" wrote:
   > What if we have to sleep and page in some memory from disk?
   > 
   > Your idea could lead to deadlock in a multi-threaded app.
   
   Why? The page should eventually get into memory from the disk,
   at this point the process doing the copy can continue, and
   when it finishes the other processes gets waked up. While the
   copy_to_user is in progress all the processes witht this mm
   should be in noninterruptible sleep. The sleeping procces
   doesn't need to do anything to get the page into memory, so I
   cannot see the problem.
   
What if the other thread we freeze is holding a lock we
need in order to get the page from disk?

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[Kasper Dupont]

"David S. Miller" wrote:
> 
>    From: Kasper Dupont <kasperd@daimi.au.dk>
>    Date: Tue, 06 Aug 2002 16:03:34 +0200
> 
>    "David S. Miller" wrote:
>    > verify_area() checks aren't enough, consider a threaded application
>    > calling mprotect() while the copy is in progress.
> 
>    Couldn't we just freeze all other processes with the same mm while
>    a copy_to_user is in progress?
> 
> What if we have to sleep and page in some memory from disk?
> 
> Your idea could lead to deadlock in a multi-threaded app.

Why? The page should eventually get into memory from the disk,
at this point the process doing the copy can continue, and
when it finishes the other processes gets waked up. While the
copy_to_user is in progress all the processes witht this mm
should be in noninterruptible sleep. The sleeping procces
doesn't need to do anything to get the page into memory, so I
cannot see the problem.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razrep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[Kasper Dupont]

"David S. Miller" wrote:
> 
>    From: Kasper Dupont <kasperd@daimi.au.dk>
>    Date: Tue, 06 Aug 2002 16:16:03 +0200
> 
>    "David S. Miller" wrote:
>    > What if we have to sleep and page in some memory from disk?
>    >
>    > Your idea could lead to deadlock in a multi-threaded app.
> 
>    Why? The page should eventually get into memory from the disk,
>    at this point the process doing the copy can continue, and
>    when it finishes the other processes gets waked up. While the
>    copy_to_user is in progress all the processes witht this mm
>    should be in noninterruptible sleep. The sleeping procces
>    doesn't need to do anything to get the page into memory, so I
>    cannot see the problem.
> 
> What if the other thread we freeze is holding a lock we
> need in order to get the page from disk?

If the other thread is in user mode, that should not be possible.
If the other thread is in kernel mode, things starts getting
complicated. Maybe we could delay the freezing until the other
thread leaves kernel. I don't right away see if the current
thread has to wait for the other process to leave kernel and
get frozen.

I just get another idea, that might be easier to get right. If
the only problem is one process changing the mm while another
process is doing a copy_to_user, we should be able to fix it by
placing a readlock on the mm while the copy_to_user is in progress.

I don't remember if the mm is protected by a spinlock or
semaphore, if it is a spinlock maybe it could be replaced by a
semaphore? Otherwise we could prevent the copy_to_user from
completing if it has to sleep, and just release the lock if it
does go to sleep. In that case when the process gets waked up, it
has to get a special return value, that forces it to repeat the
verification of the area. (Isn't there a way to ensure the pages
are in memory before starting the actual copy, that would make
things simpler?)

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razrep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[Manfred Spraul]

Kasper Dupont wrote:

>I just get another idea, that might be easier to get right. If
>the only problem is one process changing the mm while another
>process is doing a copy_to_user, we should be able to fix it by
>placing a readlock on the mm while the copy_to_user is in progress.
>  
>
Yes, that would work. copy_to_user is never called with the mmap 
semaphore locked, i.e.

#define copy_to_user(...) \
        down(&current->mm->mmap_sem); \
        check_wp_bit(); \
        real_copy_to_user(); \
        up(&current->mm->mmap_sem)

verify_area would just check that the pointer is below TASK_SIZE, and 
the wp bit is checked within copy_to_user().

But how many 80386 Linux systems that run the 2.4 kernel exist?

--
    Manfred

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[Kasper Dupont]

Manfred Spraul wrote:
> 
> But how many 80386 Linux systems that run the 2.4 kernel exist?

I don't know. I don't have any myself.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:razrep@daimi.au.dk
or mailto:mcxumhvenwblvtl@skrammel.yaboo.dk

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[Willy Tarreau]

On Tue, Aug 06, 2002 at 04:36:35PM +0200, Manfred Spraul wrote:
> But how many 80386 Linux systems that run the 2.4 kernel exist?

at least my ADSL router/firewall here :-)
It has the advantage of running really cool without *ANY* mechanical parts.
And for this exact reason, there may many others around the world.

Regards,
Willy

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[Zwane Mwaikambo]

On Tue, 6 Aug 2002, Manfred Spraul wrote:

> But how many 80386 Linux systems that run the 2.4 kernel exist?

http://function.linuxpower.ca/dmesg-386-2.4.txt

8)

-- 
function.linuxpower.ca

Re: [TRIVIAL] Warn users about machines with non-working WP bit

[Alan Cox]

On Mon, 2001-08-20 at 21:06, Pavel Machek wrote:
> > But how many 80386 Linux systems that run the 2.4 kernel exist?
> 
> Many embedded boxes, I beieve, have modern 386 CPUs.

The 6117 is one example of that. Its a 386SX PC on a chip