Re: sys/param.h

:Matt,
:
:are we going to use the priority queues from sys/param.h?
:
:Right now they're #if 0'd out.
:
:tsleep() code uses it, for example.
:
:-- 
:Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai

    You mean all the Pxxx stuff?  No, we aren't going to use that any 
    more.  That is used in 4.x and 5.x because kernel threads are scheduled
    by the user process scheduler.  In DragonFly kernel threads are
    scheduled by the LWKT scheduler and (typically) have a set fixed
    priority based on whether the thread represents an interrupt, software
    interrupt, mainline kernel code, etc.  You may have noticed that I removed
    all the priority junk from tsleep, only flags are passed now.

    We may reintroduce some sort of priority mechanism to deal with certain
    obscure situations but at the moment I am leaning against it.  If we do
    it will take on a different form.. probably a flag to tsleep rather then
    a 'priority'.

					-Matt
					Matthew Dillon 
					<dillon <at> backplane.com>

Buffer overflow?

First, congratulations to Matt on attracting lots of talented people to
this new project.  Looks like it's off to a great start already.

I've seen hundreds, maybe thousands, of remotely exploitable buffer
overflow bugs reported for many different operating systems -- even
those outside of Redmond.

Speaking (as I do) with the confidence which only ignorance can
engender, I'd like to propose that the single most important thing
this project could accomplish is to move the responsibility for
secure applications programming AWAY from the application programmer
and putting it squarely on the shoulders of the operating system
where it belongs.  So there!   :o)

I've read enough about .NET to know that a programmer needs to be
an expert in arcana to write even a trivial application.  This just
seems WRONG!  It's a giant step backwards in operating system security,
and I say that with confidence even when I know I know almost nothing
about security.  But I know when I'm right, anyway!

Seriously, if anyone could explain to me (a non-professional programmer)
how it came to pass that buffer overflow is a non-trivial problem I would
be truly grateful, since I've asked this before in several forums and I
never got a real answer (that I could understand).

Since this project seems primarily concerned with kernel design, are
there any thoughts on how security could be designed into the kernel
and isolated as much as possible from userland?

This is a big topic, but the beginning of a project seems like a better

Re: Buffer overflow?

:..
:Seriously, if anyone could explain to me (a non-professional programmer)
:how it came to pass that buffer overflow is a non-trivial problem I would
:be truly grateful, since I've asked this before in several forums and I
:never got a real answer (that I could understand).
:
:Since this project seems primarily concerned with kernel design, are
:there any thoughts on how security could be designed into the kernel
:and isolated as much as possible from userland?
:
:This is a big topic, but the beginning of a project seems like a better
:place to consider security than at the other end.

    It's all historical.  The original C language library had functions
    like sprintf(), strcpy(), strcat()... none of which are bounded
    functions.  Hundreds of thousands of programmers grew up on those 
    functions and they are all now microsoft employees .

    Seriously, though, the C lib has new functions, e.g. snprintf(), and 
    the only way to avoid most buffer overflow problems is to use these
    bounded functions and never, ever use the unbounded functions, even
    if you *know* a particular use will not overflow a buffer.

    The second type of buffer overflow is an array index overflow, where
    an array index is incorrectly calculated or incorrectly bounded.  For
    example, consider the age-old misuse of malloc() where beginning 
    programmers would do something like:  str2 = malloc(strlen(str1)),
    which doesn't account for the \0 terminating the string, or programmers
    who check the high side but forget that they are using a signed index
    variable which could very well be negative.

Re: Buffer overflow?

>     Seriously, though, the C lib has new functions, e.g. snprintf(), and 
>     the only way to avoid most buffer overflow problems is to use these
>     bounded functions and never, ever use the unbounded functions, even
>     if you *know* a particular use will not overflow a buffer.
> 
>     The second type of buffer overflow is an array index overflow, where
>     an array index is incorrectly calculated or incorrectly bounded.  For
>     example, consider the age-old misuse of malloc() where beginning 
>     programmers would do something like:  str2 = malloc(strlen(str1)),
>     which doesn't account for the \0 terminating the string, or programmers
>     who check the high side but forget that they are using a signed index
>     variable which could very well be negative.
> 
>     If just these two problem areas were cleaned up 99% of all buffer 
>     overflow issues would disappear.
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon <at> backplane.com>

Have you given any thought to pulling in the changes that OpenBSD made 
to harden against buffer overflows (i.e. canary checking)?  They've 
added some pretty serious mechanisms to make it harder to exploit buffer 
overflows (and made it turned on by default).

I've been surprised that none of the other BSD's have pulled in this code.

Richard Coleman
richardcoleman <at> mindspring.com

Re: Buffer overflow?

-On [20030801 08:02], Richard Coleman (richardcoleman <at> mindspring.com) wrote:
>Have you given any thought to pulling in the changes that OpenBSD made 
>to harden against buffer overflows (i.e. canary checking)?  They've 
>added some pretty serious mechanisms to make it harder to exploit buffer 
>overflows (and made it turned on by default).

IIRC Hiten is busy working on getting the OpenBSD non-exec stack code
working on DragonFly.

--

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
How many cares one loses when one decides not to be something but to be
someone.

Re: Buffer overflow?

Jeroen Ruigrok/asmodai wrote:

> -On [20030801 08:02], Richard Coleman (richardcoleman <at> mindspring.com) wrote:
> 
>>Have you given any thought to pulling in the changes that OpenBSD made 
>>to harden against buffer overflows (i.e. canary checking)?  They've 
>>added some pretty serious mechanisms to make it harder to exploit buffer 
>>overflows (and made it turned on by default).
> 
> 
> IIRC Hiten is busy working on getting the OpenBSD non-exec stack code
> working on DragonFly.
> 

	I have sussed out the signal trampoline code and how it was
	changed for IRIX binary emulation in other (NeT|Open) BSDs.
	I am gonna be off to holiday from next week or so; once I get
	back, I will resume my efforts on the non-exec stack for DFly.

	FWIW, I have also had my eye on the binary checksumming code
	that was put in Open/NetBSD.

	Cheers.

--

-- 
Hiten Pandya
hmp <at> nxad.com
http://hmp.serverninjas.com/

Re: sys/param.h

-On [20030801 01:32], Matthew Dillon (dillon <at> apollo.backplane.com) wrote:
>    You mean all the Pxxx stuff?  No, we aren't going to use that any 
>    more.  That is used in 4.x and 5.x because kernel threads are scheduled
>    by the user process scheduler.  In DragonFly kernel threads are
>    scheduled by the LWKT scheduler and (typically) have a set fixed
>    priority based on whether the thread represents an interrupt, software
>    interrupt, mainline kernel code, etc.  You may have noticed that I removed
>    all the priority junk from tsleep, only flags are passed now.

I need to check out the PCATCH stuff, but for now I cleaned up the
others.

Find patch attached.

--

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
Man is the Dream of the dolphin...

Index: src/contrib/ipfilter/ip_compat.h
===================================================================
RCS file: /home/ncvs/DragonFlyBSD/src/contrib/ipfilter/ip_compat.h,v
retrieving revision 1.1
diff -u -r1.1 ip_compat.h
--- src/contrib/ipfilter/ip_compat.h	17 Jun 2003 02:44:51 -0000	1.1
+++ src/contrib/ipfilter/ip_compat.h	1 Aug 2003 06:56:53 -0000
 <at>  <at>  -553,7 +553,7  <at>  <at> 

Re: sys/param.h

Oops, sorry, this patch.

Previous one didn't have the param.h with it.  (Forgot to save from my
editor.)

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://www.in-nomine.org/~asmodai/diary/
Looking for the Sun that eclipsed behind black feathered wings...

Index: src/contrib/ipfilter/ip_compat.h
===================================================================
RCS file: /home/ncvs/DragonFlyBSD/src/contrib/ipfilter/ip_compat.h,v
retrieving revision 1.1
diff -u -r1.1 ip_compat.h
--- src/contrib/ipfilter/ip_compat.h	17 Jun 2003 02:44:51 -0000	1.1
+++ src/contrib/ipfilter/ip_compat.h	1 Aug 2003 06:56:53 -0000
 <at>  <at>  -553,7 +553,7  <at>  <at> 

 # if defined(sun) && !defined(linux) || defined(__sgi)
 #  define	UIOMOVE(a,b,c,d)	uiomove((caddr_t)a,b,c,d)
-#  define	SLEEP(id, n)	sleep((id), PZERO+1)
+#  define	SLEEP(id, n)	sleep((id), 1)
 #  define	WAKEUP(id)	wakeup(id)
 #  define	KFREE(x)	kmem_free((char *)(x), sizeof(*(x)))
 #  define	KFREES(x,s)	kmem_free((char *)(x), (s))
 <at>  <at>  -609,7 +609,7  <at>  <at> 
 #   define	KFREES(x,s)	FREE((x), M_TEMP)

ltmdm

If anybody is interested in a working version of the ltmdm
driver for rockwell winmodems, I have it working in dragonfly
at least until Matt starts on DEV again.
contact me for patches.

Rob

Matt, 
   Thanks for all the examples :)

Re: Buffer overflow?

On Fri, 01 Aug 2003 07:39:19 +0100
Hiten Pandya <hmp <at> nxad.com> wrote:

> > IIRC Hiten is busy working on getting the OpenBSD non-exec stack code
> > working on DragonFly.
> > 
> 
> 	I have sussed out the signal trampoline code and how it was
> 	changed for IRIX binary emulation in other (NeT|Open) BSDs.
> 	I am gonna be off to holiday from next week or so; once I get
> 	back, I will resume my efforts on the non-exec stack for DFly.

Are you also going to port it to FreeBSD?

Bye,
Alexander.

--

-- 
              The best things in life are free, but the
                expensive ones are still worth a look.

http://www.Leidinger.net                       Alexander  <at>  Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7