On Wed, Mar 05, 2008 at 05:48:57PM +, Kees Cook wrote:
> On Wed, Mar 05, 2008 at 10:16:52AM +0100, Pierre Habouzit wrote:
> > On Wed, Mar 05, 2008 at 06:16:33AM +, Kees Cook wrote:
> > > I finally got some time to run some benchmarks. I checked the results[1]
> > > into the "hardening" svn
On Wed, 05 Mar 2008, Kees Cook wrote:
> On Wed, Mar 05, 2008 at 01:29:01AM -0800, Don Armstrong wrote:
> > Just for future reference, it'd probably be better to run more than 5
> > tests of each population in the future
>
> Getting larger data sets will be rather time-consuming -- especially
> for
While these benchmarks should show any differences in raw processing
performance, there's also the question of what differences the hardening
measures make to application start-up times. PIE in particular should cause
some slowdown when the executables are first run, but it would take some
oth
On Wed, Mar 05, 2008 at 09:55:37AM -0800, Kees Cook wrote:
>>> t.test(x=c(10.87,10.873,10.854,10.809,10.877),y=c(10.807,10.824,10.963,10.84,10.838))
> What tool is this you're using?
GNU R. Takes a while to get into, but hard to beat for statistics.
>> data: c(10.87, 10.873, 10.854, 10.809, 10.8
On Wed, Mar 05, 2008 at 01:29:01AM -0800, Don Armstrong wrote:
> Just for future reference, it'd probably be better to run more than 5
> tests of each population in the future, as 5 tests means you'll only
> detect very large differences in performance at any reasonable level
> of signifigance.
I
On Wed, Mar 05, 2008 at 10:16:52AM +0100, Pierre Habouzit wrote:
> On Wed, Mar 05, 2008 at 06:16:33AM +, Kees Cook wrote:
> > I finally got some time to run some benchmarks. I checked the results[1]
> > into the "hardening" svn tree, in case other people want to contribute
> > more stuff.
>
>
On Tue, 04 Mar 2008, Kees Cook wrote:
> mplayer doesn't compile with PIE due to the various ASM routines. (I've
> noted this failure mode in the wiki[2] now.) However, with everything
> else enabled (including FORTIFY_SOURCE), there was no measurable
> difference (it was below the percentage diff
On Wed, Mar 05, 2008 at 06:16:33AM +, Kees Cook wrote:
> Hi,
>
> I finally got some time to run some benchmarks. I checked the results[1]
> into the "hardening" svn tree, in case other people want to contribute
> more stuff.
>
> On Wed, Jan 30, 2008 at 08:46:55PM +0100, Moritz Muehlenhoff wr
Hi,
I finally got some time to run some benchmarks. I checked the results[1]
into the "hardening" svn tree, in case other people want to contribute
more stuff.
On Wed, Jan 30, 2008 at 08:46:55PM +0100, Moritz Muehlenhoff wrote:
> Video:
> mplayer with the -benchmark option in conjunction with -n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/04/08 05:45, Riku Voipio wrote:
> On Sun, Feb 03, 2008 at 08:53:00PM +0100, Moritz Muehlenhoff wrote:
>> Did you followup with upstream on the SSP problems we've seen
>> on ARM?
>
> Basicly their response was basicly "why would anyone want
> 5-1
On Sun, Feb 03, 2008 at 08:53:00PM +0100, Moritz Muehlenhoff wrote:
> Did you followup with upstream on the SSP problems we've seen
> on ARM?
Basicly their response was basicly "why would anyone want
5-10% bigger and slower binaries on arm". It was also discussed
the possibility of --disable-ssp w
John Goerzen wrote:
> However, I am concerned that is appears to be limited in scope to packages
> that:
>
> * Are written in C or C++
>
> * Can have hardening achieved through technical changes to the build process
>
> I think it is important to remember that other languages can have security
Riku Voipio wrote:
>> In kernels that support text ASLR, programs compiled
>> for PIE will gain full position randomization.
>
> For which architectures is text ASLR available? does it require
> external kernel patches? PIE means considerable system overhead
> and fatter binaries, especially for sy
On Tue, Jan 29, 2008 at 09:31:00PM -0600, John Goerzen <[EMAIL PROTECTED]> was
heard to say:
> On Tuesday 29 January 2008 4:31:51 pm Yves-Alexis Perez wrote:
> > On mar, 2008-01-29 at 15:47 -0600, John Goerzen wrote:
> > > I notice, for instance, that the latest cups
> > > requires avahi. Can we
On Wed, Jan 30, 2008 at 11:41:41AM +0200, Riku Voipio wrote:
> On Tue, Jan 29, 2008 at 10:16:24PM +0100, Moritz Muehlenhoff wrote:
> > In kernels that support text ASLR, programs compiled
> > for PIE will gain full position randomization.
>
> For which architectures is text ASLR available? does it
On Wed, Jan 30, 2008 at 07:46:55PM +, Moritz Muehlenhoff wrote:
> Kees Cook wrote:
> > Does anyone have any good test harnesses we can try this on? I'd be
> > more than happy to run them on some modern hardware.
>
> Video:
> mplayer with the -benchmark option in conjunction with -nosound and
Kees Cook wrote:
> Does anyone have any good test harnesses we can try this on? I'd be
> more than happy to run them on some modern hardware.
Video:
mplayer with the -benchmark option in conjunction with -nosound and -vo.
HTML rendering:
Mike Hommey once blogged about benchmarking the ACID test:
On Tue, Jan 29, 2008 at 04:15:27PM -0800, Kees Cook wrote:
> On Tue, Jan 29, 2008 at 11:17:37PM +0100, sean finney wrote:
> In trying to not duplicate effort, I've been working both in Debian and
> Ubuntu to help get these options enabled globally.
>
> > I have to repeat the question that tfheen a
On Tue, Jan 29, 2008 at 10:16:24PM +0100, Moritz Muehlenhoff wrote:
> In kernels that support text ASLR, programs compiled
> for PIE will gain full position randomization.
For which architectures is text ASLR available? does it require
external kernel patches? PIE means considerable system overhea
On Tue, Jan 29, 2008 at 11:47:57PM +, brian m. carlson wrote:
> And now for some numbers, on an amd64 machine (/proc/cpuinfo at [0]),
Oh and I missed that at the first read, but …
> With -fPIE -pie only:
>
> MD4: 335544320 bytes in 0.741s (431.703 MiB/s)
> MD5: 335544320 bytes in 1.052s (
On Tue, Jan 29, 2008 at 11:47:57PM +, brian m. carlson wrote:
> In conclusion, there is no appreciable performance hit on any algorithm.
> Note that these are all hash algorithms, but they all make heavy use of
> memcpy, and are extremely CPU-intensive.
OTOH the memcpy they use are static
On Tuesday 29 January 2008, Moritz Muehlenhoff wrote:
> The Debian archive is the biggest of all distributions and although
> there's security support for all security issues being found, there's
> still room for improvement and a need for increased resilience against
> flaws not yet discovered.
>
On mar, 2008-01-29 at 21:31 -0600, John Goerzen wrote:
> It wound up pulling in the daemon on my box. Though it could be that
> the
> daemon was already installed because kde required it, and upgrading
> cups
> required the upgraded lib, and the daemon wouldn't work with the
> upgraded
> lib, s
On Tuesday 29 January 2008 4:31:51 pm Yves-Alexis Perez wrote:
> On mar, 2008-01-29 at 15:47 -0600, John Goerzen wrote:
> > I notice, for instance, that the latest cups
> > requires avahi. Can we build it without that and install it without
> > that by
> > default for those that don't need it, to
On Tue, Jan 29, 2008 at 11:17:37PM +0100, sean finney wrote:
> On Tuesday 29 January 2008 10:16:24 pm Moritz Muehlenhoff wrote:
> > A group of people have been working on introducing advanced security
> > hardening features into our archive:
> > http://alioth.debian.org/projects/hardening/
> >
> i
On Tue, Jan 29, 2008 at 11:45:32PM +0100, Pierre Habouzit wrote:
> * SSP has a cost proportional to the number of calls an application
> performs (If I'm correct), which in CPU intensive tasks may become an
> issue.
In testing I've done, this is trivial overhead. Note that the extra code
is o
On Tue, Jan 29, 2008 at 11:45:32PM +0100, Pierre Habouzit wrote:
On Tue, Jan 29, 2008 at 10:31:48PM +, Moritz Muehlenhoff wrote:
There are certainly performance trade-offs involved and the final
selection of features will depend on the testing of the respective
maintainers (testing should be
On Wed, 2008-01-30 at 00:21 +0100, Moritz Muehlenhoff wrote:
> Thomas Bushnell BSG wrote:
> > For my money, you blew it. You don't bootstrap a discussion by
> > presenting a pseudo-official email like the one you posted. But we can
> > get back to that discussion: cancel the email by saying "who
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Moritz Muehlenhoff wrote:
> The Debian archive is the biggest of all distributions and although
> there's security support for all security issues being found, there's
> still room for improvement and a need for increased resilience against
> flaws no
Thomas Bushnell BSG wrote:
> For my money, you blew it. You don't bootstrap a discussion by
> presenting a pseudo-official email like the one you posted. But we can
> get back to that discussion: cancel the email by saying "whoops, we're
> not ready yet" and then having the discussion first.
Of
On mar, 2008-01-29 at 15:47 -0600, John Goerzen wrote:
> I notice, for instance, that the latest cups
> requires avahi. Can we build it without that and install it without
> that by
> default for those that don't need it, to eliminate Yet Another Daemon?
You do know that it depends on the lib,
On Tue, Jan 29, 2008 at 10:31:48PM +, Moritz Muehlenhoff wrote:
> There are certainly performance trade-offs involved and the final
> selection of features will depend on the testing of the respective
> maintainers (testing should be eased by hardening-wrapper).
I understand. To be fair, I'm
On Tue, 2008-01-29 at 23:31 +0100, Moritz Muehlenhoff wrote:
> Pierre Habouzit wrote:
> There are certainly performance trade-offs involved and the final
> selection of features will depend on the testing of the respective
> maintainers (testing should be eased by hardening-wrapper).
What bothers
hi moritz,
On Tuesday 29 January 2008 10:16:24 pm Moritz Muehlenhoff wrote:
> A group of people have been working on introducing advanced security
> hardening features into our archive:
> http://alioth.debian.org/projects/hardening/
>
> We recommend to activate the following features in individual
Pierre Habouzit wrote:
>> Fortify Source
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>> This feature adds validation for internal C functions such as strcpy
>> for buffer sizes known during compile time. While vulnerabilities in
>> the functions it protects have become uncommon in high-prof
On Tue, Jan 29, 2008 at 09:48:43PM +, William Pitcock wrote:
> On Tue, 2008-01-29 at 22:37 +0100, Pierre Habouzit wrote:
> > On Tue, Jan 29, 2008 at 09:16:24PM +, Moritz Muehlenhoff wrote:
> > > Fortify Source
> > > ==
> > >
> > > This feature adds validation for internal C fun
On Tue, 2008-01-29 at 22:37 +0100, Pierre Habouzit wrote:
> On Tue, Jan 29, 2008 at 09:16:24PM +, Moritz Muehlenhoff wrote:
> > Fortify Source
> > ==
> >
> > This feature adds validation for internal C functions such as strcpy
> > for buffer sizes known during compile time. While v
On Tue January 29 2008 3:16:24 pm Moritz Muehlenhoff wrote:
> Scope of this proposal
> ==
>
> The target for Lenny is to enable these features in all applications
> with potential security impact, specifically:
>
> - Your application is written in C / C++
> - If your package wa
On Tue, Jan 29, 2008 at 09:16:24PM +, Moritz Muehlenhoff wrote:
> Fortify Source
> ==
>
> This feature adds validation for internal C functions such as strcpy
> for buffer sizes known during compile time. While vulnerabilities in
> the functions it protects have become uncommon in
39 matches
Mail list logo
