headers
Elad Efrat | 1 Jun 2007 19:16

Re: CVS commit: src

YAMAMOTO Takashi wrote:

>> Adjust the system build so that all programs and libraries that are setuid,
>> directly handle network data (including serial comm data), perform
>> authentication, or appear likely to have (or have a history of having)
>> data-driven bugs (e.g. file(1)) are built with USE_FORT=yes by default,
>> with the exception of libc, which cannot use USE_FORT and thus uses
>> only USE_SSP by default.  Tested on i386 with no ill results; USE_FORT=no
>> per-directory or in a system build will disable if desired.
> 
> where was it proposed?

"what he said." :)

also, where is the consensus of the class of programs to protect with
USE_FORT taken from? and what's the reason for it?

-e.
Permalink | Reply | 11 comments |
headers
Elad Efrat | 1 Jun 2007 22:52

Re: CVS commit: src

Thor Lancelot Simon wrote:

>> also, where is the consensus of the class of programs to protect with
>> USE_FORT taken from? and what's the reason for it?
> 
> It takes a considerable amount of time to get large sets of source files
> building cleanly with FORTIFY_SOURCE because one finds various failures
> to conform to the C standard (non-tolerance of standard functions implemented
> as macros in header files) and some genuine and sometimes rather complex
> bugs (e.g. the struct ifreq problem).  My intent was to get as much value
> for the initial investment of time as possible.

in other words, it is planned to, as time goes by, make more parts of
the system build with USE_FORT, correct?

-e.
Permalink | Reply | 2 comments |
headers
ITOH Yasufumi | 1 Jun 2007 01:15
Picon

CVS commit: [itohy-usb1] src/sys/dev


Module Name:	src
Committed By:	itohy
Date:		Thu May 31 23:15:19 UTC 2007

Modified Files:
	src/sys/dev/ic [itohy-usb1]: sl811hs.c
	src/sys/dev/usb [itohy-usb1]: api.txt ehci.c ohci.c uhci.c uhcivar.h
	    usb_mem.c usb_mem.h usb_mem_nodma.c usb_port.h usbdi.c usbdi.h
	    usbdivar.h

Log Message:
usbdi(9): Change usbd_map_buffer_mbuf to return the result, since
	mbuf(9) chain may be fragmented and mapping failure will happen.
-void usbd_map_buffer_mbuf(usbd_xfer_handle xfer, struct mbuf *chain)
+usbd_status usbd_map_buffer_mbuf(usbd_xfer_handle xfer, struct mbuf *chain)

usbdi(9): Add more diagnostic assertions.
uhci(4): fix aux dma for mbuf mapping.
slhci(4): fix repeated interrupt transfer (not tested).
ehci/slhci/ohci/uhci: Add checks where mbuf(4) transfer is not supported.

usb_port.h: Add some compat macros for FreeBSD.
usb_mem_nodma.c: Fix typos.

To generate a diff of this commit:
cvs rdiff -r1.11.18.1 -r1.11.18.2 src/sys/dev/ic/sl811hs.c
cvs rdiff -r1.1.2.1 -r1.1.2.2 src/sys/dev/usb/api.txt \
    src/sys/dev/usb/usb_mem_nodma.c
cvs rdiff -r1.123.12.1 -r1.123.12.2 src/sys/dev/usb/ehci.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christos Zoulas | 1 Jun 2007 01:34
Picon

CVS commit: src/sys/compat/netbsd32


Module Name:	src
Committed By:	christos
Date:		Thu May 31 23:34:42 UTC 2007

Modified Files:
	src/sys/compat/netbsd32: netbsd32_socket.c

Log Message:
message size == 0 is valid. From Markus Mayer

To generate a diff of this commit:
cvs rdiff -r1.24 -r1.25 src/sys/compat/netbsd32/netbsd32_socket.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Permalink | Reply | 0 comments |
headers
matthew green | 1 Jun 2007 02:07
Picon
Favicon

re: CVS commit: src


   On Fri, Jun 01, 2007 at 08:02:34AM +1000, Simon Burge wrote:
   > Elad Efrat wrote:
   > 
   > > also, where is the consensus of the class of programs to protect with
   > > USE_FORT taken from? and what's the reason for it?
   > 
   > While talking about this change, it is too late to change the option
   > name to "USE_FORTIFY"?  I can't see any reason for using the abbreviated
   > "FORT" in the name.

   It's long and ungainly and there's something else called FORTIFY (worse,
   I suspect it's trademarked).  But USE_FORTIFY_SOURCE is even worse.

while this may be the case, "USE_FORT" makes me think of fortran.
a better name seems in order.

.mrg.
Permalink | Reply | 1 comment |
headers
John Darrow | 1 Jun 2007 01:20

Re: CVS commit: src/usr.bin/split

On 31 May 2007 12:00:13 -0500, Jan Schaumann <jschauma <at> netmeister.org> wrote:
>Alan Barrett <apb <at> cequrux.com> wrote:
>> > Add a new command-line option "-n chunk_count", that splits the input
>> > file into chunk_count smaller files.  Each file will be size/chunk_count
>> > bytes large, with whatever spillover there is ending up in the chunk_co=
>unth
>> > file.
>>
>> If you change this line in split3() from
>>
>>         split1(sb.st_size/chunks, chunks);
>>
>> to
>>
>>         split1((sb.st_size + chunks - 1)/chunks, chunks);
>>
>> then the last file will never be larger than the others, there won't
>> be any "spillover", and you can remove all the new special cases in
>> split1().
>
>If by "all the new special cases", you mean the counting of the files
>created, then I'm not sure if using your approach does the right thing.
>
>Consider a file of 100 bytes size that you want to split into 11 files:
>
>My approach says "split bytewise into files with 100/11 =3D 9 bytes, no
>more than 11 files" (ie 10 files with 9 bytes each, one file is 10
>bytes, total # of files is 11).
>
>Your approach says "split bytewise into files with (100 + 11 - 1)/11 =3D
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jachym Holecek | 1 Jun 2007 02:50
Picon

Re: CVS commit: src/usr.bin/split

# John Darrow 2007-06-01:
> On 31 May 2007 12:00:13 -0500, Jan Schaumann <jschauma <at> netmeister.org> wrote:
> >If by "all the new special cases", you mean the counting of the files
> >created, then I'm not sure if using your approach does the right thing.
> >
> >Consider a file of 100 bytes size that you want to split into 11 files:
> >
> >My approach says "split bytewise into files with 100/11 =3D 9 bytes, no
> >more than 11 files" (ie 10 files with 9 bytes each, one file is 10
> >bytes, total # of files is 11).
> >
> >Your approach says "split bytewise into files with (100 + 11 - 1)/11 =3D
> >10 bytes" (ie 10 files with 10 bytes each).
> 
> This "miscounting" is a very rare special case, only _possibly_
> occurring when (st_size / chunks) <= chunks, and even then only for
> certain particular degenerate sizes (e.g. replacing 100 by 99 or 101
> in your example will result in his code still producing 11 files).
> 
> Normally, the number of bytes per chunk is much larger than number
> of chunks, in which case Alan's version still yields the proper number
> of chunks, and greatly simplifies the rest of the code, so I think we
> should go with it (possibly including a comment indicating awareness
> of the degenerate case).

If the user asks for N chunks than that's exactly the number of chunks
he should get. At least that seems to be POLA in this case ;-)

	-- Jachym
(Continue reading)

Permalink | Reply | 0 comments |
headers
ITOH Yasufumi | 1 Jun 2007 05:18
Picon

CVS commit: [itohy-usb1] src/sys/dev/usb


Module Name:	src
Committed By:	itohy
Date:		Fri Jun  1 03:18:04 UTC 2007

Modified Files:
	src/sys/dev/usb [itohy-usb1]: if_cdce.c if_cdcereg.h

Log Message:
Convert to use usbd_map_buffer_mbuf() and eliminate copying.
Tested, ... but it doesn't work.  Why?

arpresolve: can't allocate llinfo on cdce0 for 192.168.129.201

To generate a diff of this commit:
cvs rdiff -r1.12.10.1 -r1.12.10.2 src/sys/dev/usb/if_cdce.c
cvs rdiff -r1.2 -r1.2.40.1 src/sys/dev/usb/if_cdcereg.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Permalink | Reply | 0 comments |
headers
Michael L. Hitch | 1 Jun 2007 06:05
Picon

CVS commit: src/sys/arch/amiga/amiga


Module Name:	src
Committed By:	mhitch
Date:		Fri Jun  1 04:05:05 UTC 2007

Modified Files:
	src/sys/arch/amiga/amiga: pmap.c

Log Message:
Get rid of one more incompatibility with pmap_motorola.c from pmap_bootstrap().

To generate a diff of this commit:
cvs rdiff -r1.128 -r1.129 src/sys/arch/amiga/amiga/pmap.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Permalink | Reply | 0 comments |
headers
Nick Hudson | 1 Jun 2007 09:04
Picon

CVS commit: src/sys/arch/acorn26


Module Name:	src
Committed By:	skrll
Date:		Fri Jun  1 07:04:54 UTC 2007

Modified Files:
	src/sys/arch/acorn26/acorn26: cpuswitch.c genassym.cf locore.S
	    machdep.c
	src/sys/arch/acorn26/include: machdep.h

Log Message:
Attempt to adacpt acorn26 to idlelwp. This is untested.

OK'd by Ben Harris

To generate a diff of this commit:
cvs rdiff -r1.10 -r1.11 src/sys/arch/acorn26/acorn26/cpuswitch.c
cvs rdiff -r1.7 -r1.8 src/sys/arch/acorn26/acorn26/genassym.cf
cvs rdiff -r1.11 -r1.12 src/sys/arch/acorn26/acorn26/locore.S
cvs rdiff -r1.19 -r1.20 src/sys/arch/acorn26/acorn26/machdep.c
cvs rdiff -r1.2 -r1.3 src/sys/arch/acorn26/include/machdep.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Permalink | Reply | 0 comments |

Gmane