From owner-freebsd-security@FreeBSD.ORG Sun Apr 15 11:20:37 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66924106566B for ; Sun, 15 Apr 2012 11:20:37 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 1A03B8FC0A for ; Sun, 15 Apr 2012 11:20:37 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SJNVU-0005k1-0d>; Sun, 15 Apr 2012 13:20:36 +0200 Received: from e178032100.adsl.alicedsl.de ([85.178.32.100] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SJNVT-0003Ca-RU>; Sun, 15 Apr 2012 13:20:36 +0200 Message-ID: <4F8AAEF7.3090800@zedat.fu-berlin.de> Date: Sun, 15 Apr 2012 13:20:23 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Richard Kojedzinszky References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF0D98E26C984CBD583EA5B0C" X-Originating-IP: 85.178.32.100 Cc: freebsd-security@freebsd.org Subject: Re: ufs multilabel performance (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 11:20:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF0D98E26C984CBD583EA5B0C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04/14/12 21:37, schrieb Richard Kojedzinszky: > Dear list, >=20 > Although it is not only security-related question, I did not get any > answer from freebsd-performance. The original question is below. >=20 > Can someone give some advice? >=20 > Thanks in advance, >=20 >=20 > Kojedzinszky Richard > Euronet Magyarorszag Informatikai Zrt. >=20 > ---------- Forwarded message ---------- > Date: Thu, 10 Nov 2011 06:16:57 +0100 (CET) > From: Richard Kojedzinszky > To: freebsd-performance@freebsd.org > Subject: ufs multilabel performance >=20 > Dear List, >=20 > I've noticed that when I enable multilabel on an fs, a file creation > gets around 20-30 times slower than without multilabel set. >=20 > This one-liner can be used to test the differences: > $ truss -D perl -e 'open(F, ">$_.file") for 1 .. 1000' Same here, creating files seems to be 10 - 30 times slower with multilabels as it is without. But as several posts and discussions reflects, FreeBSD isn't supposed to be fast although it is claimed that writing is the major than reading; FBSD should serve functionality. >=20 > And one can see that the open call takes much more when multilabel is > set on an fs. It seems that only file creation needs that many time, > when a file exists it is opened much faster. >=20 > Could someone acknowledge this, and have some suggestions how to make i= t > faster? >=20 > Regards, >=20 >=20 > Kojedzinszky Richard > TvNetWork Nyrt. > E-mail: krichy (at) tvnetwork [dot] hu > PGP: 0x54B2BF0C8F59B1B7 > Fingerprint =3D F6D4 3FFE AF03 CACF 0DCB 46A1 54B2 BF0C 8F59 B1B7 > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.= org" --------------enigF0D98E26C984CBD583EA5B0C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPiq8DAAoJEOgBcD7A/5N8CMIIAJDE2q87nR7cdwrxNdZnJtl3 +VL5xs13MD5/2TLLpwjFnwFUT0JfEWLHGt9L8eQSQq6Ec4ZJdooyfdjzdYN9Q8NO ykd4lUjnPeEzcUdjjiftY8BFsHomMM8PHZi9GDROJnzPT1c29GxNXLafwZxDGPq0 DvnKDXMjLaYf/SE1MKRIofyzXwJHsu7nbLcQJj4ZOv+W5FMkRwqIadFMux2VhNxc nAVPK1CVsoc8o1BVY2h5GGQ+Z6ww0WYgJYr/ekkwNAOxh3xFDklxQgNPuIOSwhMt VlQXUie5esAjaQ8PDRC14lHSEhCALgT27lTtGqWI9CageTgxljfkncZ+IY9xUiY= =dMKB -----END PGP SIGNATURE----- --------------enigF0D98E26C984CBD583EA5B0C-- From owner-freebsd-security@FreeBSD.ORG Sun Apr 15 13:59:57 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0952106566B for ; Sun, 15 Apr 2012 13:59:57 +0000 (UTC) (envelope-from krichy@tvnetwork.hu) Received: from krichy.tvnetwork.hu (unknown [IPv6:2a01:be00:0:2::10]) by mx1.freebsd.org (Postfix) with ESMTP id 4FA6E8FC0C for ; Sun, 15 Apr 2012 13:59:56 +0000 (UTC) Received: by krichy.tvnetwork.hu (Postfix, from userid 1000) id C4189216B2; Sun, 15 Apr 2012 15:59:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by krichy.tvnetwork.hu (Postfix) with ESMTP id BA266203CC; Sun, 15 Apr 2012 15:59:55 +0200 (CEST) Date: Sun, 15 Apr 2012 15:59:55 +0200 (CEST) From: Richard Kojedzinszky To: "O. Hartmann" In-Reply-To: <4F8AAEF7.3090800@zedat.fu-berlin.de> Message-ID: References: <4F8AAEF7.3090800@zedat.fu-berlin.de> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-security@freebsd.org Subject: Re: ufs multilabel performance (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 13:59:57 -0000 Thank you for the reply. Unfortunately, dont know why, but on my xen virtualised environment, fbsd amd64 domU performs much slower, not only 30 times. Without multilabel, file creation speed is around 2500/s, but with multilabels enabled, it is only 15/s (!). so it is more than 100 times slower. And anyway freebsd is known to be fast as well, as functional. The power to serve. :) But in my environment, 15/s file creation is very-very slow. The hardware is a q6700 cpu with 4G ram, 2x1T sata disks in raid1, the host runs linux. I think with this hw the mentioned speed is really slow. Regards, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. On Sun, 15 Apr 2012, O. Hartmann wrote: > Date: Sun, 15 Apr 2012 13:20:23 +0200 > From: O. Hartmann > To: Richard Kojedzinszky > Cc: freebsd-security@freebsd.org > Subject: Re: ufs multilabel performance (fwd) > > Am 04/14/12 21:37, schrieb Richard Kojedzinszky: >> Dear list, >> >> Although it is not only security-related question, I did not get any >> answer from freebsd-performance. The original question is below. >> >> Can someone give some advice? >> >> Thanks in advance, >> >> >> Kojedzinszky Richard >> Euronet Magyarorszag Informatikai Zrt. >> >> ---------- Forwarded message ---------- >> Date: Thu, 10 Nov 2011 06:16:57 +0100 (CET) >> From: Richard Kojedzinszky >> To: freebsd-performance@freebsd.org >> Subject: ufs multilabel performance >> >> Dear List, >> >> I've noticed that when I enable multilabel on an fs, a file creation >> gets around 20-30 times slower than without multilabel set. >> >> This one-liner can be used to test the differences: >> $ truss -D perl -e 'open(F, ">$_.file") for 1 .. 1000' > > Same here, creating files seems to be 10 - 30 times slower with > multilabels as it is without. > > But as several posts and discussions reflects, FreeBSD isn't supposed to > be fast although it is claimed that writing is the major than reading; > FBSD should serve functionality. >> >> And one can see that the open call takes much more when multilabel is >> set on an fs. It seems that only file creation needs that many time, >> when a file exists it is opened much faster. >> >> Could someone acknowledge this, and have some suggestions how to make it >> faster? >> >> Regards, >> >> >> Kojedzinszky Richard >> TvNetWork Nyrt. >> E-mail: krichy (at) tvnetwork [dot] hu >> PGP: 0x54B2BF0C8F59B1B7 >> Fingerprint = F6D4 3FFE AF03 CACF 0DCB 46A1 54B2 BF0C 8F59 B1B7 >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > > From owner-freebsd-security@FreeBSD.ORG Sun Apr 15 19:30:33 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA169106566C; Sun, 15 Apr 2012 19:30:33 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 46F9B8FC18; Sun, 15 Apr 2012 19:30:33 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SJV9c-0002Gk-6n>; Sun, 15 Apr 2012 21:30:32 +0200 Received: from e178030137.adsl.alicedsl.de ([85.178.30.137] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SJV9c-0001zn-0J>; Sun, 15 Apr 2012 21:30:32 +0200 Message-ID: <4F8B21D2.4080008@zedat.fu-berlin.de> Date: Sun, 15 Apr 2012 21:30:26 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Richard Kojedzinszky References: <4F8AAEF7.3090800@zedat.fu-berlin.de> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigACA75699F447BB9326077DB3" X-Originating-IP: 85.178.30.137 Cc: freebsd-security@freebsd.org, freebsd-performance@freebsd.org, Current FreeBSD Subject: Re: ufs multilabel performance (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 19:30:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigACA75699F447BB9326077DB3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04/15/12 15:59, schrieb Richard Kojedzinszky: > Thank you for the reply. >=20 > Unfortunately, dont know why, but on my xen virtualised environment, > fbsd amd64 domU performs much slower, not only 30 times. Without > multilabel, file creation speed is around 2500/s, but with multilabels > enabled, it is only 15/s (!). so it is more than 100 times slower. >=20 > And anyway freebsd is known to be fast as well, as functional. The powe= r > to serve. :) >=20 > But in my environment, 15/s file creation is very-very slow. The > hardware is a q6700 cpu with 4G ram, 2x1T sata disks in raid1, the host= > runs linux. I think with this hw the mentioned speed is really slow. >=20 > Regards, >=20 >=20 > Kojedzinszky Richard > Euronet Magyarorszag Informatikai Zrt. >=20 > On Sun, 15 Apr 2012, O. Hartmann wrote: >=20 >> Date: Sun, 15 Apr 2012 13:20:23 +0200 >> From: O. Hartmann >> To: Richard Kojedzinszky >> Cc: freebsd-security@freebsd.org >> Subject: Re: ufs multilabel performance (fwd) >> >> Am 04/14/12 21:37, schrieb Richard Kojedzinszky: >>> Dear list, >>> >>> Although it is not only security-related question, I did not get any >>> answer from freebsd-performance. The original question is below. >>> >>> Can someone give some advice? >>> >>> Thanks in advance, >>> >>> >>> Kojedzinszky Richard >>> Euronet Magyarorszag Informatikai Zrt. >>> >>> ---------- Forwarded message ---------- >>> Date: Thu, 10 Nov 2011 06:16:57 +0100 (CET) >>> From: Richard Kojedzinszky >>> To: freebsd-performance@freebsd.org >>> Subject: ufs multilabel performance >>> >>> Dear List, >>> >>> I've noticed that when I enable multilabel on an fs, a file creation >>> gets around 20-30 times slower than without multilabel set. >>> >>> This one-liner can be used to test the differences: >>> $ truss -D perl -e 'open(F, ">$_.file") for 1 .. 1000' >> >> Same here, creating files seems to be 10 - 30 times slower with >> multilabels as it is without. >> >> But as several posts and discussions reflects, FreeBSD isn't supposed = to >> be fast although it is claimed that writing is the major than reading;= >> FBSD should serve functionality. >>> >>> And one can see that the open call takes much more when multilabel is= >>> set on an fs. It seems that only file creation needs that many time, >>> when a file exists it is opened much faster. >>> >>> Could someone acknowledge this, and have some suggestions how to make= it >>> faster? >>> >>> Regards, >>> >>> >>> Kojedzinszky Richard >>> TvNetWork Nyrt. >>> E-mail: krichy (at) tvnetwork [dot] hu >>> PGP: 0x54B2BF0C8F59B1B7 >>> Fingerprint =3D F6D4 3FFE AF03 CACF 0DCB 46A1 54B2 BF0C 8F59 B1B7 At the moment, I'm troubled with a nasty kernel bug on all FreeBSD 10 boxes I have spare to test. I just tried to reproduce your observation and as far as I can go with my experience, I can confirm that by using your perl script. I'd like to test this again with a small C program. I can only test the issue (test is too far optimistic, it's simply a reproduction of your observation) on FreeBSD 10, the only remaining FreeBSD server at our department is running FBSD 9-STABLE/amd64 and "in production", so changing multilabel support is a bit harsh at the moment.= Sorry about crossposting, but I think this belongs more to CURRENT and PERFORMANCE than SECURITY. Regards, Oliver --------------enigACA75699F447BB9326077DB3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPiyHXAAoJEOgBcD7A/5N8LrsIANmL3ZmRs4NV+ZcwYgEMbON2 FoofUvnxCWi+U8v7WDxjkgzhB9gZZSCB6Sg96rsqRM1Koac4CeYSegrNU93Cs1q5 E8kKIrwxqamfSTe1a8zRmD2xQm6jRea3SLs7YyDhNVus24lwvsXrQO+raigkw+mF +ZXb3dFDnJtPZwJf22iiuQUsPCEwsYj4L9NUX//kW/AIvAYmeItKSGs1KEUqQ14D Gi5bhcGyFykR4/AlXCXGmw0reQuS8bBFl8gfKbQCi9ksZdZ5ZuTqU8NSZoUsZZUZ piPLowl8mLVqdNJVh6kSdLNp5L7UuUEXzMYpxmpXhV3poAdWIU/AoT2OxxZwrmM= =kwTn -----END PGP SIGNATURE----- --------------enigACA75699F447BB9326077DB3-- From owner-freebsd-security@FreeBSD.ORG Sun Apr 15 20:17:16 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66B35106566B; Sun, 15 Apr 2012 20:17:16 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 05A238FC0C; Sun, 15 Apr 2012 20:17:16 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1SJVso-000749-V3>; Sun, 15 Apr 2012 22:17:15 +0200 Received: from e178030137.adsl.alicedsl.de ([85.178.30.137] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1SJVso-0004Jy-O1>; Sun, 15 Apr 2012 22:17:14 +0200 Message-ID: <4F8B2CC4.5030601@zedat.fu-berlin.de> Date: Sun, 15 Apr 2012 22:17:08 +0200 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Garrett Cooper References: <4F8AAEF7.3090800@zedat.fu-berlin.de> <4F8B21D2.4080008@zedat.fu-berlin.de> <951B1A8C-A216-420A-BA17-316B8D9C2B0E@gmail.com> In-Reply-To: <951B1A8C-A216-420A-BA17-316B8D9C2B0E@gmail.com> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F6C5458A718E52245A69775" X-Originating-IP: 85.178.30.137 Cc: freebsd-security@freebsd.org, Richard Kojedzinszky , Current FreeBSD , freebsd-performance@freebsd.org Subject: Re: ufs multilabel performance (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 20:17:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F6C5458A718E52245A69775 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 04/15/12 22:00, schrieb Garrett Cooper: > On Apr 15, 2012, at 12:30 PM, O. Hartmann wrote: >=20 >> Am 04/15/12 15:59, schrieb Richard Kojedzinszky: >>> Thank you for the reply. >>> >>> Unfortunately, dont know why, but on my xen virtualised environment, >>> fbsd amd64 domU performs much slower, not only 30 times. Without >>> multilabel, file creation speed is around 2500/s, but with multilabel= s >>> enabled, it is only 15/s (!). so it is more than 100 times slower. >>> >>> And anyway freebsd is known to be fast as well, as functional. The po= wer >>> to serve. :) >>> >>> But in my environment, 15/s file creation is very-very slow. The >>> hardware is a q6700 cpu with 4G ram, 2x1T sata disks in raid1, the ho= st >>> runs linux. I think with this hw the mentioned speed is really slow. >>> >>> Regards, >>> >>> >>> Kojedzinszky Richard >>> Euronet Magyarorszag Informatikai Zrt. >>> >>> On Sun, 15 Apr 2012, O. Hartmann wrote: >>> >>>> Date: Sun, 15 Apr 2012 13:20:23 +0200 >>>> From: O. Hartmann >>>> To: Richard Kojedzinszky >>>> Cc: freebsd-security@freebsd.org >>>> Subject: Re: ufs multilabel performance (fwd) >>>> >>>> Am 04/14/12 21:37, schrieb Richard Kojedzinszky: >>>>> Dear list, >>>>> >>>>> Although it is not only security-related question, I did not get an= y >>>>> answer from freebsd-performance. The original question is below. >>>>> >>>>> Can someone give some advice? >>>>> >>>>> Thanks in advance, >>>>> >>>>> >>>>> Kojedzinszky Richard >>>>> Euronet Magyarorszag Informatikai Zrt. >>>>> >>>>> ---------- Forwarded message ---------- >>>>> Date: Thu, 10 Nov 2011 06:16:57 +0100 (CET) >>>>> From: Richard Kojedzinszky >>>>> To: freebsd-performance@freebsd.org >>>>> Subject: ufs multilabel performance >>>>> >>>>> Dear List, >>>>> >>>>> I've noticed that when I enable multilabel on an fs, a file creatio= n >>>>> gets around 20-30 times slower than without multilabel set. >>>>> >>>>> This one-liner can be used to test the differences: >>>>> $ truss -D perl -e 'open(F, ">$_.file") for 1 .. 1000' >>>> >>>> Same here, creating files seems to be 10 - 30 times slower with >>>> multilabels as it is without. >>>> >>>> But as several posts and discussions reflects, FreeBSD isn't suppose= d to >>>> be fast although it is claimed that writing is the major than readin= g; >>>> FBSD should serve functionality. >>>>> >>>>> And one can see that the open call takes much more when multilabel = is >>>>> set on an fs. It seems that only file creation needs that many time= , >>>>> when a file exists it is opened much faster. >>>>> >>>>> Could someone acknowledge this, and have some suggestions how to ma= ke it >>>>> faster? >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Kojedzinszky Richard >>>>> TvNetWork Nyrt. >>>>> E-mail: krichy (at) tvnetwork [dot] hu >>>>> PGP: 0x54B2BF0C8F59B1B7 >>>>> Fingerprint =3D F6D4 3FFE AF03 CACF 0DCB 46A1 54B2 BF0C 8F59 B1B7= >> >> At the moment, I'm troubled with a nasty kernel bug on all FreeBSD 10 >> boxes I have spare to test. >> >> I just tried to reproduce your observation and as far as I can go with= >> my experience, I can confirm that by using your perl script. >> >> I'd like to test this again with a small C program. >> >> I can only test the issue (test is too far optimistic, it's simply a >> reproduction of your observation) on FreeBSD 10, the only remaining >> FreeBSD server at our department is running FBSD 9-STABLE/amd64 and "i= n >> production", so changing multilabel support is a bit harsh at the mome= nt. >> >> >> Sorry about crossposting, but I think this belongs more to CURRENT and= >> PERFORMANCE than SECURITY. >=20 > My suggestion is completely take perl out of the equation because the w= ay you're invoking it above uses stdio and a few other things that add un= necessary overhead. >=20 > Try the attached C program/bourne shell snippet instead. >=20 > Cheers, > -Garrett >=20 > #!/bin/sh >=20 > set -e >=20 > tmp=3D$(mktemp -d tmp.XXXXXX) > trap "cd /; rm -Rf $tmp" EXIT > cd $tmp >=20 > cat > test_open.c <=20 > #include > #include > #include >=20 > int > main(void) > { > char buf[20]; > int i; >=20 > for (i =3D 0; i < 1000; i++) { > sprintf(buf, "%d", i); > close(open(buf, O_WRONLY|O_CREAT, 0600)); > } > return (0); > } > EOF >=20 > gcc -o test_open test_open.c > time ./test_open_______________________________________________ This was pretty fast ;-) --------------enig8F6C5458A718E52245A69775 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJPiyzJAAoJEOgBcD7A/5N88K4IAM1Ta4DbIuYJHdbJ7TYYqPCF cfM24slE0SikRQLxpNAtcm2gnVELhwxDiKbkFuM3277pmL9gpWhoLvJoLuCcNEo3 UKsr6YHzxfIPgcv61JhRzhyki0ETdjKbZorMpfhQAGfI1ssQQ824mMMTvWfMSOu2 x6wJ+d0pPZGlWRRkfhVUYZBaqdfj/OuM7pIq+COAU12UhZySt+4srryMeDJDzQNU Dv7ile+FrXCQ8yrqy9nbeyRJJlPpDqnb7eQS/7d78hlnzL8tFXT6XaxOZGvB3NM2 Ej2pmGqvju+TvO9LI/CemsnEJByHmJNkFWiOTMpyrHhoCgIqr8NB7SzH98Vt5j8= =j3k7 -----END PGP SIGNATURE----- --------------enig8F6C5458A718E52245A69775-- From owner-freebsd-security@FreeBSD.ORG Sun Apr 15 20:50:26 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCE6D106564A; Sun, 15 Apr 2012 20:50:26 +0000 (UTC) (envelope-from krichy@tvnetwork.hu) Received: from krichy.tvnetwork.hu (krichy.tvnetwork.hu [109.61.101.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4C90A8FC0A; Sun, 15 Apr 2012 20:50:26 +0000 (UTC) Received: by krichy.tvnetwork.hu (Postfix, from userid 1000) id B07F7216B2; Sun, 15 Apr 2012 22:50:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by krichy.tvnetwork.hu (Postfix) with ESMTP id A6A4520096; Sun, 15 Apr 2012 22:50:18 +0200 (CEST) Date: Sun, 15 Apr 2012 22:50:18 +0200 (CEST) From: Richard Kojedzinszky To: Garrett Cooper In-Reply-To: <28768C15-C694-4C09-8CD1-3F5412554B55@gmail.com> Message-ID: References: <4F8AAEF7.3090800@zedat.fu-berlin.de> <4F8B21D2.4080008@zedat.fu-berlin.de> <951B1A8C-A216-420A-BA17-316B8D9C2B0E@gmail.com> <4F8B2CC4.5030601@zedat.fu-berlin.de> <28768C15-C694-4C09-8CD1-3F5412554B55@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-security@freebsd.org, freebsd-performance@freebsd.org, Current FreeBSD , "O. Hartmann" Subject: Re: ufs multilabel performance (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 20:50:27 -0000 Thanks for the replies. I dont think so that perl counts anything in the test, just run the code with truss -D, you will see the timing that the open() syscall takes just more time with multilabel enabled. Even a single touch shows that: # truss -D touch 1 0.000056431 mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366259200 (0x800638000) 0.000020672 issetugid(0x800639015,0x80062e4be,0x80084a0b0,0x80084a080,0xab57,0x0) = 0 (0x0) 0.000060342 open("/etc/libmap.conf",O_RDONLY,0666) ERR#2 'No such file or directory' 0.000032964 open("/var/run/ld-elf.so.hints",O_RDONLY,057) = 3 (0x3) 0.000029891 read(3,"Ehnt\^A\0\0\0\M^@\0\0\0-\0\0\0\0"...,128) = 128 (0x80) 0.000063135 lseek(3,0x80,SEEK_SET) = 128 (0x80) 0.000040228 read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,45) = 45 (0x2d) 0.000034361 close(3) = 0 (0x0) 0.000031288 access("/lib/libc.so.7",0) = 0 (0x0) 0.000038551 open("/lib/libc.so.7",O_RDONLY,040754040) = 3 (0x3) 0.000045256 fstat(3,{ mode=-r--r--r-- ,inode=4107,size=1306952,blksize=32768 }) = 0 (0x0) 0.000031847 pread(0x3,0x80083c800,0x1000,0x0,0x101010101010101,0x8080808080808080) = 4096 (0x1000) 0.000024025 mmap(0x0,3420160,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 34368434176 (0x80084b000) 0.000055872 mmap(0x80084b000,1171456,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0) = 34368434176 (0x80084b000) 0.000046095 mmap(0x800b68000,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x11d000) = 34371698688 (0x800b68000) 0.000022628 mmap(0x800b73000,110592,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 34371743744 (0x800b73000) 0.000022069 close(3) = 0 (0x0) 0.000024584 munmap(0x80063f000,4096) = 0 (0x0) 0.000030450 mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366287872 (0x80063f000) 0.000036875 sysarch(0x81,0x7fffffffd450,0x80063c0c8,0x0,0xffffffffffad2228,0x8080808080808080) = 0 (0x0) 0.000041345 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 0.000065370 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 0.000041066 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 0.000032685 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 0.000051681 readlink("/etc/malloc.conf",0x7fffffffd5e0,1024) ERR#2 'No such file or directory' 0.000020393 issetugid(0x800945101,0x7fffffffd5e0,0xffffffffffffffff,0x0,0x2,0x7fffffffef79) = 0 (0x0) 0.000025143 break(0x800000) = 0 (0x0) 0.000024863 mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34371854336 (0x800b8e000) 0.000038273 mmap(0x800f8e000,466944,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34376048640 (0x800f8e000) 0.000025142 munmap(0x800b8e000,466944) = 0 (0x0) 0.000025143 gettimeofday({1334522860.892157 },0x0) = 0 (0x0) 0.000042463 stat("1",0x7fffffffdb10) ERR#2 'No such file or directory' 0.116764212 open("1",O_WRONLY|O_CREAT,0666) = 3 (0x3) 0.000025701 fstat(3,{ mode=-rw-r--r-- ,inode=5,size=0,blksize=32768 }) = 0 (0x0) 0.000026819 close(3) = 0 (0x0) 0.000021231 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 0.000026818 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 0.000020952 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 0.000032127 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) -1.999864511 process exit, rval = 0 Can you see the open()'s spent time? Without multilabel: # truss -D touch 1 0.000078779 mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366259200 (0x800638000) 0.000053078 issetugid(0x800639015,0x80062e4be,0x80084a0b0,0x80084a080,0xab57,0x0) = 0 (0x0) 0.000078500 open("/etc/libmap.conf",O_RDONLY,0666) ERR#2 'No such file or directory' 0.000039390 open("/var/run/ld-elf.so.hints",O_RDONLY,057) = 3 (0x3) 0.000034920 read(3,"Ehnt\^A\0\0\0\M^@\0\0\0-\0\0\0\0"...,128) = 128 (0x80) 0.000031847 lseek(3,0x80,SEEK_SET) = 128 (0x80) 0.000029612 read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,45) = 45 (0x2d) 0.000053357 close(3) = 0 (0x0) 0.000040508 access("/lib/libc.so.7",0) = 0 (0x0) 0.000035758 open("/lib/libc.so.7",O_RDONLY,040754040) = 3 (0x3) 0.000057828 fstat(3,{ mode=-r--r--r-- ,inode=4107,size=1306952,blksize=32768 }) = 0 (0x0) 0.000037713 pread(0x3,0x80083c800,0x1000,0x0,0x101010101010101,0x8080808080808080) = 4096 (0x1000) 0.000075986 mmap(0x0,3420160,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 34368434176 (0x80084b000) 0.000031568 mmap(0x80084b000,1171456,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0) = 34368434176 (0x80084b000) 0.000048888 mmap(0x800b68000,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x11d000) = 34371698688 (0x800b68000) 0.000027656 mmap(0x800b73000,110592,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 34371743744 (0x800b73000) 0.000032405 close(3) = 0 (0x0) 0.000033244 munmap(0x80063f000,4096) = 0 (0x0) 0.000032406 mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366287872 (0x80063f000) 0.000043301 sysarch(0x81,0x7fffffffd450,0x80063c0c8,0x0,0xffffffffffad2228,0x8080808080808080) = 0 (0x0) 0.000032405 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 0.000028495 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 0.000068443 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 0.000030450 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 0.000084925 readlink("/etc/malloc.conf",0x7fffffffd5e0,1024) ERR#2 'No such file or directory' 0.000024304 issetugid(0x800945101,0x7fffffffd5e0,0xffffffffffffffff,0x0,0x2,0x7fffffffef79) = 0 (0x0) 0.000029891 break(0x800000) = 0 (0x0) 0.000029054 mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34371854336 (0x800b8e000) 0.000025701 mmap(0x800f8e000,466944,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34376048640 (0x800f8e000) 0.000063135 munmap(0x800b8e000,466944) = 0 (0x0) 0.000030171 gettimeofday({1334522939.716792 },0x0) = 0 (0x0) 0.000464296 stat("1",0x7fffffffdb10) ERR#2 'No such file or directory' 0.000612356 open("1",O_WRONLY|O_CREAT,0666) = 3 (0x3) 0.000034082 fstat(3,{ mode=-rw-r--r-- ,inode=4,size=0,blksize=32768 }) = 0 (0x0) 0.000058945 close(3) = 0 (0x0) 0.000027377 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 0.000032685 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 0.000026818 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 0.000023746 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) -1.999924294 process exit, rval = 0 Maybe the factor is not this much in real installations, not as in my domU, but still it is slow. Regards, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. On Sun, 15 Apr 2012, Garrett Cooper wrote: > Date: Sun, 15 Apr 2012 13:35:59 -0700 > From: Garrett Cooper > To: O. Hartmann > Cc: freebsd-security@freebsd.org, Richard Kojedzinszky , > Current FreeBSD , > freebsd-performance@freebsd.org > Subject: Re: ufs multilabel performance (fwd) > > On Apr 15, 2012, at 1:17 PM, O. Hartmann wrote: > >> Am 04/15/12 22:00, schrieb Garrett Cooper: >>> On Apr 15, 2012, at 12:30 PM, O. Hartmann wrote: >>> >>>> Am 04/15/12 15:59, schrieb Richard Kojedzinszky: >>>>> Thank you for the reply. >>>>> >>>>> Unfortunately, dont know why, but on my xen virtualised environment, >>>>> fbsd amd64 domU performs much slower, not only 30 times. Without >>>>> multilabel, file creation speed is around 2500/s, but with multilabels >>>>> enabled, it is only 15/s (!). so it is more than 100 times slower. >>>>> >>>>> And anyway freebsd is known to be fast as well, as functional. The power >>>>> to serve. :) >>>>> >>>>> But in my environment, 15/s file creation is very-very slow. The >>>>> hardware is a q6700 cpu with 4G ram, 2x1T sata disks in raid1, the host >>>>> runs linux. I think with this hw the mentioned speed is really slow. >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Kojedzinszky Richard >>>>> Euronet Magyarorszag Informatikai Zrt. >>>>> >>>>> On Sun, 15 Apr 2012, O. Hartmann wrote: >>>>> >>>>>> Date: Sun, 15 Apr 2012 13:20:23 +0200 >>>>>> From: O. Hartmann >>>>>> To: Richard Kojedzinszky >>>>>> Cc: freebsd-security@freebsd.org >>>>>> Subject: Re: ufs multilabel performance (fwd) >>>>>> >>>>>> Am 04/14/12 21:37, schrieb Richard Kojedzinszky: >>>>>>> Dear list, >>>>>>> >>>>>>> Although it is not only security-related question, I did not get any >>>>>>> answer from freebsd-performance. The original question is below. >>>>>>> >>>>>>> Can someone give some advice? >>>>>>> >>>>>>> Thanks in advance, >>>>>>> >>>>>>> >>>>>>> Kojedzinszky Richard >>>>>>> Euronet Magyarorszag Informatikai Zrt. >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> Date: Thu, 10 Nov 2011 06:16:57 +0100 (CET) >>>>>>> From: Richard Kojedzinszky >>>>>>> To: freebsd-performance@freebsd.org >>>>>>> Subject: ufs multilabel performance >>>>>>> >>>>>>> Dear List, >>>>>>> >>>>>>> I've noticed that when I enable multilabel on an fs, a file creation >>>>>>> gets around 20-30 times slower than without multilabel set. >>>>>>> >>>>>>> This one-liner can be used to test the differences: >>>>>>> $ truss -D perl -e 'open(F, ">$_.file") for 1 .. 1000' >>>>>> >>>>>> Same here, creating files seems to be 10 - 30 times slower with >>>>>> multilabels as it is without. >>>>>> >>>>>> But as several posts and discussions reflects, FreeBSD isn't supposed to >>>>>> be fast although it is claimed that writing is the major than reading; >>>>>> FBSD should serve functionality. >>>>>>> >>>>>>> And one can see that the open call takes much more when multilabel is >>>>>>> set on an fs. It seems that only file creation needs that many time, >>>>>>> when a file exists it is opened much faster. >>>>>>> >>>>>>> Could someone acknowledge this, and have some suggestions how to make it >>>>>>> faster? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> Kojedzinszky Richard >>>>>>> TvNetWork Nyrt. >>>>>>> E-mail: krichy (at) tvnetwork [dot] hu >>>>>>> PGP: 0x54B2BF0C8F59B1B7 >>>>>>> Fingerprint = F6D4 3FFE AF03 CACF 0DCB 46A1 54B2 BF0C 8F59 B1B7 >>>> >>>> At the moment, I'm troubled with a nasty kernel bug on all FreeBSD 10 >>>> boxes I have spare to test. >>>> >>>> I just tried to reproduce your observation and as far as I can go with >>>> my experience, I can confirm that by using your perl script. >>>> >>>> I'd like to test this again with a small C program. >>>> >>>> I can only test the issue (test is too far optimistic, it's simply a >>>> reproduction of your observation) on FreeBSD 10, the only remaining >>>> FreeBSD server at our department is running FBSD 9-STABLE/amd64 and "in >>>> production", so changing multilabel support is a bit harsh at the moment. >>>> >>>> >>>> Sorry about crossposting, but I think this belongs more to CURRENT and >>>> PERFORMANCE than SECURITY. >>> >>> My suggestion is completely take perl out of the equation because the way you're invoking it above uses stdio and a few other things that add unnecessary overhead. >>> >>> Try the attached C program/bourne shell snippet instead. >>> >>> Cheers, >>> -Garrett >>> >>> #!/bin/sh >>> >>> set -e >>> >>> tmp=$(mktemp -d tmp.XXXXXX) >>> trap "cd /; rm -Rf $tmp" EXIT >>> cd $tmp >>> >>> cat > test_open.c <>> >>> #include >>> #include >>> #include >>> >>> int >>> main(void) >>> { >>> char buf[20]; >>> int i; >>> >>> for (i = 0; i < 1000; i++) { >>> sprintf(buf, "%d", i); >>> close(open(buf, O_WRONLY|O_CREAT, 0600)); >>> } >>> return (0); >>> } >>> EOF >>> >>> gcc -o test_open test_open.c >>> time ./test_open_______________________________________________ >> >> This was pretty fast ;-) > > If it turns out that it wasn't that particular item that's causing a slowdown, I can easily modify my above snippet to use stdio, etc. But unless the version of perl and a few other items are the same, I wouldn't necessarily blame the guest OS. Please also make sure that Xen, etc is completely up-to-date because there were some performance degradation issues that were fixed post-6.0. > -Garrett From owner-freebsd-security@FreeBSD.ORG Sun Apr 15 20:00:53 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41BA4106566B; Sun, 15 Apr 2012 20:00:53 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D87438FC15; Sun, 15 Apr 2012 20:00:52 +0000 (UTC) Received: by obqv19 with SMTP id v19so5391943obq.13 for ; Sun, 15 Apr 2012 13:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=mnralVivXlJvciH+6DBucC8H6Pz/CSSQecoxTjyy138=; b=mYjK1C+WkQoFoDi4ma0qJyO2g4WkuiBMHGUMR/QeIAgxz5mWH8LCvsi3RdNguBPWOX TgEezvSScz+pDZUXJII2xzXBqfRMlOPEnKRsB8LsR/lv1N0qCGsF8OeQOjvUDeC59b45 wgNeTfctmtK9kBIkRZCGtS5ySQCu7CMGLY5XFMCxnpTH3c5FhGHqvhbHwBdQAc1uAbMO IHaqKRV++pbYUI0w7xJwwBXTK9yDuy+W1DWDz7s+a4Dreb2NC4QUVEZeCiAIEnj+CKu9 F3qMHaRjLADyvMtKsRgaK2n03pKYYJGSEtqOqByQ/A0rjjW/lqkRATGqMoYtuXU8SzkM 79ow== Received: by 10.182.169.68 with SMTP id ac4mr12587579obc.19.1334520052529; Sun, 15 Apr 2012 13:00:52 -0700 (PDT) Received: from [192.168.2.5] (dpc691939029.direcpc.com. [69.19.39.29]) by mx.google.com with ESMTPS id by5sm17138512obb.19.2012.04.15.13.00.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Apr 2012 13:00:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Garrett Cooper In-Reply-To: <4F8B21D2.4080008@zedat.fu-berlin.de> Date: Sun, 15 Apr 2012 13:00:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <951B1A8C-A216-420A-BA17-316B8D9C2B0E@gmail.com> References: <4F8AAEF7.3090800@zedat.fu-berlin.de> <4F8B21D2.4080008@zedat.fu-berlin.de> To: O. Hartmann X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Sun, 15 Apr 2012 20:59:04 +0000 Cc: freebsd-security@freebsd.org, Richard Kojedzinszky , Current FreeBSD , freebsd-performance@freebsd.org Subject: Re: ufs multilabel performance (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 20:00:53 -0000 On Apr 15, 2012, at 12:30 PM, O. Hartmann wrote: > Am 04/15/12 15:59, schrieb Richard Kojedzinszky: >> Thank you for the reply. >>=20 >> Unfortunately, dont know why, but on my xen virtualised environment, >> fbsd amd64 domU performs much slower, not only 30 times. Without >> multilabel, file creation speed is around 2500/s, but with = multilabels >> enabled, it is only 15/s (!). so it is more than 100 times slower. >>=20 >> And anyway freebsd is known to be fast as well, as functional. The = power >> to serve. :) >>=20 >> But in my environment, 15/s file creation is very-very slow. The >> hardware is a q6700 cpu with 4G ram, 2x1T sata disks in raid1, the = host >> runs linux. I think with this hw the mentioned speed is really slow. >>=20 >> Regards, >>=20 >>=20 >> Kojedzinszky Richard >> Euronet Magyarorszag Informatikai Zrt. >>=20 >> On Sun, 15 Apr 2012, O. Hartmann wrote: >>=20 >>> Date: Sun, 15 Apr 2012 13:20:23 +0200 >>> From: O. Hartmann >>> To: Richard Kojedzinszky >>> Cc: freebsd-security@freebsd.org >>> Subject: Re: ufs multilabel performance (fwd) >>>=20 >>> Am 04/14/12 21:37, schrieb Richard Kojedzinszky: >>>> Dear list, >>>>=20 >>>> Although it is not only security-related question, I did not get = any >>>> answer from freebsd-performance. The original question is below. >>>>=20 >>>> Can someone give some advice? >>>>=20 >>>> Thanks in advance, >>>>=20 >>>>=20 >>>> Kojedzinszky Richard >>>> Euronet Magyarorszag Informatikai Zrt. >>>>=20 >>>> ---------- Forwarded message ---------- >>>> Date: Thu, 10 Nov 2011 06:16:57 +0100 (CET) >>>> From: Richard Kojedzinszky >>>> To: freebsd-performance@freebsd.org >>>> Subject: ufs multilabel performance >>>>=20 >>>> Dear List, >>>>=20 >>>> I've noticed that when I enable multilabel on an fs, a file = creation >>>> gets around 20-30 times slower than without multilabel set. >>>>=20 >>>> This one-liner can be used to test the differences: >>>> $ truss -D perl -e 'open(F, ">$_.file") for 1 .. 1000' >>>=20 >>> Same here, creating files seems to be 10 - 30 times slower with >>> multilabels as it is without. >>>=20 >>> But as several posts and discussions reflects, FreeBSD isn't = supposed to >>> be fast although it is claimed that writing is the major than = reading; >>> FBSD should serve functionality. >>>>=20 >>>> And one can see that the open call takes much more when multilabel = is >>>> set on an fs. It seems that only file creation needs that many = time, >>>> when a file exists it is opened much faster. >>>>=20 >>>> Could someone acknowledge this, and have some suggestions how to = make it >>>> faster? >>>>=20 >>>> Regards, >>>>=20 >>>>=20 >>>> Kojedzinszky Richard >>>> TvNetWork Nyrt. >>>> E-mail: krichy (at) tvnetwork [dot] hu >>>> PGP: 0x54B2BF0C8F59B1B7 >>>> Fingerprint =3D F6D4 3FFE AF03 CACF 0DCB 46A1 54B2 BF0C 8F59 B1B7 >=20 > At the moment, I'm troubled with a nasty kernel bug on all FreeBSD 10 > boxes I have spare to test. >=20 > I just tried to reproduce your observation and as far as I can go with > my experience, I can confirm that by using your perl script. >=20 > I'd like to test this again with a small C program. >=20 > I can only test the issue (test is too far optimistic, it's simply a > reproduction of your observation) on FreeBSD 10, the only remaining > FreeBSD server at our department is running FBSD 9-STABLE/amd64 and = "in > production", so changing multilabel support is a bit harsh at the = moment. >=20 >=20 > Sorry about crossposting, but I think this belongs more to CURRENT and > PERFORMANCE than SECURITY. My suggestion is completely take perl out of the equation because the = way you're invoking it above uses stdio and a few other things that add = unnecessary overhead. Try the attached C program/bourne shell snippet instead. Cheers, -Garrett #!/bin/sh set -e tmp=3D$(mktemp -d tmp.XXXXXX) trap "cd /; rm -Rf $tmp" EXIT cd $tmp cat > test_open.c < #include #include int main(void) { char buf[20]; int i; for (i =3D 0; i < 1000; i++) { sprintf(buf, "%d", i); close(open(buf, O_WRONLY|O_CREAT, 0600)); } return (0); } EOF gcc -o test_open test_open.c time ./test_open= From owner-freebsd-security@FreeBSD.ORG Sun Apr 15 20:39:10 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 956AA1065674; Sun, 15 Apr 2012 20:39:10 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 35E718FC16; Sun, 15 Apr 2012 20:39:10 +0000 (UTC) Received: by obqv19 with SMTP id v19so5422520obq.13 for ; Sun, 15 Apr 2012 13:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WzeAvt6pvhUgFhO0k93lFSOn8nLG3M1hx3eGZN/CotI=; b=gJ5P5kyAvobcQ2SVQdRTwHEe4wzblb8TuVzOuGZ8yRUsJkcaiuVcjyfFb9m78InZtK Skx3MPuJiJdAD3ePplOuGqdorZNGKyS1scN5pSDrl5W2WJk/X8aVImXbQLg7nqpGC4Gg G2zhFP5Wp3EFhy432ZchI1yYjdR9tBqfsT9JdBA6ej8h5ivj+R88UJUagU82auonyBKb qfPufbaL5kDl9TJQG8amwz+6Ja7pZymeB0aQ2KaVEwezQPk/CoCoVR2hTetJBZpnB5YI SGrRp0ARw/UvnGm21w8OMxkuSETjlZ3mDqybg59heW//xPjKLKi2x98EvkPzxFy7ETy8 i6dQ== Received: by 10.60.36.100 with SMTP id p4mr12717115oej.42.1334522349610; Sun, 15 Apr 2012 13:39:09 -0700 (PDT) Received: from [192.168.2.5] (dpc691939029.direcpc.com. [69.19.39.29]) by mx.google.com with ESMTPS id a8sm13819782oea.8.2012.04.15.13.38.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Apr 2012 13:39:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Garrett Cooper In-Reply-To: <4F8B2CC4.5030601@zedat.fu-berlin.de> Date: Sun, 15 Apr 2012 13:35:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <28768C15-C694-4C09-8CD1-3F5412554B55@gmail.com> References: <4F8AAEF7.3090800@zedat.fu-berlin.de> <4F8B21D2.4080008@zedat.fu-berlin.de> <951B1A8C-A216-420A-BA17-316B8D9C2B0E@gmail.com> <4F8B2CC4.5030601@zedat.fu-berlin.de> To: "O. Hartmann" X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Sun, 15 Apr 2012 21:25:51 +0000 Cc: freebsd-security@freebsd.org, Richard Kojedzinszky , Current FreeBSD , freebsd-performance@freebsd.org Subject: Re: ufs multilabel performance (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 20:39:10 -0000 On Apr 15, 2012, at 1:17 PM, O. Hartmann wrote: > Am 04/15/12 22:00, schrieb Garrett Cooper: >> On Apr 15, 2012, at 12:30 PM, O. Hartmann wrote: >>=20 >>> Am 04/15/12 15:59, schrieb Richard Kojedzinszky: >>>> Thank you for the reply. >>>>=20 >>>> Unfortunately, dont know why, but on my xen virtualised = environment, >>>> fbsd amd64 domU performs much slower, not only 30 times. Without >>>> multilabel, file creation speed is around 2500/s, but with = multilabels >>>> enabled, it is only 15/s (!). so it is more than 100 times slower. >>>>=20 >>>> And anyway freebsd is known to be fast as well, as functional. The = power >>>> to serve. :) >>>>=20 >>>> But in my environment, 15/s file creation is very-very slow. The >>>> hardware is a q6700 cpu with 4G ram, 2x1T sata disks in raid1, the = host >>>> runs linux. I think with this hw the mentioned speed is really = slow. >>>>=20 >>>> Regards, >>>>=20 >>>>=20 >>>> Kojedzinszky Richard >>>> Euronet Magyarorszag Informatikai Zrt. >>>>=20 >>>> On Sun, 15 Apr 2012, O. Hartmann wrote: >>>>=20 >>>>> Date: Sun, 15 Apr 2012 13:20:23 +0200 >>>>> From: O. Hartmann >>>>> To: Richard Kojedzinszky >>>>> Cc: freebsd-security@freebsd.org >>>>> Subject: Re: ufs multilabel performance (fwd) >>>>>=20 >>>>> Am 04/14/12 21:37, schrieb Richard Kojedzinszky: >>>>>> Dear list, >>>>>>=20 >>>>>> Although it is not only security-related question, I did not get = any >>>>>> answer from freebsd-performance. The original question is below. >>>>>>=20 >>>>>> Can someone give some advice? >>>>>>=20 >>>>>> Thanks in advance, >>>>>>=20 >>>>>>=20 >>>>>> Kojedzinszky Richard >>>>>> Euronet Magyarorszag Informatikai Zrt. >>>>>>=20 >>>>>> ---------- Forwarded message ---------- >>>>>> Date: Thu, 10 Nov 2011 06:16:57 +0100 (CET) >>>>>> From: Richard Kojedzinszky >>>>>> To: freebsd-performance@freebsd.org >>>>>> Subject: ufs multilabel performance >>>>>>=20 >>>>>> Dear List, >>>>>>=20 >>>>>> I've noticed that when I enable multilabel on an fs, a file = creation >>>>>> gets around 20-30 times slower than without multilabel set. >>>>>>=20 >>>>>> This one-liner can be used to test the differences: >>>>>> $ truss -D perl -e 'open(F, ">$_.file") for 1 .. 1000' >>>>>=20 >>>>> Same here, creating files seems to be 10 - 30 times slower with >>>>> multilabels as it is without. >>>>>=20 >>>>> But as several posts and discussions reflects, FreeBSD isn't = supposed to >>>>> be fast although it is claimed that writing is the major than = reading; >>>>> FBSD should serve functionality. >>>>>>=20 >>>>>> And one can see that the open call takes much more when = multilabel is >>>>>> set on an fs. It seems that only file creation needs that many = time, >>>>>> when a file exists it is opened much faster. >>>>>>=20 >>>>>> Could someone acknowledge this, and have some suggestions how to = make it >>>>>> faster? >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>>=20 >>>>>> Kojedzinszky Richard >>>>>> TvNetWork Nyrt. >>>>>> E-mail: krichy (at) tvnetwork [dot] hu >>>>>> PGP: 0x54B2BF0C8F59B1B7 >>>>>> Fingerprint =3D F6D4 3FFE AF03 CACF 0DCB 46A1 54B2 BF0C 8F59 = B1B7 >>>=20 >>> At the moment, I'm troubled with a nasty kernel bug on all FreeBSD = 10 >>> boxes I have spare to test. >>>=20 >>> I just tried to reproduce your observation and as far as I can go = with >>> my experience, I can confirm that by using your perl script. >>>=20 >>> I'd like to test this again with a small C program. >>>=20 >>> I can only test the issue (test is too far optimistic, it's simply a >>> reproduction of your observation) on FreeBSD 10, the only remaining >>> FreeBSD server at our department is running FBSD 9-STABLE/amd64 and = "in >>> production", so changing multilabel support is a bit harsh at the = moment. >>>=20 >>>=20 >>> Sorry about crossposting, but I think this belongs more to CURRENT = and >>> PERFORMANCE than SECURITY. >>=20 >> My suggestion is completely take perl out of the equation because the = way you're invoking it above uses stdio and a few other things that add = unnecessary overhead. >>=20 >> Try the attached C program/bourne shell snippet instead. >>=20 >> Cheers, >> -Garrett >>=20 >> #!/bin/sh >>=20 >> set -e >>=20 >> tmp=3D$(mktemp -d tmp.XXXXXX) >> trap "cd /; rm -Rf $tmp" EXIT >> cd $tmp >>=20 >> cat > test_open.c <>=20 >> #include >> #include >> #include >>=20 >> int >> main(void) >> { >> char buf[20]; >> int i; >>=20 >> for (i =3D 0; i < 1000; i++) { >> sprintf(buf, "%d", i); >> close(open(buf, O_WRONLY|O_CREAT, 0600)); >> } >> return (0); >> } >> EOF >>=20 >> gcc -o test_open test_open.c >> time ./test_open_______________________________________________ >=20 > This was pretty fast ;-) If it turns out that it wasn't that particular item that's = causing a slowdown, I can easily modify my above snippet to use stdio, = etc. But unless the version of perl and a few other items are the same, = I wouldn't necessarily blame the guest OS. Please also make sure that = Xen, etc is completely up-to-date because there were some performance = degradation issues that were fixed post-6.0. -Garrett= From owner-freebsd-security@FreeBSD.ORG Tue Apr 17 06:31:35 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EABD1106566B; Tue, 17 Apr 2012 06:31:35 +0000 (UTC) (envelope-from krichy@tvnetwork.hu) Received: from krichy.tvnetwork.hu (krichy.tvnetwork.hu [109.61.101.194]) by mx1.freebsd.org (Postfix) with ESMTP id 876588FC0A; Tue, 17 Apr 2012 06:31:35 +0000 (UTC) Received: by krichy.tvnetwork.hu (Postfix, from userid 1000) id F3BC020402; Tue, 17 Apr 2012 08:31:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by krichy.tvnetwork.hu (Postfix) with ESMTP id E949D20096; Tue, 17 Apr 2012 08:31:27 +0200 (CEST) Date: Tue, 17 Apr 2012 08:31:27 +0200 (CEST) From: Richard Kojedzinszky To: Garrett Cooper In-Reply-To: <28768C15-C694-4C09-8CD1-3F5412554B55@gmail.com> Message-ID: References: <4F8AAEF7.3090800@zedat.fu-berlin.de> <4F8B21D2.4080008@zedat.fu-berlin.de> <951B1A8C-A216-420A-BA17-316B8D9C2B0E@gmail.com> <4F8B2CC4.5030601@zedat.fu-berlin.de> <28768C15-C694-4C09-8CD1-3F5412554B55@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-security@freebsd.org, freebsd-performance@freebsd.org, Current FreeBSD , "O. Hartmann" Subject: Re: ufs multilabel performance (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 06:31:36 -0000 So now reactions here, creating files with multilabel is still slow. I would like to use multilabel access control on my /tmp, for example, my web server places it's session files there in a subdirectory. Of course, I would like to assign a label for that subdir, but with this slow file creation, that is not the way to go. I may then use a different filesystem for that. In this case, can I assign a root mac label for a mount point? Thanks in advance, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. On Sun, 15 Apr 2012, Garrett Cooper wrote: > Date: Sun, 15 Apr 2012 13:35:59 -0700 > From: Garrett Cooper > To: O. Hartmann > Cc: freebsd-security@freebsd.org, Richard Kojedzinszky , > Current FreeBSD , > freebsd-performance@freebsd.org > Subject: Re: ufs multilabel performance (fwd) > > On Apr 15, 2012, at 1:17 PM, O. Hartmann wrote: > >> Am 04/15/12 22:00, schrieb Garrett Cooper: >>> On Apr 15, 2012, at 12:30 PM, O. Hartmann wrote: >>> >>>> Am 04/15/12 15:59, schrieb Richard Kojedzinszky: >>>>> Thank you for the reply. >>>>> >>>>> Unfortunately, dont know why, but on my xen virtualised environment, >>>>> fbsd amd64 domU performs much slower, not only 30 times. Without >>>>> multilabel, file creation speed is around 2500/s, but with multilabels >>>>> enabled, it is only 15/s (!). so it is more than 100 times slower. >>>>> >>>>> And anyway freebsd is known to be fast as well, as functional. The power >>>>> to serve. :) >>>>> >>>>> But in my environment, 15/s file creation is very-very slow. The >>>>> hardware is a q6700 cpu with 4G ram, 2x1T sata disks in raid1, the host >>>>> runs linux. I think with this hw the mentioned speed is really slow. >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Kojedzinszky Richard >>>>> Euronet Magyarorszag Informatikai Zrt. >>>>> >>>>> On Sun, 15 Apr 2012, O. Hartmann wrote: >>>>> >>>>>> Date: Sun, 15 Apr 2012 13:20:23 +0200 >>>>>> From: O. Hartmann >>>>>> To: Richard Kojedzinszky >>>>>> Cc: freebsd-security@freebsd.org >>>>>> Subject: Re: ufs multilabel performance (fwd) >>>>>> >>>>>> Am 04/14/12 21:37, schrieb Richard Kojedzinszky: >>>>>>> Dear list, >>>>>>> >>>>>>> Although it is not only security-related question, I did not get any >>>>>>> answer from freebsd-performance. The original question is below. >>>>>>> >>>>>>> Can someone give some advice? >>>>>>> >>>>>>> Thanks in advance, >>>>>>> >>>>>>> >>>>>>> Kojedzinszky Richard >>>>>>> Euronet Magyarorszag Informatikai Zrt. >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> Date: Thu, 10 Nov 2011 06:16:57 +0100 (CET) >>>>>>> From: Richard Kojedzinszky >>>>>>> To: freebsd-performance@freebsd.org >>>>>>> Subject: ufs multilabel performance >>>>>>> >>>>>>> Dear List, >>>>>>> >>>>>>> I've noticed that when I enable multilabel on an fs, a file creation >>>>>>> gets around 20-30 times slower than without multilabel set. >>>>>>> >>>>>>> This one-liner can be used to test the differences: >>>>>>> $ truss -D perl -e 'open(F, ">$_.file") for 1 .. 1000' >>>>>> >>>>>> Same here, creating files seems to be 10 - 30 times slower with >>>>>> multilabels as it is without. >>>>>> >>>>>> But as several posts and discussions reflects, FreeBSD isn't supposed to >>>>>> be fast although it is claimed that writing is the major than reading; >>>>>> FBSD should serve functionality. >>>>>>> >>>>>>> And one can see that the open call takes much more when multilabel is >>>>>>> set on an fs. It seems that only file creation needs that many time, >>>>>>> when a file exists it is opened much faster. >>>>>>> >>>>>>> Could someone acknowledge this, and have some suggestions how to make it >>>>>>> faster? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> Kojedzinszky Richard >>>>>>> TvNetWork Nyrt. >>>>>>> E-mail: krichy (at) tvnetwork [dot] hu >>>>>>> PGP: 0x54B2BF0C8F59B1B7 >>>>>>> Fingerprint = F6D4 3FFE AF03 CACF 0DCB 46A1 54B2 BF0C 8F59 B1B7 >>>> >>>> At the moment, I'm troubled with a nasty kernel bug on all FreeBSD 10 >>>> boxes I have spare to test. >>>> >>>> I just tried to reproduce your observation and as far as I can go with >>>> my experience, I can confirm that by using your perl script. >>>> >>>> I'd like to test this again with a small C program. >>>> >>>> I can only test the issue (test is too far optimistic, it's simply a >>>> reproduction of your observation) on FreeBSD 10, the only remaining >>>> FreeBSD server at our department is running FBSD 9-STABLE/amd64 and "in >>>> production", so changing multilabel support is a bit harsh at the moment. >>>> >>>> >>>> Sorry about crossposting, but I think this belongs more to CURRENT and >>>> PERFORMANCE than SECURITY. >>> >>> My suggestion is completely take perl out of the equation because the way you're invoking it above uses stdio and a few other things that add unnecessary overhead. >>> >>> Try the attached C program/bourne shell snippet instead. >>> >>> Cheers, >>> -Garrett >>> >>> #!/bin/sh >>> >>> set -e >>> >>> tmp=$(mktemp -d tmp.XXXXXX) >>> trap "cd /; rm -Rf $tmp" EXIT >>> cd $tmp >>> >>> cat > test_open.c <>> >>> #include >>> #include >>> #include >>> >>> int >>> main(void) >>> { >>> char buf[20]; >>> int i; >>> >>> for (i = 0; i < 1000; i++) { >>> sprintf(buf, "%d", i); >>> close(open(buf, O_WRONLY|O_CREAT, 0600)); >>> } >>> return (0); >>> } >>> EOF >>> >>> gcc -o test_open test_open.c >>> time ./test_open_______________________________________________ >> >> This was pretty fast ;-) > > If it turns out that it wasn't that particular item that's causing a slowdown, I can easily modify my above snippet to use stdio, etc. But unless the version of perl and a few other items are the same, I wouldn't necessarily blame the guest OS. Please also make sure that Xen, etc is completely up-to-date because there were some performance degradation issues that were fixed post-6.0. > -Garrett_______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > From owner-freebsd-security@FreeBSD.ORG Tue Apr 17 19:17:05 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76AC01065678; Tue, 17 Apr 2012 19:17:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 360058FC0C; Tue, 17 Apr 2012 19:17:05 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so8482382pbc.13 for ; Tue, 17 Apr 2012 12:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pynJz+Qr6tcT3ZvpH9LJ0+d0XCbJM1eVlERdMpKYp6Q=; b=hFr1N9uljiuovh9cevX/lJ/nbsdxjKeSAbRNECsTyQlfN2FfTAdkbO+bz1vyZpi7j/ QJi+h/WfFs3643AdXUIiJFUV5V/OvpCAStRSd3tbfeoQCMYmwDi4LRAtE+ro/acBmybU 986ylTq9bZ9L7c9TMTfWmeEUpuRTugVW1t7CKvHOgAQKOSm6ZWnyCypV3sHiHzuHOhfL MbPnM76P0mtAc4iAf9BesY0Y+A1djC8fnYRoBrLsI1UnypN2Ah5+NqqkPzKb3FXlG0WD 6RudJVHy3OTzV7kxzIcgDAkGBa7QTPKUS7qzyMC2eurL4oOHLRFDwahVCj6SiMyj0PVP 39aw== MIME-Version: 1.0 Received: by 10.68.225.132 with SMTP id rk4mr37338630pbc.157.1334690224737; Tue, 17 Apr 2012 12:17:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.101.9 with HTTP; Tue, 17 Apr 2012 12:17:04 -0700 (PDT) In-Reply-To: References: <4F8AAEF7.3090800@zedat.fu-berlin.de> <4F8B21D2.4080008@zedat.fu-berlin.de> <951B1A8C-A216-420A-BA17-316B8D9C2B0E@gmail.com> <4F8B2CC4.5030601@zedat.fu-berlin.de> <28768C15-C694-4C09-8CD1-3F5412554B55@gmail.com> Date: Tue, 17 Apr 2012 12:17:04 -0700 X-Google-Sender-Auth: ZJ_qKDqXcYG5xfBHBN6XQcijTy4 Message-ID: From: Adrian Chadd To: Richard Kojedzinszky Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 17 Apr 2012 19:58:40 +0000 Cc: Garrett Cooper , freebsd-security@freebsd.org, freebsd-performance@freebsd.org, Current FreeBSD , "O. Hartmann" Subject: Re: ufs multilabel performance (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:17:05 -0000 On 16 April 2012 23:31, Richard Kojedzinszky wrote: > > So now reactions here, creating files with multilabel is still slow. > > I would like to use multilabel access control on my /tmp, for example, my > web server places it's session files there in a subdirectory. Of course, I > would like to assign a label for that subdir, but with this slow file > creation, that is not the way to go. I may then use a different filesystem > for that. In this case, can I assign a root mac label for a mount point? Hi, This is a perfect job for hwpmc / dtrace. Would you be able to load up either of those and get some CPU usage statistics whilst you're running your benchmark? It's either that, or it's (massive) locking contention. Adrian From owner-freebsd-security@FreeBSD.ORG Tue Apr 17 20:57:15 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D431A106566C; Tue, 17 Apr 2012 20:57:15 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D6C358FC16; Tue, 17 Apr 2012 20:57:14 +0000 (UTC) Received: by wern13 with SMTP id n13so5663620wer.13 for ; Tue, 17 Apr 2012 13:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5mLT1o19oerLhARGTh7NKQhb318V3zZLwSJZRoasJdg=; b=n57rJzReCJO9r+HBkFJyH70/fZI9AzuPaxoczmTfc2C3Neqz82AgWQ8NZwc8Xs72f7 LAOWJZ1oC0zUfTihZXx9JjWiZ9ShSAPBnumvaLSb3T60dCRg4tk36VSZdpVMQdfudYYZ gev+XPQanfb9+gHlBcOTyaiPAdw8oCCxW6Z3H138FX2qcxoFX42aODK5vHphVU9wLwJr H9Vu4rlpTYbZXeo6Jc3gZXCB8P6SyIiycvMMuTaeXFt6+m36InXYh7X97tu+1Loem91e C9cZdYBv8CfeEgrVMBabCSx+EVV/huOkN4/ZIWgGHO07R07D9ZCFXlEn4//SMNAlEWF9 24VQ== Received: by 10.180.101.8 with SMTP id fc8mr18144077wib.12.1334696234070; Tue, 17 Apr 2012 13:57:14 -0700 (PDT) Received: from [192.168.1.105] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPS id 17sm30028896wis.0.2012.04.17.13.57.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 13:57:12 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: Date: Tue, 17 Apr 2012 22:57:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BFCE7F6-8C67-4BEA-AF13-712A83430002@FreeBSD.org> References: <4F8AAEF7.3090800@zedat.fu-berlin.de> <4F8B21D2.4080008@zedat.fu-berlin.de> <951B1A8C-A216-420A-BA17-316B8D9C2B0E@gmail.com> <4F8B2CC4.5030601@zedat.fu-berlin.de> <28768C15-C694-4C09-8CD1-3F5412554B55@gmail.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Tue, 17 Apr 2012 21:10:13 +0000 Cc: Garrett Cooper , Richard Kojedzinszky , freebsd-security@freebsd.org, Current FreeBSD , freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: ufs multilabel performance (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:57:15 -0000 Wiadomo=B6=E6 napisana przez Adrian Chadd w dniu 17 kwi 2012, o godz. = 21:17: > On 16 April 2012 23:31, Richard Kojedzinszky = wrote: >>=20 >> So now reactions here, creating files with multilabel is still slow. >>=20 >> I would like to use multilabel access control on my /tmp, for = example, my >> web server places it's session files there in a subdirectory. Of = course, I >> would like to assign a label for that subdir, but with this slow file >> creation, that is not the way to go. I may then use a different = filesystem >> for that. In this case, can I assign a root mac label for a mount = point? >=20 > Hi, >=20 > This is a perfect job for hwpmc / dtrace. >=20 > Would you be able to load up either of those and get some CPU usage > statistics whilst you're running your benchmark? >=20 > It's either that, or it's (massive) locking contention. Or disk I/O. MAC labels, just like ACLs, are stored in extended = attributes, and I remember something about writing those being synchronous. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-security@FreeBSD.ORG Tue Apr 17 21:24:31 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 516561065677; Tue, 17 Apr 2012 21:24:31 +0000 (UTC) (envelope-from krichy@tvnetwork.hu) Received: from krichy.tvnetwork.hu (unknown [IPv6:2a01:be00:0:2::10]) by mx1.freebsd.org (Postfix) with ESMTP id C81C88FC16; Tue, 17 Apr 2012 21:24:30 +0000 (UTC) Received: by krichy.tvnetwork.hu (Postfix, from userid 1000) id 5FF2720402; Tue, 17 Apr 2012 23:24:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by krichy.tvnetwork.hu (Postfix) with ESMTP id 4F4B4203CC; Tue, 17 Apr 2012 23:24:29 +0200 (CEST) Date: Tue, 17 Apr 2012 23:24:29 +0200 (CEST) From: Richard Kojedzinszky To: =?ISO-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <3BFCE7F6-8C67-4BEA-AF13-712A83430002@FreeBSD.org> Message-ID: References: <4F8AAEF7.3090800@zedat.fu-berlin.de> <4F8B21D2.4080008@zedat.fu-berlin.de> <951B1A8C-A216-420A-BA17-316B8D9C2B0E@gmail.com> <4F8B2CC4.5030601@zedat.fu-berlin.de> <28768C15-C694-4C09-8CD1-3F5412554B55@gmail.com> <3BFCE7F6-8C67-4BEA-AF13-712A83430002@FreeBSD.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1030603365-960894060-1334697869=:5815" Cc: Adrian Chadd , Garrett Cooper , freebsd-security@freebsd.org, Current FreeBSD , freebsd-performance@freebsd.org, "O. Hartmann" Subject: Re: ufs multilabel performance (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 21:24:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1030603365-960894060-1334697869=:5815 Content-Type: TEXT/PLAIN; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8BIT Without any benchmarks I would also think for the high io, in the xen dom0 I see high disk activity (eg 99% writes) when using mac labels. But of course I will do the tests, please give some instructions, how to compile the kernel, how the implement the benchmark. Thanks in advance, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. On Tue, 17 Apr 2012, Edward Tomasz Napierała wrote: > Date: Tue, 17 Apr 2012 22:57:09 +0200 > From: Edward Tomasz Napierała > To: Adrian Chadd > Cc: Richard Kojedzinszky , > Garrett Cooper , freebsd-security@freebsd.org, > freebsd-performance@freebsd.org, > Current FreeBSD , > O. Hartmann > Subject: Re: ufs multilabel performance (fwd) > > Wiadomość napisana przez Adrian Chadd w dniu 17 kwi 2012, o godz. 21:17: >> On 16 April 2012 23:31, Richard Kojedzinszky wrote: >>> >>> So now reactions here, creating files with multilabel is still slow. >>> >>> I would like to use multilabel access control on my /tmp, for example, my >>> web server places it's session files there in a subdirectory. Of course, I >>> would like to assign a label for that subdir, but with this slow file >>> creation, that is not the way to go. I may then use a different filesystem >>> for that. In this case, can I assign a root mac label for a mount point? >> >> Hi, >> >> This is a perfect job for hwpmc / dtrace. >> >> Would you be able to load up either of those and get some CPU usage >> statistics whilst you're running your benchmark? >> >> It's either that, or it's (massive) locking contention. > > Or disk I/O. MAC labels, just like ACLs, are stored in extended attributes, > and I remember something about writing those being synchronous. > > -- > If you cut off my head, what would I say? Me and my head, or me and my body? > --1030603365-960894060-1334697869=:5815-- From owner-freebsd-security@FreeBSD.ORG Thu Apr 19 05:11:57 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51065106566C for ; Thu, 19 Apr 2012 05:11:57 +0000 (UTC) (envelope-from cfp@ruxcon.org.au) Received: from ruxcon.org.au (li382-175.members.linode.com [106.187.39.175]) by mx1.freebsd.org (Postfix) with ESMTP id 280688FC12 for ; Thu, 19 Apr 2012 05:11:56 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by ruxcon.org.au (Postfix) with ESMTP id DD943CD41 for ; Thu, 19 Apr 2012 15:04:06 +1000 (EST) From: cfp@ruxcon.org.au To: freebsd-security@freebsd.org Message-Id: <20120419050406.DD943CD41@ruxcon.org.au> Date: Thu, 19 Apr 2012 15:04:06 +1000 (EST) Subject: Ruxcon 2012 Call For Papers X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 05:11:57 -0000 Ruxcon 2012 Call For Papers The Ruxcon team is pleased to announce the call for papers for the 2012 annual Ruxcon conference. This year the conference will take place over the weekend of 20th and 21st of October at the CQ Function Centre, Melbourne, Australia. The deadline for submissions is the 15th of July. * What is Ruxcon? Ruxcon is the premier technical computer security conference in the Australia. The conference aims to bring together the individual talents of the best and brightest security folk in the region, through live presentations, activities and demonstrations. The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security. Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community. For more information, please visit http://www.ruxcon.org.au * Presentation Information Presentations are set to run for 40 to 50 minutes, and will be of a formal nature, with slides and a speech. * Topics Topics of interest include, but are not limited to: o Mobile Device Security o Virtualization, Hypervisor, and Cloud Security o Malware Analysis o Reverse Engineering o Exploitation Techniques o Rootkit Development o Code Analysis o Forensics and Anti-Forensics o Embedded Device Security o Web Application Security o Network Traffic Analysis o Wireless Network Security o Cryptography and Cryptanalysis o Social Engineering o Law Enforcement Activities o Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc) * Submissions Submissions should thoroughly outline your desired presentation subject. If you have any enquiries about submissions, or would like to make a submission, please send an e-mail to presentations@ruxcon.org.au The deadline for submissions is the 15th of July. If approved we will additionally require: i. A brief personal biography (between 2-5 paragraphs in length). ii. A description on your presentation (between 2-5 paragraphs in length). * Contacts Email: presentations@ruxcon.org.au Twitter: ruxcon From owner-freebsd-security@FreeBSD.ORG Thu Apr 19 12:59:20 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13CF2106566B for ; Thu, 19 Apr 2012 12:59:20 +0000 (UTC) (envelope-from marco@tolstoy.tols.org) Received: from tolstoy.tols.org (tolstoy.tols.org [IPv6:2a02:898:0:20::57:1]) by mx1.freebsd.org (Postfix) with ESMTP id A0ADB8FC12 for ; Thu, 19 Apr 2012 12:59:19 +0000 (UTC) Received: from tolstoy.tols.org (localhost [127.0.0.1]) by tolstoy.tols.org (8.14.5/8.14.5) with ESMTP id q3JCxCeG036139 for ; Thu, 19 Apr 2012 12:59:12 GMT (envelope-from marco@tolstoy.tols.org) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at tolstoy.tols.org Received: (from marco@localhost) by tolstoy.tols.org (8.14.5/8.14.5/Submit) id q3JCxCM3036138 for freebsd-security@freebsd.org; Thu, 19 Apr 2012 14:59:12 +0200 (CEST) (envelope-from marco) Date: Thu, 19 Apr 2012 14:59:12 +0200 From: Marco van Tol To: FreeBSD Security Message-ID: <20120419125912.GC30970@tolstoy.tols.org> Mail-Followup-To: FreeBSD Security Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tolstoy.tols.org Subject: openssl bug X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 12:59:20 -0000 Hi there, The following URL was brought to my attention. Figured I should forward it to here in case it hasn't been cought yet: http://lists.grok.org.uk/pipermail/full-disclosure/2012-April/086585.html Kind regards, Marco van Tol -- Success is having to worry about every damn thing in the world, except money. - Johnny Cash From owner-freebsd-security@FreeBSD.ORG Thu Apr 19 18:03:01 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id BC8FD1065678; Thu, 19 Apr 2012 18:03:00 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Marco van Tol Date: Thu, 19 Apr 2012 14:02:50 -0400 User-Agent: KMail/1.6.2 References: <20120419125912.GC30970@tolstoy.tols.org> In-Reply-To: <20120419125912.GC30970@tolstoy.tols.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204191402.52216.jkim@FreeBSD.org> Cc: benl@FreeBSD.org, FreeBSD Security Subject: Re: openssl bug X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 18:03:01 -0000 On Thursday 19 April 2012 08:59 am, Marco van Tol wrote: > Hi there, > > The following URL was brought to my attention. Figured I should > forward it to here in case it hasn't been cought yet: > > http://lists.grok.org.uk/pipermail/full-disclosure/2012-April/08658 >5.html FYI, I've been maintaining unofficial patchsets for OpenSSL in the base. My patch is updated to 0.9.8v now, available from here: http://people.freebsd.org/~jkim/openssl-0.9.8v.diff Thanks, Jung-uk Kim From owner-freebsd-security@FreeBSD.ORG Thu Apr 19 18:53:49 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E71B210657D7; Thu, 19 Apr 2012 18:53:49 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 793908FC15; Thu, 19 Apr 2012 18:53:49 +0000 (UTC) Received: by ghrr20 with SMTP id r20so5687939ghr.13 for ; Thu, 19 Apr 2012 11:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h0P2Uosd/nVTsmIPJyzMoHIWCHrU0P9VnR0vJyFEc6k=; b=iI/pWlmHPspXfAPWZiefLrNfTi1JISDOnuKvGvNGhPq4eE3oEQnGeow4tCTEBEoaI2 9sM/nf6/pAMteWzGR2/QPOWQCofNiT1UabFH/LXTWSoTnqMmSoPcy6XSZf0LFk1WfCdh Zz24yQpTtlHRgeiQciSjH1SvXZ1v1YrO36imZe/GwM7IQTOfJ9705QEaKs2YUbpdUJxy Gp5wRnigvUI2+yRIRDZvE7amdrFWnscEnMvvCf6n7sERTOvYvmBxL/LdrJweTjsx+pCW K6spOqNRjizlQsl9fcA+owtsv+fG2yvkVyGgB7DuDMY/iH6piKHTkKHVJxUF3d06fnp+ /JMQ== MIME-Version: 1.0 Received: by 10.100.245.10 with SMTP id s10mr998763anh.65.1334861623252; Thu, 19 Apr 2012 11:53:43 -0700 (PDT) Received: by 10.236.161.97 with HTTP; Thu, 19 Apr 2012 11:53:43 -0700 (PDT) In-Reply-To: <201204191402.52216.jkim@FreeBSD.org> References: <20120419125912.GC30970@tolstoy.tols.org> <201204191402.52216.jkim@FreeBSD.org> Date: Thu, 19 Apr 2012 20:53:43 +0200 Message-ID: From: Oliver Pinter To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Cc: Marco van Tol , benl@freebsd.org, FreeBSD Security Subject: Re: openssl bug X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 18:53:50 -0000 And another one, as you can see FreeBSD Security Team , reported at Wed, Apr 4, 2012 at 5:41 PM. On 4/19/12, Jung-uk Kim wrote: > On Thursday 19 April 2012 08:59 am, Marco van Tol wrote: >> Hi there, >> >> The following URL was brought to my attention. Figured I should >> forward it to here in case it hasn't been cought yet: >> >> http://lists.grok.org.uk/pipermail/full-disclosure/2012-April/08658 >>5.html > > FYI, I've been maintaining unofficial patchsets for OpenSSL in the > base. My patch is updated to 0.9.8v now, available from here: > > http://people.freebsd.org/~jkim/openssl-0.9.8v.diff > > Thanks, > > Jung-uk Kim > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" >