[ Truth in advertising? ]
From: Pavel Machek <[email protected]>
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
> - 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
From: Manfred Spraul <[email protected]>
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.
David S. Miller wrote:
> From: Manfred Spraul <[email protected]>
> 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
"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:[email protected]
or mailto:[email protected]
From: Kasper Dupont <[email protected]>
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.
"David S. Miller" wrote:
>
> From: Kasper Dupont <[email protected]>
> 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:[email protected]
or mailto:[email protected]
From: Kasper Dupont <[email protected]>
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?
"David S. Miller" wrote:
>
> From: Kasper Dupont <[email protected]>
> 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:[email protected]
or mailto:[email protected]
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(¤t->mm->mmap_sem); \
check_wp_bit(); \
real_copy_to_user(); \
up(¤t->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
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:[email protected]
or mailto:[email protected]
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
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
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(¤t->mm->mmap_sem); > check_wp_bit(); > real_copy_to_user(); > up(¤t->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.
Hi!
> > From: Manfred Spraul <[email protected]>
> > 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.
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