From aw-confirm at ebay.com Mon Apr 4 13:03:32 2005 From: aw-confirm at ebay.com (aw-confirm@ebay.com) Date: Mon Apr 4 13:03:39 2005 Subject: Your Final Warning From eBay Message-ID: CORRUPTED MESSAGE This is the Courier Mail Server 0.48 on fosho.putnamville.com. I received the following message for delivery to your address. This message contains several internal formatting errors. This is often caused by viruses that attempt to infect remote systems. Instead of blocking this message, it has been converted as a safe, text-only attachment that can be safely read with a text editor. This sometimes also happens when the sender's mail software has a bug that creates improperly-formatted messages. Although these kinds of formatting errors may often be ignored by other mail servers, this server detects and intercepts improperly-coded messages in order to prevent viruses from taking advantage of bugs in E-mail programs: ----------------------------------------------------------------------------- This message contains improperly-formatted binary content, or attachment. See for more information. ----------------------------------------------------------------------------- -------------- next part -------------- Received: from localhost (localhost [127.0.0.1]) (uid 503) by fosho.putnamville.com with local; Mon, 04 Apr 2005 13:03:53 -0700 id 000F0541.42519DA9.0000179C To: freebsd-fs@freebsd.org Subject: Your Final Warning From eBay From: "aw-confirm@ebay.com" Content-Type: text/html Message-ID: Date: Mon, 04 Apr 2005 13:03:53 -0700
Place or Update Credit Card on File 

Dear eBay,

During our regulary schedule account maintenance and verification we have detected a slight error in your billing information on file with eBay. This might be due to either following reasons:

             - A recent change in your personal information (i.e. change of address)
             - Submiting invalid information during the initial sign up process.
             - An inability to accurately verify your selected option of payment due an internal error within
               our processors.

Your credit card on file with eBay    
Card number: XXXX-XXXX-XXXX-4322 (Not shown for security purposes)  Expiration date: 11/05

Please sign in to your eBay account and update your billing information:

http://signin.ebay.com/eBayISAPI.dll?SignIn&ssPageName=h:h:sin:US" >

If your account information is not update, your ability to sell or bid on eBay will become restricted.

Thank you,
eBay Billing Department

eBay treats your personal information with the utmost care, and our Privacy Policy is designed to protect you and your information. eBay will never ask their users for personal information, such as bank account numbers, credit card numbers, pin numbers, passwords, or Social Security numbers in an email. For more information on how to protect your eBay password and your account, please visit User Account Protection.
This eBay notice was sent to you based on your eBay account preferences and in accordance with our Privacy Policy. To change your notification preferences, click here. If you would like to receive this email in text format, click here.

Copyright ? 2004 eBay Inc. All Rights Reserved.
Designated trademarks and brands are the property of their respective owners.
eBay and the eBay logo are trademarks of eBay Inc.

From ezk at cs.sunysb.edu Wed Apr 6 13:19:49 2005 From: ezk at cs.sunysb.edu (Erez Zadok) Date: Wed Apr 6 13:19:50 2005 Subject: Reproducable FreeBSD/AMD Crash In-Reply-To: Your message of "Wed, 06 Apr 2005 12:57:25 PDT." <637A278D8D0DBC438EA5E75C6E1818B9028C4810@magenta.hq.netapp.com> Message-ID: <200504062019.j36KJdgh024816@agora.fsl.cs.sunysb.edu> I'm CCing freebsd-fs here. To the freebsd-fs people: Tom reported a freebsd kernel panic that's triggered by an intense activity via amd (using amq -u to unmount an entry, and then "touching" it again to re-mount it, then repeating this process). In message <637A278D8D0DBC438EA5E75C6E1818B9028C4810@magenta.hq.netapp.com>, "Vincent, Thomas" writes: > -----Original Message----- > From: Nomura, Kevin > Sent: Wednesday, April 06, 2005 12:54 PM > To: Vincent, Thomas > Subject: Re: FW: Reproducable FreeBSD/AMD Crash > > Thomas, > > The amd version we saw this with: both the stock version that comes with > freebsd 5.3, and also 6.1rc1 which I built and invoked by hand. It does > seem that a user space program (like am-utils) should be be the root cause > of a kernel panic. > There was the chance that some algorithmic change in the very latest amd > would avoid the problem, or more precisely mask it, but that did not happen > either. > > The kernel panicked. The console did not give much info: > > gimcrack# panic: unmount: dangling vnode cpuid = 0 > boot() called on cpu#0 > Uptime: 21h58m34s > Cannot dump. No dump device defined. > Automatic reboot in 15 seconds - press a key on the console to abort > > If a core will be useful then I can presumably set the system up to capture > one. > > Thanks, > Kevin I think you need to report it to the freebsd people: for now, I can put a report in the BUGS file of am-utils that certain intense activity via amd could trigger a panic. I suggest you get a core dump, stack trace, whatever you can, and report it on freebsd-hackers and/or freebsd-fs. Clearly this is a serious bug that they need to fix. Of course, we'll be happy to help you and the freebsd folks to fix it. If it turns out that Amd is doing something wrong, then we'll fix it. But as I said in my earlier email to you: no kernel should ever panic b/c of what a userland process does via syscalls (with the exception of scribbling over random kernel memory via /dev/kmem :-) Thanks, Erez. From mb at imp.ch Wed Apr 6 14:05:42 2005 From: mb at imp.ch (Martin Blapp) Date: Wed Apr 6 14:05:46 2005 Subject: Reproducable FreeBSD/AMD Crash In-Reply-To: <200504062019.j36KJdgh024816@agora.fsl.cs.sunysb.edu> References: <200504062019.j36KJdgh024816@agora.fsl.cs.sunysb.edu> Message-ID: <20050406230346.S73884@cvs.imp.ch> Hi, > > The amd version we saw this with: both the stock version that comes with > > freebsd 5.3, and also 6.1rc1 which I built and invoked by hand. It does > > seem that a user space program (like am-utils) should be be the root cause > > of a kernel panic. > > There was the chance that some algorithmic change in the very latest amd > > would avoid the problem, or more precisely mask it, but that did not happen > > either. Can you please upgrade to FreeBSD 5.4RC1 and see if it happens there too ? We need also a kernel trace, I can help with that you if you don't know how to do it. If so, contact me off-list. Martin (FreeBSD AMD maintainer) From Thomas.Vincent at netapp.com Fri Apr 8 14:56:48 2005 From: Thomas.Vincent at netapp.com (Vincent, Thomas) Date: Fri Apr 8 14:56:50 2005 Subject: Reproducable FreeBSD/AMD Crash Message-ID: <637A278D8D0DBC438EA5E75C6E1818B9028C482F@magenta.hq.netapp.com> http://www.freebsd.org/cgi/query-pr.cgi?pr=79665 ---snip--- Hi, > > The amd version we saw this with: both the stock version that comes with > > freebsd 5.3, and also 6.1rc1 which I built and invoked by hand. It does > > seem that a user space program (like am-utils) should be be the root cause > > of a kernel panic. > > There was the chance that some algorithmic change in the very latest amd > > would avoid the problem, or more precisely mask it, but that did not happen > > either. Can you please upgrade to FreeBSD 5.4RC1 and see if it happens there too ? We need also a kernel trace, I can help with that you if you don't know how to do it. If so, contact me off-list. Martin (FreeBSD AMD maintainer) Cheers, Tom ---- Thomas Vincent Network Services Architect | Engineering Support Network Appliance | Email: thomasv@netapp.com | Phone: 408.822.7157 AIM: thomasv@mac.com | Yahoo: thomasvncnt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3653 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20050408/cb5ed41f/smime.bin From takawata at jp.freebsd.org Sat Apr 9 19:53:09 2005 From: takawata at jp.freebsd.org (takawata@jp.freebsd.org) Date: Sat Apr 9 19:53:12 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 Message-ID: <200504100251.j3A2pLEH055107@sana.init-main.com> Hi I found the bug which is introduced at smbfs_vnops.c rev 1.58 This will make instant panic when you try to access file on mounted smbfs. This is caused by uninitialized vp. Index: smbfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/smbfs/smbfs_vnops.c,v retrieving revision 1.59 diff -u -r1.59 smbfs_vnops.c --- smbfs_vnops.c 29 Mar 2005 13:06:58 -0000 1.59 +++ smbfs_vnops.c 10 Apr 2005 02:44:04 -0000 @@ -1118,7 +1118,8 @@ return error; if (error) { /* name was found */ struct vattr vattr; - + + vp = *vpp; killit = 0; error = VOP_GETATTR(vp, &vattr, cnp->cn_cred, td); /* From delphij at frontfree.net Sat Apr 9 20:20:26 2005 From: delphij at frontfree.net (Xin LI) Date: Sat Apr 9 20:20:35 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 In-Reply-To: <200504100251.j3A2pLEH055107@sana.init-main.com> References: <200504100251.j3A2pLEH055107@sana.init-main.com> Message-ID: <20050410032009.GA37675@frontfree.net> Hi, On Sun, Apr 10, 2005 at 11:51:21AM +0900, takawata@jp.freebsd.org wrote: > Hi I found the bug which is introduced at smbfs_vnops.c rev 1.58 > > This will make instant panic when you try to access > file on mounted smbfs. > > This is caused by uninitialized vp. Committed, thanks! Cheers, -- Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20050410/311d6357/attachment.bin From q at uni.de Sun Apr 10 02:24:30 2005 From: q at uni.de (Ulrich Spoerlein) Date: Sun Apr 10 02:24:40 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 In-Reply-To: <200504100251.j3A2pLEH055107@sana.init-main.com> References: <200504100251.j3A2pLEH055107@sana.init-main.com> Message-ID: <20050410092417.GA774@galgenberg.net> On Sun, 10.04.2005 at 11:51:21 +0900, takawata@jp.freebsd.org wrote: > This is caused by uninitialized vp. The compiler should warn about this. But something fishy is going on ... foo.c: int main(void) { int a; a+=1; return (0); } % gcc -O -W -Wall -Wuninitialized -Winit-self foo.c % icc -Wbrief -Wall foo.c foo.c(3): remark #592: variable "a" is used before its value is set % tdfc2 -Wall foo.c >/dev/null "foo.c", line 2: Warning: [ISO C90 6.6.2]: Variable 'a' may be used without being set. "foo.c", line 4: Warning: [ISO C90 6.6.2]: Variable 'a' not used since previous assignment. % lint -i foo.c foo.c(3): warning: a may be used before set [158] % splint foo.c foo.c: (in function main) foo.c:3:3: Variable a used before definition Any magical flags for gcc I'm missing? Ulrich Sp?rlein -- PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20050410/091b3fb1/attachment.bin From schweikh at schweikhardt.net Sun Apr 10 04:09:02 2005 From: schweikh at schweikhardt.net (Jens Schweikhardt) Date: Sun Apr 10 04:09:11 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 In-Reply-To: <20050410092417.GA774@galgenberg.net> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410092417.GA774@galgenberg.net> Message-ID: <20050410110836.GA1355@schweikhardt.net> On Sun, Apr 10, 2005 at 11:24:17AM +0200, Ulrich Spoerlein wrote: # On Sun, 10.04.2005 at 11:51:21 +0900, takawata@jp.freebsd.org wrote: # > This is caused by uninitialized vp. # # The compiler should warn about this. But something fishy is going on ... # # foo.c: # int main(void) { # int a; # a+=1; # return (0); # } Not so fishy. No warning because -O completely optimizes 'a' away. Try this instead: $ cat foo.c int main(void) { int a; a+=1; return a; } $ gcc -O -W -Wall -Wuninitialized -Winit-self foo.c foo.c: In function `main': foo.c:2: warning: 'a' might be used uninitialized in this function Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From ellard at eecs.harvard.edu Sun Apr 10 04:46:02 2005 From: ellard at eecs.harvard.edu (Daniel Ellard) Date: Sun Apr 10 04:46:05 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 In-Reply-To: <20050410092417.GA774@galgenberg.net> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410092417.GA774@galgenberg.net> Message-ID: <20050410074009.N66651@bowser.eecs.harvard.edu> On Sun, 10 Apr 2005, Ulrich Spoerlein wrote: > Date: Sun, 10 Apr 2005 11:24:17 +0200 > From: Ulrich Spoerlein > To: takawata@jp.freebsd.org > Cc: freebsd-fs@freebsd.org, bp@freebsd.org, jeff@freebsd.org, > freebsd-current@freebsd.org > Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 > > On Sun, 10.04.2005 at 11:51:21 +0900, takawata@jp.freebsd.org wrote: > > This is caused by uninitialized vp. > > The compiler should warn about this. But something fishy is going on ... > > foo.c: > int main(void) { > int a; > a+=1; > return (0); > } > > % gcc -O -W -Wall -Wuninitialized -Winit-self foo.c Certainly this is undesireable, but from what I can tell this happens because "a" is a dead variable and removed. (Look at the asm output and you'll see what I mean.) So it's debatable whether this is a bug. If you change the -O to -g, then the code for "a" is not removed -- but there's still no warning. I think this is a bug, because if the expression wasn't an innocuous a+=1 it could be a real problem if the variable wasn't removed. But people will also argue about this.. -Dan From dimitry at andric.com Sun Apr 10 05:04:48 2005 From: dimitry at andric.com (Dimitry Andric) Date: Sun Apr 10 05:04:57 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 In-Reply-To: <20050410074009.N66651@bowser.eecs.harvard.edu> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410092417.GA774@galgenberg.net> <20050410074009.N66651@bowser.eecs.harvard.edu> Message-ID: <1892195662.20050410140423@andric.com> On 2005-04-10 at 13:45:50 Daniel Ellard wrote: >> int main(void) { >> int a; >> a+=1; >> return (0); >> } [snip] > If you change the -O to -g, then the code for "a" is not > removed -- but there's still no warning. I think this is > a bug, because if the expression wasn't an innocuous a+=1 > it could be a real problem if the variable wasn't removed. The idea here is that gcc sees that the value of a is never used, and therefore it doesn't have to warn. (Whether you agree with this, or not, is more of a political or philosophical question. ;) But as soon as you actually *do* something with a's value afterwards, it will start to complain. IOW, if you change main into: int main(void) { int a; a += 1; a++; //...bunch of other operations on a... ++a; a *= 3; return 0; } and gcc will still issue no warning. However, add one actual *use* of a: extern void f(int i); int main(void) { int a; a += 1; f(a); return 0; } and you'll get the warning you want... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 183 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20050410/d63688af/attachment.bin From ellard at eecs.harvard.edu Sun Apr 10 05:44:45 2005 From: ellard at eecs.harvard.edu (Daniel Ellard) Date: Sun Apr 10 05:44:49 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 In-Reply-To: <1892195662.20050410140423@andric.com> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410074009.N66651@bowser.eecs.harvard.edu> <1892195662.20050410140423@andric.com> Message-ID: <20050410082945.H66651@bowser.eecs.harvard.edu> On Sun, 10 Apr 2005, Dimitry Andric wrote: > > If you change the -O to -g, then the code for "a" is not > > removed -- but there's still no warning. I think this is > > a bug, because if the expression wasn't an innocuous a+=1 > > it could be a real problem if the variable wasn't removed. > > The idea here is that gcc sees that the value of a is never used, and > therefore it doesn't have to warn. (Whether you agree with this, or > not, is more of a political or philosophical question. ;) But as soon > as you actually *do* something with a's value afterwards, it will > start to complain. Well, I guess have to give an example... int main(void) { int a; int b[1]; a = b[a * 10000]; /* Uses the value of a. */ return (0); } If you compile this with -O, then the "a = " line is optimized away, and the deref of some random piece of memory goes away. If you compile this without the -O then now you have a deref to something whose address depends on an uninitialized variable. Sorry, that's bad. At least the gcc folk now do detect this old chestnut: { int a; a /= 0; } which was used to provoke arguments in compiler classes for many years. (Optimized, nothing happens. Unoptimized, a division-by-zero error happens...) My philosophy is that the compiler should warn you about things in the un-optimized, un-transformed code (because that's where I put my bugs -- if I've written code that has no effect, that's probably not what I meant). I'd rather get extraneous warnings than miss something. Of course, everyone is welcome to their own philosophy. (But how politics enter into this, I don't want to know.) -Dan From q at uni.de Sun Apr 10 06:21:43 2005 From: q at uni.de (Ulrich Spoerlein) Date: Sun Apr 10 06:21:52 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 In-Reply-To: <20050410074009.N66651@bowser.eecs.harvard.edu> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410092417.GA774@galgenberg.net> <20050410074009.N66651@bowser.eecs.harvard.edu> Message-ID: <20050410132135.GB774@galgenberg.net> On Sun, 10.04.2005 at 07:45:50 -0400, Daniel Ellard wrote: > Certainly this is undesireable, but from what I can tell this > happens because "a" is a dead variable and removed. (Look at > the asm output and you'll see what I mean.) So it's debatable > whether this is a bug. > > If you change the -O to -g, then the code for "a" is not > removed -- but there's still no warning. I think this is > a bug, because if the expression wasn't an innocuous a+=1 > it could be a real problem if the variable wasn't removed. > But people will also argue about this.. You are right, using something like this: #include int main(void) { int a,b; a+=1; b=1+a; printf("%d\n", b); return (0); } I get a warning: % cc -O -W -Wall -Wuninitialized foo.c foo.c: In function `main': foo.c:3: warning: 'a' might be used uninitialized in this function Sorry for the noise then. /me needs to learn asm some day. Ulrich Sp?rlein -- PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20050410/f23af906/attachment.bin From cswiger at mac.com Sun Apr 10 10:10:39 2005 From: cswiger at mac.com (Chuck Swiger) Date: Sun Apr 10 10:10:48 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 In-Reply-To: <20050410082945.H66651@bowser.eecs.harvard.edu> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410074009.N66651@bowser.eecs.harvard.edu> <1892195662.20050410140423@andric.com> <20050410082945.H66651@bowser.eecs.harvard.edu> Message-ID: <42595E04.60705@mac.com> Daniel Ellard wrote: > On Sun, 10 Apr 2005, Dimitry Andric wrote: [ ... ] > At least the gcc folk now do detect this old chestnut: > > { > int a; > > a /= 0; > } > > which was used to provoke arguments in compiler > classes for many years. (Optimized, nothing happens. > Unoptimized, a division-by-zero error happens...) Great example. If the optimized code fails to generate a division-by-zero error here, the optimizer is buggy. (I won't quote Aho, Sethi, and Ullman again.... :-) -- -Chuck From das at FreeBSD.ORG Sun Apr 10 10:49:42 2005 From: das at FreeBSD.ORG (David Schultz) Date: Sun Apr 10 10:49:52 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 In-Reply-To: <42595E04.60705@mac.com> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410074009.N66651@bowser.eecs.harvard.edu> <1892195662.20050410140423@andric.com><42595E04.60705@mac.com> Message-ID: <20050410174938.GA4842@VARK.MIT.EDU> On Sun, Apr 10, 2005, Chuck Swiger wrote: > Daniel Ellard wrote: > >On Sun, 10 Apr 2005, Dimitry Andric wrote: > [ ... ] > >At least the gcc folk now do detect this old chestnut: > > > > { > > int a; > > > > a /= 0; > > } > > > >which was used to provoke arguments in compiler > >classes for many years. (Optimized, nothing happens. > >Unoptimized, a division-by-zero error happens...) > > Great example. > > If the optimized code fails to generate a division-by-zero error here, the > optimizer is buggy. (I won't quote Aho, Sethi, and Ullman again.... :-) gcc's optimizer is notoriously bad with side-effects like this, particularly for floating-point code. The C99 standard requires that the compiler support the FENV_ACCESS pragma to tell the compiler that (among other things) it must not optimize away arithmetic that may generate an exception as a side-effect, but gcc doesn't implement it. Worse yet, gcc defaults to assuming that it *is* allowed to optimize such arithmetic operations away, even in expressions such as '1.0 / 0.0' where it's clear what the programmer wanted to happen. A number of routines in libm don't work properly at -O2 as a result of this, and in several places we play tricks such as declaring variables to be volatile or 'long double' just to trick the optimizer. IIRC, Steve Moshier wrote some gcc patches to fix this, but nobody ever committed them... From bde at zeta.org.au Sun Apr 10 10:55:39 2005 From: bde at zeta.org.au (Bruce Evans) Date: Sun Apr 10 10:55:42 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 In-Reply-To: <42595E04.60705@mac.com> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <1892195662.20050410140423@andric.com><42595E04.60705@mac.com> Message-ID: <20050411032601.S55302@delplex.bde.org> On Sun, 10 Apr 2005, Chuck Swiger wrote: > Daniel Ellard wrote: >> On Sun, 10 Apr 2005, Dimitry Andric wrote: > [ ... ] >> At least the gcc folk now do detect this old chestnut: >> >> { >> int a; >> >> a /= 0; >> } >> >> which was used to provoke arguments in compiler >> classes for many years. (Optimized, nothing happens. >> Unoptimized, a division-by-zero error happens...) > > Great example. > > If the optimized code fails to generate a division-by-zero error here, the > optimizer is buggy. (I won't quote Aho, Sethi, and Ullman again.... :-) No, the behaviour is undefined. The compiler can do anything. gcc now emits a warning even with -O0. A similar example with "double a;" is more interesting. This also gives undefined behaviour (C99 6.5.5[#5]). However, this is bogus if there is a floating point infinity. C99 has support for IEEE floating point and it is clearly intended that the behaviour of 1.0/0.0 is to give +Inf and raise the divide-by-zero exception, but I couldn't see anywhere in the C99 draft n869.txt where this is spelled out (raising of the divide-by-zero exception is spelled out for lots of math functions but doesn't seem to be mentioned for plain division). Also, in C99 with IEEE FP support, "#pragma STDC FENV_ACCESS *" should affect the behaviour. I'm not sure of the details, but think that programs can only depend on getting the divide-by-zero exception if FENV_ACCESS is ON. gcc still doesn't support this pragma, so it does several wrong things with FENV_ACCESS ON: - for "a = 1.0 / 0.0;", it evaluates 1.0 / 0.0 at compile time (even with -O0) so it never raises a divide-by-zero exception. - "a /= 0.0;" where "a" is not otherwise used is not dead code, since it should have the side effect of raising the exception, but gcc considers this code to be dead. Bruce From ertr1013 at student.uu.se Sun Apr 10 11:04:55 2005 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Sun Apr 10 11:05:05 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 In-Reply-To: <42595E04.60705@mac.com> References: <200504100251.j3A2pLEH055107@sana.init-main.com> <20050410074009.N66651@bowser.eecs.harvard.edu> <1892195662.20050410140423@andric.com><42595E04.60705@mac.com> Message-ID: <20050410180450.GA963@falcon.midgard.homeip.net> On Sun, Apr 10, 2005 at 01:10:28PM -0400, Chuck Swiger wrote: > Daniel Ellard wrote: > >On Sun, 10 Apr 2005, Dimitry Andric wrote: > [ ... ] > >At least the gcc folk now do detect this old chestnut: > > > > { > > int a; > > > > a /= 0; > > } > > > >which was used to provoke arguments in compiler > >classes for many years. (Optimized, nothing happens. > >Unoptimized, a division-by-zero error happens...) > > Great example. > > If the optimized code fails to generate a division-by-zero error here, the > optimizer is buggy. Not at all. Division by zero means undefined behaviour (at least in C.) Undefined behaviour means *anything* may happen - including no error happening. A compiler optimizing away the division-by-zero is perfectly correct in doing so. (It is also perfectly correct to not optimize away the error.) > (I won't quote Aho, Sethi, and Ullman again.... :-) No, please don't - especially since that quote you are so fond of isn't *quite* correct - an optimizer is allowed to change the output of a program as long as the new output is also correct according to the language specification. (Language specifications often do not specify every detail, with the result that for a given program it can be the case that more than one output can be correct. In C any instance of undefined behaviour in a program means that *no* aspect of the program is defined and therefore all different outputs will be equally correct.) -- Erik Trulsson ertr1013@student.uu.se From bakul at BitBlocks.com Sun Apr 10 11:43:31 2005 From: bakul at BitBlocks.com (Bakul Shah) Date: Sun Apr 10 11:43:41 2005 Subject: smbfs bug introduced at smbfs_vnops.c:1.58 In-Reply-To: Your message of "Mon, 11 Apr 2005 03:55:31 +1000." <20050411032601.S55302@delplex.bde.org> Message-ID: <200504101843.j3AIhUh0046427@gate.bitblocks.com> > A similar example with "double a;" is more interesting. This also > gives undefined behaviour (C99 6.5.5[#5]). However, this is bogus if > there is a floating point infinity. C99 has support for IEEE floating > point and it is clearly intended that the behaviour of 1.0/0.0 is to > give +Inf and raise the divide-by-zero exception, but I couldn't see > anywhere in the C99 draft n869.txt where this is spelled out (raising of > the divide-by-zero exception is spelled out for lots of math functions > but doesn't seem to be mentioned for plain division). This is indirectly spelled out in draft n2764.txt in annex F: F.3 Operators and functions [#1] C operators and functions provide IEC 60559 required and recommended facilities as listed below. -- The +, -, *, and / operators provide the IEC 60559 add, subtract, multiply, and divide operations. IEC 60599 (aka IEEE754) clearly states the behavior for divide by zero. 6.5.5 does say x/0 is undefined but if __STDC_IEC_559__ is defined then IEEE behavior is expected. I haven't checked gassy-c (gcc) for conformance. From gth at cmex.de Mon Apr 11 09:15:45 2005 From: gth at cmex.de (Gunther Thiel) Date: Mon Apr 11 09:15:47 2005 Subject: Stackable Filesystems/deadlock/VI_DOOMED Message-ID: <1113236140.685.33.camel@darthvader> I am working on stackable filesystems using 5.3-STABLE and figured that there are still deadlock problems when using the nullfs template on a busy, stressed machine. >From what I have experienced, apparently the deadlock occurs when trying to get a new node while it's being recycled. What I have seen in the VFS code of the CURRENT branch looks very promising (VI_DOOMED instead of VI_XLOCK!), but as I have no clue when new VFS stuff will be in a solid state, I wanted to ask if the problem is at all solveable with the VFS concept under 5.3 and if so, how. If it is not solveable (which is my personal guess) would someone mind giving me a hint on dependencies when I would only like to use as much stuff from CURRENT to move to new VFS concept (with all the ostentatious risks)? Thanks very much! Gunther From takawata at jp.freebsd.org Wed Apr 13 19:09:43 2005 From: takawata at jp.freebsd.org (takawata@jp.freebsd.org) Date: Wed Apr 13 19:09:46 2005 Subject: kern/78110: [patch] fixed multibyte treatment of Samba FS (smb/ctx.c). Message-ID: <200504140209.LAA17486@axe-inc.co.jp> I wrote a patch that can applied to -CURRENT at a few days ago. Please review it. If anyone don't make objections in a week, I'll commit it. Index: contrib/smbfs/lib/smb/ctx.c =================================================================== RCS file: /home/ncvs/src/contrib/smbfs/lib/smb/ctx.c,v retrieving revision 1.3 diff -u -r1.3 ctx.c --- contrib/smbfs/lib/smb/ctx.c 27 Jul 2003 11:41:38 -0000 1.3 +++ contrib/smbfs/lib/smb/ctx.c 7 Apr 2005 23:30:42 -0000 @@ -473,8 +473,6 @@ struct sockaddr *sap; struct sockaddr_nb *salocal, *saserver; char *cp; - u_char cstbl[256]; - u_int i; int error = 0; ctx->ct_flags &= ~SMBCF_RESOLVED; @@ -496,7 +494,7 @@ if (error) return error; if (ssn->ioc_localcs[0] == 0) - strcpy(ssn->ioc_localcs, "default"); /* XXX: locale name ? */ + strcpy(ssn->ioc_localcs, "ISO8859-1"); error = smb_addiconvtbl("tolower", ssn->ioc_localcs, nls_lower); if (error) return error; @@ -504,18 +502,9 @@ if (error) return error; if (ssn->ioc_servercs[0] != 0) { - for(i = 0; i < sizeof(cstbl); i++) - cstbl[i] = i; - nls_mem_toext(cstbl, cstbl, sizeof(cstbl)); - error = smb_addiconvtbl(ssn->ioc_servercs, ssn->ioc_localcs, cstbl); - if (error) - return error; - for(i = 0; i < sizeof(cstbl); i++) - cstbl[i] = i; - nls_mem_toloc(cstbl, cstbl, sizeof(cstbl)); - error = smb_addiconvtbl(ssn->ioc_localcs, ssn->ioc_servercs, cstbl); - if (error) - return error; + error = kiconv_add_xlat16_cspairs + (ssn->ioc_localcs, ssn->ioc_servercs); + if (error) return error; } if (ctx->ct_srvaddr) { error = nb_resolvehost_in(ctx->ct_srvaddr, &sap); Index: sys/fs/smbfs/smbfs_smb.c =================================================================== RCS file: /home/ncvs/src/sys/fs/smbfs/smbfs_smb.c,v retrieving revision 1.14 diff -u -r1.14 smbfs_smb.c --- sys/fs/smbfs/smbfs_smb.c 6 Jan 2005 18:10:41 -0000 1.14 +++ sys/fs/smbfs/smbfs_smb.c 7 Apr 2005 23:30:42 -0000 @@ -1449,8 +1449,8 @@ continue; break; } - smbfs_fname_tolocal(SSTOVC(ctx->f_ssp), ctx->f_name, ctx->f_nmlen, - ctx->f_dnp->n_mount->sm_caseopt); + smbfs_fname_tolocal(SSTOVC(ctx->f_ssp), ctx->f_name, &ctx->f_nmlen, + ctx->f_dnp->n_mount->sm_caseopt); ctx->f_attr.fa_ino = smbfs_getino(ctx->f_dnp, ctx->f_name, ctx->f_nmlen); return 0; } Index: sys/fs/smbfs/smbfs_subr.c =================================================================== RCS file: /home/ncvs/src/sys/fs/smbfs/smbfs_subr.c,v retrieving revision 1.5 diff -u -r1.5 smbfs_subr.c --- sys/fs/smbfs/smbfs_subr.c 6 Jan 2005 18:10:41 -0000 1.5 +++ sys/fs/smbfs/smbfs_subr.c 7 Apr 2005 23:40:24 -0000 @@ -316,13 +316,33 @@ } int -smbfs_fname_tolocal(struct smb_vc *vcp, char *name, int nmlen, int caseopt) +smbfs_fname_tolocal(struct smb_vc *vcp, char *name, int *nmlen, int caseopt) { -/* if (caseopt & SMB_CS_UPPER) - iconv_convmem(vcp->vc_toupper, name, name, nmlen); - else if (caseopt & SMB_CS_LOWER) - iconv_convmem(vcp->vc_tolower, name, name, nmlen);*/ - if (vcp->vc_tolocal) - iconv_convmem(vcp->vc_tolocal, name, name, nmlen); - return 0; + int copt = (caseopt == SMB_CS_LOWER ? KICONV_FROM_LOWER : + (caseopt == SMB_CS_UPPER ? KICONV_FROM_UPPER : 0)); + int error = 0; + int ilen = *nmlen; + int olen; + char *ibuf = name; + char outbuf[SMB_MAXFNAMELEN]; + char *obuf = outbuf; + + if (vcp->vc_tolocal) { + olen = sizeof(outbuf); + bzero(outbuf, sizeof(outbuf)); + + /* + error = iconv_conv_case + (vcp->vc_tolocal, NULL, NULL, &obuf, &olen, copt); + if (error) return error; + */ + + error = iconv_conv_case + (vcp->vc_tolocal, (const char **)&ibuf, &ilen, &obuf, &olen, copt); + if (!error) { + *nmlen = sizeof(outbuf) - olen; + memcpy(name, outbuf, *nmlen); + } + } + return error; } Index: sys/fs/smbfs/smbfs_subr.h =================================================================== RCS file: /home/ncvs/src/sys/fs/smbfs/smbfs_subr.h,v retrieving revision 1.5 diff -u -r1.5 smbfs_subr.h --- sys/fs/smbfs/smbfs_subr.h 10 Feb 2005 12:07:02 -0000 1.5 +++ sys/fs/smbfs/smbfs_subr.h 7 Apr 2005 23:30:42 -0000 @@ -174,7 +174,7 @@ int smbfs_smb_lookup(struct smbnode *dnp, const char *name, int nmlen, struct smbfattr *fap, struct smb_cred *scred); -int smbfs_fname_tolocal(struct smb_vc *vcp, char *name, int nmlen, int caseopt); +int smbfs_fname_tolocal(struct smb_vc *vcp, char *name, int *nmlen, int caseopt); void smb_time_local2server(struct timespec *tsp, int tzoff, u_long *seconds); void smb_time_server2local(u_long seconds, int tzoff, struct timespec *tsp); Index: usr.bin/smbutil/Makefile =================================================================== RCS file: /home/ncvs/src/usr.bin/smbutil/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- usr.bin/smbutil/Makefile 14 Dec 2001 11:41:22 -0000 1.1 +++ usr.bin/smbutil/Makefile 12 Apr 2005 04:32:52 -0000 @@ -3,8 +3,8 @@ PROG= smbutil SRCS= smbutil.c dumptree.c login.c lookup.c view.c print.c -DPADD= ${LIBSMB} -LDADD= -lsmb +DPADD= ${LIBSMB} ${LIBKICONV} +LDADD= -lsmb -lkiconv CONTRIBDIR= ${.CURDIR}/../../contrib/smbfs CFLAGS+= -I${CONTRIBDIR}/include Index: usr.sbin/mount_smbfs/Makefile =================================================================== RCS file: /home/ncvs/src/usr.sbin/mount_smbfs/Makefile,v retrieving revision 1.6 diff -u -r1.6 Makefile --- usr.sbin/mount_smbfs/Makefile 21 Dec 2004 09:59:44 -0000 1.6 +++ usr.sbin/mount_smbfs/Makefile 12 Apr 2005 04:32:26 -0000 @@ -9,8 +9,8 @@ CONTRIBDIR= ${.CURDIR}/../../contrib/smbfs CFLAGS+= -DSMBFS -I${MOUNTDIR} -I${CONTRIBDIR}/include -LDADD= -lsmb -DPADD= ${LIBSMB} +LDADD= -lsmb -lkiconv +DPADD= ${LIBSMB} ${LIBKICONV} # Needs to be dynamically linked for optional dlopen() access to # userland libiconv (see the -E option). From root at parse.com Wed Apr 27 12:18:34 2005 From: root at parse.com (Robert Krten) Date: Wed Apr 27 12:18:36 2005 Subject: Background block scrubbing Message-ID: <200504271918.PAA05842@parse.com> I don't know where to ask but here :-) Is there a utility that does background unused block scrubbing? What I'm thinking of is something that looks for unused blocks on the disk, and then writes zeros, then random, then more random, etc, to them for security applications. It would need to have some cooperation from the filesystem so that it could lock down a block (or ten, or some number) at a time that it could then go and "scrub" during idle periods... Since it would only allocate a few blocks at a time, it wouldn't need to have a mechanism to release them (IMHO). If there's nothing like it, can anyone give hints on where I should look in the source tree for an appropriate place to put such a thing? Thanks in advance! Cheers, -RK -- Robert Krten, PARSE Software Devices +1 613 599 8316. Looking for Digital Equipment Corp. PDP-1 through PDP-15 minicomputers! From des at des.no Wed Apr 27 14:17:58 2005 From: des at des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Wed Apr 27 14:18:02 2005 Subject: Background block scrubbing In-Reply-To: <200504271918.PAA05842@parse.com> References: <200504271918.PAA05842@parse.com> Message-ID: <867jin2a2p.fsf@xps.des.no> "Robert Krten" writes: > Is there a utility that does background unused block scrubbing? > > What I'm thinking of is something that looks for unused blocks on the > disk, and then writes zeros, then random, then more random, etc, to them > for security applications. That's not how it's done. Here's a good explanation of how to do it and why it must be done that way: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > It would need to have some cooperation from the filesystem so that it could > lock down a block (or ten, or some number) at a time that it could then go > and "scrub" during idle periods... Since it would only allocate a few > blocks at a time, it wouldn't need to have a mechanism to release them (IMHO). To do this safely, you have to first scrub the entire disk before partitioning / newfsing it, and when the disk is in use, scrub every single block that has held data but no longer does as soon as it is deallocated, and before reporting the I/O operation complete to the filesystem. Performance would be abysmal (it takes 35 passes to fully scrub each block), so in real life you'd be better off encrypting the disk (using gbde or something similar), and only scrubbing or bulk erasing it when you decomission it. DES -- Dag-Erling Sm?rgrav - des@des.no From aef-bounce at parse.com Wed Apr 27 14:25:12 2005 From: aef-bounce at parse.com (Authorized Email System) Date: Wed Apr 27 14:28:33 2005 Subject: Your email [ =?windows-1251?b?QUJWLkJHIODi8u7s4PLo9+XtIO7y4+7i7vA=?= ] Message-ID: <200504272125.RAA20372@parse.com> THIS IS AN AUTOMATICALLY-GENERATED EMAIL MESSAGE, PLEASE READ! Recently, you (or someone using your email address) sent an email to an email address @parse.com [from IP address 194.153.145.92] Due to the existing high volume of spam email that we receive, your email is currently in a holding area, and will not be presented to the recipient until you click on the following URL: http://www.parse.com:8080/cgi-bin/aefweb?whitelist=E8FE903E We will hold the email for 15 days, after which point it will be deleted. By clicking on the above URL, you will cause the queued email to be delivered, as well as all future emails. Please note the legal text below. For more information on this procedure, as well as frequently asked questions (FAQs) please visit the following URL: http://www.parse.com/aef/index.html We thank you for your understanding and cooperation in this matter. ------------------------------------------------------------------------------ LEGAL TEXT: We have a strict, zero-tolerance policy regarding spam email. Any form of advertising, or Unsolicited Commercial Email (UCE), which is sent will be dealt with severely, including but not limited to placing your email address on a blacklist, notifying your ISP, etc. at our sole discretion. By clicking on the provided URL, you thereby certify that the sent email is neither spam nor UCE, and in case it is, you thereby agree to be liable for any and all related costs associated with damages, direct, consequential, or other, however caused. ------------------------------------------------------------------------------ From ellard at eecs.harvard.edu Wed Apr 27 15:43:31 2005 From: ellard at eecs.harvard.edu (Daniel Ellard) Date: Wed Apr 27 15:43:34 2005 Subject: Background block scrubbing In-Reply-To: <867jin2a2p.fsf@xps.des.no> References: <200504271918.PAA05842@parse.com> <867jin2a2p.fsf@xps.des.no> Message-ID: <20050427183037.E46204@bowser.eecs.harvard.edu> On Wed, 27 Apr 2005, [iso-8859-1] Dag-Erling Sm=F8rgrav wrote: > "Robert Krten" writes: > > Is there a utility that does background unused block scrubbing? > > > > What I'm thinking of is something that looks for unused blocks on the > > disk, and then writes zeros, then random, then more random, etc, to the= m > > for security applications. > > That's not how it's done. Here's a good explanation of how to do it > and why it must be done that way: > > http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html That's not how it's done *now*, but it could be done like that in the future. The problem with this approach is that it might take an unknown amount of time before a particular block is sufficiently scrubbed. If the user needs to have something scrubbed right away (or by any given time) then this won't work -- but if the user has relaxed time constraints and a good amount of idle time, this doesn't seem like a bad way to get started on the process. Another suggestion -- look at the work done on free block scheduling, which opportunistically schedules I/Os for "free" during time that would ordinarily be rotational delays. There was a study a few years ago that showed that a free block scheduler could read or write every block on a disk in a matter of hours, even if the disk was heavily utilized during this period -- no need to wait for the disk to be idle. [Note that this scheduleing is "free" in terms of time, but not power or wear -- if you've got a disk that's designed to be idle a good fraction of the time, like most PC disks, this could cook it.] -Dan From root at parse.com Thu Apr 28 06:04:40 2005 From: root at parse.com (Robert Krten) Date: Thu Apr 28 06:04:44 2005 Subject: Background block scrubbing In-Reply-To: <867jin2a2p.fsf@xps.des.no> from "=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=" at Apr 27, 2005 11:17:50 PM Message-ID: <200504281304.JAA02215@parse.com> =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= sez... > > "Robert Krten" writes: > > Is there a utility that does background unused block scrubbing? > > > > What I'm thinking of is something that looks for unused blocks on the > > disk, and then writes zeros, then random, then more random, etc, to them > > for security applications. > > That's not how it's done. Here's a good explanation of how to do it > and why it must be done that way: > > http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html Thanks! > > It would need to have some cooperation from the filesystem so that it could > > lock down a block (or ten, or some number) at a time that it could then go > > and "scrub" during idle periods... Since it would only allocate a few > > blocks at a time, it wouldn't need to have a mechanism to release them (IMHO). > > To do this safely, you have to first scrub the entire disk before > partitioning / newfsing it, and when the disk is in use, scrub every > single block that has held data but no longer does as soon as it is > deallocated, and before reporting the I/O operation complete to the > filesystem. Performance would be abysmal (it takes 35 passes to fully > scrub each block), so in real life you'd be better off encrypting the > disk (using gbde or something similar), and only scrubbing or bulk > erasing it when you decomission it. Gotcha. I wasn't aware it was *35* :-) I was thinking/hoping more like 3 or 4 with random garbage. Thanks for the info! Cheers, -RK -- Robert Krten, PARSE Software Devices +1 613 599 8316. Realtime Systems Architecture, Consulting, Books and Training at www.parse.com Looking for Digital Equipment Corp. PDP-1 through PDP-15 minicomputers! From arne_woerner at yahoo.com Thu Apr 28 07:02:50 2005 From: arne_woerner at yahoo.com (Arne Wörner) Date: Thu Apr 28 07:02:52 2005 Subject: Background block scrubbing In-Reply-To: <200504281304.JAA02215@parse.com> Message-ID: <20050428140249.88064.qmail@web41203.mail.yahoo.com> --- Robert Krten wrote: > =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= sez... > > "Robert Krten" writes: > > > Is there a utility that does background unused block > > > scrubbing? > > > > > > What I'm thinking of is something that looks for unused > > > blocks on the > > > disk, and then writes zeros, then random, then more > > > random, etc, to them for security applications. > > > > That's not how it's done. Here's a good explanation of how > > to do it and why it must be done that way: > > > > http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > I think, that article dramatizes the problem a little, because: It says itself in the end, that with modern hard discs writing random data would be enough (so it is just 8 or so; I did not read the whole article and I am not so good in such things, but I do not know, why it should be possible to know, if a suspected former value of a bit should be the value the attacker is looking for (e. g. MY_DATA, RANDOM_1, RANDOM_2: since just RANDOM_2 is known in the beginning I do not see how an attacker should find MY_DATA by looking at slight variations in magnetization without knowing RANDOM_1); of course it would be necessary to chose good random data (no repetitive/periodic behaviour)). Maybe I should read that article closer... :-) > Gotcha. I wasn't aware it was *35* :-) I was thinking/hoping > more like 3 or 4 with random garbage. > (citation from the above mentioned paper:) "Modern PRML/EPRML" drives (whatever that might be; I think my hard discs both do PRML) just need some random data passes... So you should first check, which kind of drive you need a tool for. Furthermore overwriting the old data once with zeroes should protect you against most attackers... Especially when they are remote attackers, that have to use your operating system for the attack... Maybe you should analysze the kind of attacks, you want to care for: Will they get physical access to your hard disc? Or will they just read from the raw device (/dev/ad0...) with "dd" or so? -Arne __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From brooks at one-eyed-alien.net Thu Apr 28 10:28:38 2005 From: brooks at one-eyed-alien.net (Brooks Davis) Date: Thu Apr 28 10:28:44 2005 Subject: Background block scrubbing In-Reply-To: <20050428140249.88064.qmail@web41203.mail.yahoo.com> References: <200504281304.JAA02215@parse.com> <20050428140249.88064.qmail@web41203.mail.yahoo.com> Message-ID: <20050428172836.GA30626@odin.ac.hmc.edu> On Thu, Apr 28, 2005 at 07:02:49AM -0700, Arne W?rner wrote: > --- Robert Krten wrote: > > Gotcha. I wasn't aware it was *35* :-) I was thinking/hoping > > more like 3 or 4 with random garbage. > > > (citation from the above mentioned paper:) "Modern PRML/EPRML" > drives (whatever that might be; I think my hard discs both do > PRML) just need some random data passes... So you should first > check, which kind of drive you need a tool for. The paper is actually pretty clean that you do not need all 35 passes. Most of the patterns are for specific encodins your drive doesn't use. IIRC (it's been a few years since I read this and the really stupid DoD standard it refrences), for any drive other than a floppy random is the only thing that matters and for a floppy breaking the case, removing the floppy, and burning it is much faster and 100% effective. With HDDs there's the additional issue that bad block remapping happens below the surface so you can't actually know you've written to the only physical copy of the block. The issue the paper doesn't address that is relevent today is modern flash drives. There is clearly going to be resedue of the bits in the flash is it's there in DRAM, but you can't even get direct access to the raw bits due to wear balancing. What I'd like to see is a simple zeroing of blocks when they are freed so deletes actually remove the files from the hot disk. That would be a slight (though imperfect) improvement over the current situation for hot disks. You can then use gbde for cold disk protection. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20050428/695082fd/attachment.bin From das at FreeBSD.ORG Thu Apr 28 15:29:22 2005 From: das at FreeBSD.ORG (David Schultz) Date: Thu Apr 28 15:29:24 2005 Subject: Background block scrubbing In-Reply-To: <20050428140249.88064.qmail@web41203.mail.yahoo.com> References: <200504281304.JAA02215@parse.com> <20050428140249.88064.qmail@web41203.mail.yahoo.com> Message-ID: <20050428222621.GA18634@VARK.MIT.EDU> On Thu, Apr 28, 2005, Arne WXrner wrote: > --- Robert Krten wrote: > > =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= sez... > > > "Robert Krten" writes: > > > > Is there a utility that does background unused block > > > > scrubbing? > > > > > > > > What I'm thinking of is something that looks for unused > > > > blocks on the > > > > disk, and then writes zeros, then random, then more > > > > random, etc, to them for security applications. > > > > > > That's not how it's done. Here's a good explanation of how > > > to do it and why it must be done that way: > > > > > > http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html > > > I think, that article dramatizes the problem a little, because: It > says itself in the end, that with modern hard discs writing random > data would be enough (so it is just 8 or so; I did not read the > whole article and I am not so good in such things, but I do not If you're truly paranoid, 1000 rewrites isn't enough. Consider, for instance, that when the disk encounters problems reading a particular sector, it will automatically reallocate that (logical) sector somewhere else. Hence, the original sensitive information remains on the disk no matter how many times the OS tells the disk to write over the sector. Furthermore, the firmware programs on modern high-end disk arrays are just like operating systems in the sense they have their own bugs, race conditions, etc. Misdirected and phantom writes, however rare, can also expose your secret data. If you're going to write your data to disk unencrypted, you have to trust that everything from the OS I/O path to the device driver to the disk controller to the disk is working correctly. By simply using encryption, you can save on all of those rewrites with random garbage and at the same time take a lot out of the trusted computing base.