From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 27 07:05:54 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78AAC16A4CE for ; Sun, 27 Feb 2005 07:05:54 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CFA143D49 for ; Sun, 27 Feb 2005 07:05:54 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so32038rns for ; Sat, 26 Feb 2005 23:05:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=M/sSjUPfCcwuCVsOhRrvPL0U2qQXstbbEtvidTpCb92Pi5hi+rDWOZzxn4Hu1LKHUz+/7kvm+E+JKRzYDo6rQDCbk2NQJlQdgYHWPq2RVYca8vx80Vuh5fN63wIAJPJhwvB9DHU2jK2KSFcA/wupLpG7FoI6NX2JzVPbsH1/HUc= Received: by 10.38.206.76 with SMTP id d76mr14350rng; Sat, 26 Feb 2005 23:05:53 -0800 (PST) Received: by 10.38.8.9 with HTTP; Sat, 26 Feb 2005 23:05:53 -0800 (PST) Message-ID: Date: Sun, 27 Feb 2005 15:05:53 +0800 From: Jiawei Ye To: John-Mark Gurney , Yan Yu , freebsd-hackers@freebsd.org In-Reply-To: <20050226093907.GM89312@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050226072645.76950.qmail@web26802.mail.ukl.yahoo.com> <20050226093907.GM89312@funkthat.com> Subject: Re: send file descriptor via ipc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jiawei Ye List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 07:05:54 -0000 On Sat, 26 Feb 2005 01:39:07 -0800, John-Mark Gurney wrote: > You can also look at unix(4) which has a brief description.. You must > use unix domain sockets in order to pass file descriptors, and so the > unp probably refers to UNix Protocol... but I could be wrong about > that... > > -- > John-Mark Gurney Voice: +1 415 225 5579 I always thought the unp_ prefix referred to Unix Network Programming (http://www.kohala.com/start/unpv12e.html) since most sample code given in the book had the prefix. But I may be wrong here :) -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 27 07:22:03 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBFC016A4CE for ; Sun, 27 Feb 2005 07:22:03 +0000 (GMT) Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.128.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id A205643D4C for ; Sun, 27 Feb 2005 07:22:03 +0000 (GMT) (envelope-from yanyu@CS.UCLA.EDU) Received: from localhost (yanyu@localhost)j1R7M3504447 for ; Sat, 26 Feb 2005 23:22:03 -0800 (PST) Date: Sat, 26 Feb 2005 23:22:03 -0800 (PST) From: Yan Yu To: freebsd-hackers@freebsd.org In-Reply-To: Message-ID: References: <20050226072645.76950.qmail@web26802.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: function prototype of fdrop() and fdrop_locked() in kern_descrip.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 07:22:03 -0000 HI, all, I have a Q on the input parameter of fdrop() and fdrop_locked() in kern/kern_descrip.c. i am curious about the design choice of their input parameter. currently, it is defined as ---------------------------------------- A) fdrop( struct file *, struct thread *) ---------------------------------------- I added some field in the file descriptor table, and need to do some bookkeeping whenever a file descriptor is freed. It would be much easier for me if fdrop() is defined as --------------------------------- B) fdrop( int fd, struct thread *) --------------------------------- then i could just instrument the fdrop function as opposed to change every place that calls the fdrop() function. btw, there are more than 100 places that calls fdrop():( I am wondering about what is the motivation of fdrop is defined as A) as opposed to B).. or it is an arbitrary design choice? it seems to me fdrop is called usually when an fd is freed(or is there other reason that fdrop get called?), then fdrop(int fd, thread *) seems a natural choice.. many thanks, yan From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 27 11:05:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D705416A4CE for ; Sun, 27 Feb 2005 11:05:22 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id F38E643D3F for ; Sun, 27 Feb 2005 11:05:21 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 27 Feb 2005 11:05:21 +0000 (GMT) Date: Sun, 27 Feb 2005 11:05:19 +0000 From: David Malone To: Yan Yu Message-ID: <20050227110519.GA23630@walton.maths.tcd.ie> References: <20050226072645.76950.qmail@web26802.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie cc: freebsd-hackers@freebsd.org Subject: Re: function prototype of fdrop() and fdrop_locked() in kern_descrip.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 11:05:22 -0000 On Sat, Feb 26, 2005 at 11:22:03PM -0800, Yan Yu wrote: > I am wondering about what is the motivation of fdrop is defined as > A) as opposed to B).. or it is an arbitrary design choice? > it seems to me fdrop is called usually when an fd is freed(or is there > other reason that fdrop get called?), fdrop is called to drop the reference count in a file structure. That file structure may or may not correspond to a file that has an entry in the file discriptor table. For example, suppose you have two processes sharing a file discriptor table (as happens with certain threading schemes) and the following happens: thread 1 thread 2 calls read on fd 1 *sleeps in read* closes fd 1 read completes At the time read completes, there is no entry in any file discriptor table for fd 1, but read is still using the file structure, so it must remain valid even though the file has been closed. Similar things can happen while descriptors are being passed over Unix domain sockets. So, fdrop is to do with the lifetime of the file structure not the lifetime of the file discriptor entry. If you want to track file discriptor entries, you'll have to track where fd_ofiles is manuipulated - these should be fairly obvious as they all involve grabbing the FILEDESC_LOCK. David. From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 27 12:57:59 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C031116A4E6 for ; Sun, 27 Feb 2005 12:57:59 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5368143D49 for ; Sun, 27 Feb 2005 12:57:59 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j1QH2KoH093866; Sat, 26 Feb 2005 09:02:21 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j1QH2Emp093865; Sat, 26 Feb 2005 09:02:14 -0800 (PST) (envelope-from www) Date: Sat, 26 Feb 2005 09:02:14 -0800 (PST) Message-Id: <200502261702.j1QH2Emp093865@marlena.vvi.at> To: sirmoo@cowbert.2y.net From: "ALeine" cc: freebsd-hackers@freebsd.org Subject: Re: sandisk cruzer mini quirks [failure] on RELENG_4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 12:57:59 -0000 sirmoo@cowbert.2y.net wrote: > I did this as the first hack. It made the problem worse. I'll try > patching both umass.c and scsi_da.c maybe they will have some sort of > synergistic effect. You said the problem occurs only when you copy files to the device using cp(1) and not dd(1). The main difference between how cp(1) and dd(1) copy files (other than cp(1) mmap(2)-ing files which are <= 8 Mb in size) is that cp(1) copies files in 64kb (MAXBSIZE) chunks while dd(1) copies files in 512 byte chunks by default. They both use read(2) and write(2), so I would suggest using dd with bs=64k and then applying the bisection method to find the largest transfer block size for writing the device can handle. Does this problem occur with cpdup (ports/sysutils/cpdup) as well? It currently copies files in 32kb chunks, which could easily be changed since the transfer block size is set in a single place. You may want to patch cpdup to use the maximum transfer block size the device can handle as a temporary workaround and then use cpdup for copying files to the device. > maybe i should just bite the bullet and upgrade the box to 5.3. Let's hope you won't have to. :-) Can you verify that this problem does not occur on 5.x without upgrading (by using a FreeSBIE LiveCD)? ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 27 08:20:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1799616A4CE for ; Sun, 27 Feb 2005 08:20:42 +0000 (GMT) Received: from cowbert.2y.net (d46h180.public.uconn.edu [137.99.46.180]) by mx1.FreeBSD.org (Postfix) with SMTP id 704D143D2D for ; Sun, 27 Feb 2005 08:20:41 +0000 (GMT) (envelope-from sirmoo@cowbert.2y.net) Received: (qmail 6895 invoked by uid 1001); 27 Feb 2005 08:20:40 -0000 Date: Sun, 27 Feb 2005 03:20:40 -0500 From: "Peter C. Lai" To: ALeine Message-ID: <20050227082040.GB265@cowbert.2y.net> References: <200502251803.j1PI3tsN074534@marlena.vvi.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502251803.j1PI3tsN074534@marlena.vvi.at> User-Agent: Mutt/1.5.6i X-Mailman-Approved-At: Sun, 27 Feb 2005 13:09:05 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: sandisk cruzer mini quirks [failure] on RELENG_4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 08:20:42 -0000 On Fri, Feb 25, 2005 at 10:03:55AM -0800, ALeine wrote: > sirmoo@cowbert.2y.net wrote: > > > I have a 512mb version of the SanDisk Cruzer Mini keychain drive. > > ProductId = 0x5150 (VendorID=0x0781). I am unable to correctly > > get it to stop crashing the system when using cp(1) to copy large > > files to it. > > I patched /usr/src/sys/dev/usb/umass.c as: > > > > if (UGETW(dd->idVendor) == USB_VENDOR_SANDISK && > > (UGETW(dd->idProduct) == 0x5150) { > > sc->proto = UMASS_PROTO_SCSI | UMASS_PROTO_BBB; > > sc->quirks |= IGNORE_RESIDUE; > > } > > Try extending da_quirk_table in sys/cam/scsi/scsi_da.c with an > entry like this: > > { > /* > * SanDisk Cruzer Mini 512MB > */ > {T_DIRECT, SIP_MEDIA_REMOVABLE, "SanDisk" , "Cruzer Mini", "*"}, > /*quirks*/ DA_Q_NO_SYNC_CACHE > } > I did this as the first hack. It made the problem worse. I'll try patching both umass.c and scsi_da.c maybe they will have some sort of synergistic effect. maybe i should just bite the bullet and upgrade the box to 5.3. pete -- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/ From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 27 15:48:07 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2203716A4CE for ; Sun, 27 Feb 2005 15:48:07 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 598C743D5C for ; Sun, 27 Feb 2005 15:48:06 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id j1RFj4XX054712 for hackers@FreeBSD.org.checked; Sun, 27 Feb 2005 18:45:04 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (localhost.cronyx.ru [127.0.0.1]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id j1RFgM6F054683; Sun, 27 Feb 2005 18:42:22 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <4221E816.6030407@cronyx.ru> Date: Sun, 27 Feb 2005 18:32:38 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: =?KOI8-R?Q?=E0=D2=C9=CA?= References: <892267968.20050225115047@mail.ru> In-Reply-To: <892267968.20050225115047@mail.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit cc: hackers@FreeBSD.org Subject: Re: Install Free BSD without floppy, without bootableCD-ROM-drive, without boot from LAN etc. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 15:48:07 -0000 嘁墒: >Hello hackers, > >I wrote to @questions, but as result, I have advised to address the help to you. > >Sorry, if I spend your time > >I have notebook IP-120MHz without FDD >He is NOT BOOT from CD. > >How can i install FreeBSD on it? > > >Hardvare configuration: >Compaq 5280 >Intel Pentium 120MHz >80Mb RAM >4,3 Gb HDD Hitachi >CD-ROM -8x Panasonic (I CAN NOT boot from it) > > >NO able boot from LAN, NO FDD, >2,5" HDD - I can't connect this HDD to desktop and install FreeBSD on it. > Why? Or you just don't have a connector? By the way, do you have USB? You may also try another copy of CD, or better original one. Best regards, Roman Kurakin > >I try to load a kernen from DOS-partition usin "bsdboot.com kernel", >but it have called a panic because of impossibility to mount root partition > >BUT I read in file /tools/00_index.txt (line 1): > >setup.exe Prepare for installation from a DOS partition. > > >I hope it help me, but I can not FOUND IT - >I can't found setup.exe in the installatoin CD-ROM, >in the ftp-server on freebsd.org > >Where I can found this utilite??? > > >Whether there is any other way of installation? > > > >How can i install FreeBSD? > > > > > From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 27 19:29:53 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3B3216A4CE for ; Sun, 27 Feb 2005 19:29:53 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71DEA43D55 for ; Sun, 27 Feb 2005 19:29:53 +0000 (GMT) (envelope-from opensource.enthousiat@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so698976wri for ; Sun, 27 Feb 2005 11:29:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=KZt91atTVVEEcYkWcfyqVbEwkSU40F4Pyn7JUeLh2LLklVgdoxFvpF96S79Nq3R+Zyea0dFyxSdmUQ/bFwUs4m8KjYC4XPluaiZvGaRdxG8FTgHRQHzXANjR9ZHJnkpyNnsSwH34UeDHRrULmCgonno2MiG/01w2xcXUzHNFWR4= Received: by 10.54.14.31 with SMTP id 31mr52298wrn; Sun, 27 Feb 2005 11:29:52 -0800 (PST) Received: by 10.54.49.28 with HTTP; Sun, 27 Feb 2005 11:29:52 -0800 (PST) Message-ID: <37e1316605022711293bd1e8b5@mail.gmail.com> Date: Sun, 27 Feb 2005 14:29:52 -0500 From: Aziz KEZZOU To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: intercepting RSVP packets with netgraph X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aziz KEZZOU List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 19:29:53 -0000 Hi all, I've read every thing I could find about netgraph but I still can not figure out how to intercept (divert) all IP packets of a certain type (say RSVP) and call my own function to process them. Notice that the processing has to occur at the kernel level. Any help is appreciated. Thanks in advance. Aziz Kezzou From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 27 22:55:31 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 801A116A4CE for ; Sun, 27 Feb 2005 22:55:31 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id D863543D53 for ; Sun, 27 Feb 2005 22:55:30 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j1R30DoH003564; Sat, 26 Feb 2005 19:00:14 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j1R306ZM003563; Sat, 26 Feb 2005 19:00:06 -0800 (PST) (envelope-from www) Date: Sat, 26 Feb 2005 19:00:06 -0800 (PST) Message-Id: <200502270300.j1R306ZM003563@marlena.vvi.at> To: elric@imrryr.org From: "ALeine" cc: freebsd-hackers@freebsd.org cc: tech-security@NetBSD.org cc: kernel@crater.dragonflybsd.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 22:55:31 -0000 elric@imrryr.org wrote: > [ cc'ing tech-security@NetBSD.org, because there has been talk > of GBDE there in the past.] > > Well, I thought that since I saw this: > > ALeine wrote a while ago: > >df@xxxxxx wrote: > >> > >> Wouldn't be easier porting cgd* from NetBSD ? > >> > >> * http://www.netbsd.org/guide/en/chap-cgd.html > > > >Perhaps, but I believe GBDE to be superior to CGD for a number > >of reasons, one of the most important being that with GBDE you > >can change the passphrase without re-encrypting the entire disk, > >which is not the case with CGD, AFAIK. From Poul-Henning Kamp's > >paper on GBDE: > > That, as the author of CGD, I should respond to some common > misconceptions about my work which seem to be percolating around. > > First, on the capability front, you can: > > 1. change the passphrase on a disk without re-encrypting it, > 2. have as many passphrases as you would like to configure, > 3. use n-factor authentication with arbitrary large n. > > Also, GBDE has a number of serious drawbacks. All of which would > be show-stoppers if I were considering using it for serious security > work, or even use in a production environment. > > There is no protection _at_all_ against dictionary attacks. Where > CGD uses PKCS#5 in a completely standard way to frustrate dictionary > attacks, GBDE does exactly nothing. In fact, worse than nothing. > It is possible to conduct half of the dictionary attack offline, > so the actual online portion of the attack is something that my > laptop could make about 2^30 guesses in a couple of hours. So, it > is insecure from the start. > > GBDE has no facility for using different encryption algorithms than > the rather... interesting one that it comes with. There is no > way to trade speed and security for different use cases, and the > only algorithm that it comes with is very slow. Less than half > the performance of CGD's most secure algorithm (AES256). > > So, now that we've touched on the security problems... Let's think > about using GBDE in production. Please reference > > http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf > > And read Section 7.5, and refer to figure 2. > > Each disk write involves two writes to the disk. Where is the > journal? I do not see any talk about a journal in the paper, or > the GBDE source code. Hence, if the OS crashes or if a removable > disk is removed at the wrong time, etc. etc. it is possible that > only one of those writes would succeed. I think that we can all > see where this is going. > > -- > Roland Dowdeswell http://www.Imrryr.ORG/~elric/ Thank you for taking the time to write that very informative post. I was not fully aware of all the issues you raised here, I'll look into them. In the meantime maybe someone more familiar with GBDE than myself could share their comments. I am CC:-ing this to freebsd-hackers@freebsd.org as well since I originally posted there as well. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 00:15:44 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB06316A4E9 for ; Mon, 28 Feb 2005 00:15:43 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2A8E43D58 for ; Mon, 28 Feb 2005 00:15:42 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.254] ([192.168.2.2]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j1S0FW85094993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Feb 2005 01:15:41 +0100 (CET) (envelope-from sobomax@FreeBSD.org) Message-ID: <42226293.7040603@FreeBSD.org> Date: Mon, 28 Feb 2005 02:15:15 +0200 From: Maxim Sobolev User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: dragonfly.kernel To: Roland Dowdeswell References: <20050227213032.CCB973700F@arioch.imrryr.org> In-Reply-To: <20050227213032.CCB973700F@arioch.imrryr.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/685/Wed Jan 26 10:08:24 2005 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: freebsd-hackers@FreeBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 00:15:44 -0000 Roland Dowdeswell wrote: > [ cc'ing tech-security@NetBSD.org, because there has been talk > of GBDE there in the past.] > > Well, I thought that since I saw this: > > ALeine wrote a while ago: > >>df@xxxxxx wrote: >> >>>Wouldn't be easier porting cgd* from NetBSD ? >>> >>>* http://www.netbsd.org/guide/en/chap-cgd.html >> >>Perhaps, but I believe GBDE to be superior to CGD for a number >>of reasons, one of the most important being that with GBDE you >>can change the passphrase without re-encrypting the entire disk, >>which is not the case with CGD, AFAIK. From Poul-Henning Kamp's >>paper on GBDE: > > > That, as the author of CGD, I should respond to some common > misconceptions about my work which seem to be percolating around. > > First, on the capability front, you can: > > 1. change the passphrase on a disk without re-encrypting it, > 2. have as many passphrases as you would like to configure, > 3. use n-factor authentication with arbitrary large n. > > Also, GBDE has a number of serious drawbacks. All of which would > be show-stoppers if I were considering using it for serious security > work, or even use in a production environment. > > There is no protection _at_all_ against dictionary attacks. Where > CGD uses PKCS#5 in a completely standard way to frustrate dictionary > attacks, GBDE does exactly nothing. In fact, worse than nothing. > It is possible to conduct half of the dictionary attack offline, > so the actual online portion of the attack is something that my > laptop could make about 2^30 guesses in a couple of hours. So, it > is insecure from the start. Well, I think that this is quite minor item, since GBDE doesn't govern transformation of the passphrase into the actual key, so that another scheme more bullet-prof against dictionary attacks (PKCS#5 or any other) can be developed in virtually no time at all and will require making only minor changes to the userland utility which gets password from the keyboard or command line, hashes it and feeds to the kernel. > GBDE has no facility for using different encryption algorithms than > the rather... interesting one that it comes with. There is no > way to trade speed and security for different use cases, and the > only algorithm that it comes with is very slow. Less than half > the performance of CGD's most secure algorithm (AES256). Well, it's hard to comment on this, since the only paper that I have found on CGD is http://www.imrryr.org/~elric/cgd/cgd.pdf, which unfortunately doesn't provide any details on how CGD encrypts data and lays it out on disk. > So, now that we've touched on the security problems... Let's think > about using GBDE in production. Please reference > > http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf > > And read Section 7.5, and refer to figure 2. > > Each disk write involves two writes to the disk. Where is the > journal? I do not see any talk about a journal in the paper, or > the GBDE source code. Hence, if the OS crashes or if a removable > disk is removed at the wrong time, etc. etc. it is possible that > only one of those writes would succeed. I think that we can all > see where this is going. So what? If the write fails in the middle, reading sector will just produce garbage. I don't think that it's different from plain old HDD which has been powered down in the middle of doing disk write. Disk encryption layer is definitely not the level at which journaling should be implemented. It's task of file system to do this. The task of encryption layer is merely to inform the file system when transaction (i.e. both of those two writes in this case) have been completed successfully, so that FS can adjust its journal accordingly. -Maxim From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 02:11:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C868016A4CF for ; Mon, 28 Feb 2005 02:11:36 +0000 (GMT) Received: from smtp.ucla.edu (smtp.ucla.edu [169.232.46.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94A4E43D46 for ; Mon, 28 Feb 2005 02:11:36 +0000 (GMT) (envelope-from ashcs@ucla.edu) Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.135]) by smtp.ucla.edu (8.13.2/8.13.2) with ESMTP id j1S2BaYn018563 for ; Sun, 27 Feb 2005 18:11:36 -0800 Received: from ash (s226-171.resnet.ucla.edu [164.67.226.171]) (authenticated bits=0) by mail.ucla.edu (8.13.3/8.13.3) with ESMTP id j1S2BaSP027007 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 27 Feb 2005 18:11:36 -0800 Message-ID: <000801c51d3a$e1ac47c0$abe243a4@ash> From: "Ashwin Chandra" To: Date: Sun, 27 Feb 2005 18:11:57 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Probable-Spam: no X-Spam-Hits: 1.054 X-Spam-Score: * X-Scanned-By: smtp.ucla.edu on 169.232.46.136 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Priority Increasing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 02:11:37 -0000 Hi all, Ive been trying to counter the malicious effects of a forkbomb by = setting the forkbomb parent and children to a PRI_MAX priority, although = this is not having any effect on the system load. Basically in my code when I know which process is acting maliciously = (forkbomb), I run the following simple code: FOREACH_KSEGRP_IN_PROC(p, kg) { printf("old prio:%d", kg->kg_user_pri); kg->kg_user_pri =3D PRI_MAX; printf(" new prio:%d", kg->kg_user_pri); } When it prints out, the old prio was 180 and the new gets set to 255 = although there is help to the system...the system is still under stress. = Do you guys know any good ways of hacking the scheduler to make a = process that is bad run MUCH MUCH less as to not overload the system? Ash From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 03:28:24 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8196616A4CE for ; Mon, 28 Feb 2005 03:28:24 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 180F643D46 for ; Mon, 28 Feb 2005 03:28:24 +0000 (GMT) (envelope-from zombyfork@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so800405rng for ; Sun, 27 Feb 2005 19:28:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=KOYLcTFVv+eOMze7gv3G5LtLixngsKEuImTXNJn3t89ZWq0yzHcHbINe2ofgkZEBrGLhdWGGmjcRXgNaRe0XOyiWr9zEpgA12krLJw950PtzFoNq1zmExyOLDR2EWc94GBXoh71XC6DTKxijhynS7t7dOn12rymOhwY9n3p0yiE= Received: by 10.38.153.46 with SMTP id a46mr161527rne; Sun, 27 Feb 2005 19:28:23 -0800 (PST) Received: by 10.38.22.22 with HTTP; Sun, 27 Feb 2005 19:28:23 -0800 (PST) Message-ID: <346a8022050227192871c65779@mail.gmail.com> Date: Sun, 27 Feb 2005 22:28:23 -0500 From: Coleman Kane To: Ashwin Chandra In-Reply-To: <000801c51d3a$e1ac47c0$abe243a4@ash> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <000801c51d3a$e1ac47c0$abe243a4@ash> cc: freebsd-hackers@freebsd.org Subject: Re: Priority Increasing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cokane@cokane.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 03:28:24 -0000 Well, since the program is running a forkbomb, it is gonna stress out the kernel. The kernel is constantly creating new process spaces, as well as filling in the queue. Are we talking a O(2^n) forkbomb here (where the forks also fork)? Remember, there is overhead associated with forking off new processes, and if your program is doing it continuously, nicing them is not going to fix the problem. I suggest you fix the program so that it doesn't forkbomb. You can also rlimit it, and force the number of processes to a specific ceiling. This will result in crashing the program everytime you hit that limit, however. Try looking into djb's daemontools if you want to duct-tape it (ports/sysutils/daemontools) -- coleman On Sun, 27 Feb 2005 18:11:57 -0800, Ashwin Chandra wrote: > Hi all, > Ive been trying to counter the malicious effects of a forkbomb by setting the forkbomb parent and children to a PRI_MAX priority, although this is not having any effect on the system load. > > Basically in my code when I know which process is acting maliciously (forkbomb), I run the following simple code: > > FOREACH_KSEGRP_IN_PROC(p, kg) > { > printf("old prio:%d", kg->kg_user_pri); > kg->kg_user_pri = PRI_MAX; > printf(" new prio:%d", kg->kg_user_pri); > } > > When it prints out, the old prio was 180 and the new gets set to 255 although there is help to the system...the system is still under stress. Do you guys know any good ways of hacking the scheduler to make a process that is bad run MUCH MUCH less as to not overload the system? > > Ash > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 04:55:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B59F016A4CE for ; Mon, 28 Feb 2005 04:55:42 +0000 (GMT) Received: from smtp.ucla.edu (smtp.ucla.edu [169.232.46.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D0D043D46 for ; Mon, 28 Feb 2005 04:55:42 +0000 (GMT) (envelope-from ashcs@ucla.edu) Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.135]) by smtp.ucla.edu (8.13.2/8.13.2) with ESMTP id j1S4tgBb003467 for ; Sun, 27 Feb 2005 20:55:42 -0800 Received: from ash (s226-171.resnet.ucla.edu [164.67.226.171]) (authenticated bits=0) by mail.ucla.edu (8.13.3/8.13.3) with ESMTP id j1S4tfts017154 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 27 Feb 2005 20:55:41 -0800 Message-ID: <000c01c51d51$ce6243b0$abe243a4@ash> From: "Ashwin Chandra" To: Date: Sun, 27 Feb 2005 20:56:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Probable-Spam: no X-Spam-Hits: 0 X-Scanned-By: smtp.ucla.edu on 169.232.46.136 Subject: Fw: Priority Increasing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 04:55:42 -0000 The forkbomb program I wrote is just one parent that forks 750 or so children that each malloc around 40 MB's of memory and do a mem traversal through it. The children do not fork. I see the overhead of forking could be causing this, but shouldn't there be some difference in the load of the system when each forkbomb process is set to the lowest priority? To fork 750 processes would incur overhead until those processes are created (Which shouldnt take much of real time) and once they are running, if they other processes that have already been created are running "nicely", I don't see why there is so much overhead too. Do you recommend anotoher way to solve this forkbomb problem and keep the system DoS free for others? Ash > ----- Original Message ----- > From: "Coleman Kane" > To: "Ashwin Chandra" > Cc: > Sent: Sunday, February 27, 2005 7:28 PM > Subject: Re: Priority Increasing > > >> Well, since the program is running a forkbomb, it is gonna stress out >> the kernel. The kernel is constantly creating new process spaces, as >> well as filling in the queue. >> >> Are we talking a O(2^n) forkbomb here (where the forks also fork)? >> Remember, there is overhead associated with forking off new processes, >> and if your program is doing it continuously, nicing them is not going >> to fix the problem. I suggest you fix the program so that it doesn't >> forkbomb. >> >> You can also rlimit it, and force the number of processes to a >> specific ceiling. This will result in crashing the program everytime >> you hit that limit, however. Try looking into djb's daemontools if you >> want to duct-tape it (ports/sysutils/daemontools) >> >> -- >> coleman >> >> On Sun, 27 Feb 2005 18:11:57 -0800, Ashwin Chandra >> wrote: >>> Hi all, >>> Ive been trying to counter the malicious effects of a forkbomb by >>> setting the forkbomb parent and children to a PRI_MAX priority, although >>> this is not having any effect on the system load. >>> >>> Basically in my code when I know which process is acting maliciously >>> (forkbomb), I run the following simple code: >>> >>> FOREACH_KSEGRP_IN_PROC(p, kg) >>> { >>> printf("old prio:%d", kg->kg_user_pri); >>> kg->kg_user_pri = PRI_MAX; >>> printf(" new prio:%d", kg->kg_user_pri); >>> } >>> >>> When it prints out, the old prio was 180 and the new gets set to 255 >>> although there is help to the system...the system is still under stress. >>> Do you guys know any good ways of hacking the scheduler to make a >>> process that is bad run MUCH MUCH less as to not overload the system? >>> >>> Ash >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >>> > From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 07:29:11 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91E1816A4CE for ; Mon, 28 Feb 2005 07:29:11 +0000 (GMT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 232BC43D53 for ; Mon, 28 Feb 2005 07:29:11 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.103] (adsl-68-123-122-107.dsl.snfc21.pacbell.net [68.123.122.107])j1S7T8Hb197156; Mon, 28 Feb 2005 02:29:09 -0500 Message-ID: <4222C843.9040409@elischer.org> Date: Sun, 27 Feb 2005 23:29:07 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050214 X-Accept-Language: en, hu MIME-Version: 1.0 To: Aziz KEZZOU References: <37e1316605022711293bd1e8b5@mail.gmail.com> In-Reply-To: <37e1316605022711293bd1e8b5@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: intercepting RSVP packets with netgraph X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 07:29:11 -0000 Aziz KEZZOU wrote: > Hi all, > I've read every thing I could find about netgraph but I still can not > figure out how to intercept (divert) all IP packets of a certain type > (say RSVP) and call my own function to process them. > > Notice that the processing has to occur at the kernel level. > > Any help is appreciated. Thanks in advance. > > Aziz Kezzou > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" use the bpf node as a filter to separate them out.. OR use ipfw to separate them out and pass them somewhere (e.g. to netgraph) From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 08:16:19 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C3F916A4CE for ; Mon, 28 Feb 2005 08:16:19 +0000 (GMT) Received: from smtp.ucla.edu (smtp.ucla.edu [169.232.46.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2906B43D39 for ; Mon, 28 Feb 2005 08:16:19 +0000 (GMT) (envelope-from ashcs@ucla.edu) Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.135]) by smtp.ucla.edu (8.13.1/8.13.1) with ESMTP id j1S8GIW1015467 for ; Mon, 28 Feb 2005 00:16:18 -0800 Received: from ash (s226-171.resnet.ucla.edu [164.67.226.171]) (authenticated bits=0) by mail.ucla.edu (8.13.3/8.13.3) with ESMTP id j1S8GIDM016656 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 28 Feb 2005 00:16:18 -0800 Message-ID: <001a01c51d6d$d50ce500$abe243a4@ash> From: "Ashwin Chandra" To: Date: Mon, 28 Feb 2005 00:16:41 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Probable-Spam: no X-Spam-Hits: 0.528 X-Scanned-By: smtp.ucla.edu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 08:16:19 -0000 I wanted to get some clarification about the 4BSD scheduler. I am sort = of confused why there are two forms of scheduling, one done between = processes and another done between threads in a process. The priority = calculations seem to be done only with processes and I assume that the = global run queue holds processes, not threads. Also why is there only 1 = run queue for 1 CPU. What happens to blocked processes and ready to be = runned processes? Ash From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 08:26:17 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2E0D16A4CE for ; Mon, 28 Feb 2005 08:26:17 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EFDB43D5E for ; Mon, 28 Feb 2005 08:26:17 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.103] (adsl-68-123-122-107.dsl.snfc21.pacbell.net [68.123.122.107])j1S8QESJ173276; Mon, 28 Feb 2005 03:26:15 -0500 Message-ID: <4222D5A2.9010301@elischer.org> Date: Mon, 28 Feb 2005 00:26:10 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050214 X-Accept-Language: en, hu MIME-Version: 1.0 To: Ashwin Chandra References: <001a01c51d6d$d50ce500$abe243a4@ash> In-Reply-To: <001a01c51d6d$d50ce500$abe243a4@ash> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 08:26:18 -0000 Ashwin Chandra wrote: > I wanted to get some clarification about the 4BSD scheduler. I am sort of > confused why there are two forms of scheduling, one done between processes and > another done between threads in a process. The priority calculations seem to be > done only with processes and I assume that the global run queue holds processes, > not threads. Also why is there only 1 run queue for 1 CPU. What happens to > blocked processes and ready to be runned processes? Part of the challenge of adding threads to a system is to make it hard for a threaded process to "flood" the system run queues so that other processes get no cpu time. The scheme in the current freeBSD schedulers is a "crude" method, by which only a limitted number of threads per process are allowed to be added to the system run queue. RUnnable hreads fo r aprocess are kept on a run queue for the process and only the highest N prioriy hreads are actually put on the system run queue. This is by no means the best way, but rather the easiest way. I am hoping that some PhD candidate somewhere will decide that thread scheduling is his topic and will figure out a better way of doing this. both run queues hold threads. This is still a place wjere a lot of work can be done. :-) > > Ash > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 09:30:08 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A69716A4CE for ; Mon, 28 Feb 2005 09:30:08 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 9005D43D31 for ; Mon, 28 Feb 2005 09:30:07 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 29967 invoked from network); 28 Feb 2005 09:30:06 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 28 Feb 2005 09:30:06 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 28 Feb 2005 03:30:01 -0600 (CST) From: Mike Silbersack To: Ashwin Chandra In-Reply-To: <000801c51d3a$e1ac47c0$abe243a4@ash> Message-ID: <20050228032537.H11576@odysseus.silby.com> References: <000801c51d3a$e1ac47c0$abe243a4@ash> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: Priority Increasing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 09:30:08 -0000 On Sun, 27 Feb 2005, Ashwin Chandra wrote: > Hi all, Ive been trying to counter the malicious effects of a forkbomb > by setting the forkbomb parent and children to a PRI_MAX priority, > although this is not having any effect on the system load. > > Basically in my code when I know which process is acting maliciously > (forkbomb), I run the following simple code: If you're sure that the program is a forkbomb, why not modify the forkbomb protection that is already present in kern_fork.c: tsleep(&forksleep, PUSER, "fork", hz / 2); What it does at present is whenever you try to fork and you've hit your process limit (see limits(1)), it puts your process to sleep for .5 seconds. If you have a better way to tell if something is a forkbomb, why not just do the same thing, perhaps with a shorter sleep. Don't try too hard to defeat forkbombs, though. Whenever it's been discussed, someone has invariably pointed out that you could just fork 750 processes, and then have those 750 do something else which is kernel intensive, like reading/writing 1 byte at a time. In other words, limiting the maximum number of processes a user can have must be part of the equation - and we probably set that limit too high by default. :) Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 00:33:43 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0D8916A4CE; Mon, 28 Feb 2005 00:33:43 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1EB843D31; Mon, 28 Feb 2005 00:33:41 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id 9055A3700F; Sun, 27 Feb 2005 19:33:26 -0500 (EST) To: Maxim Sobolev In-reply-to: Your message of "Mon, 28 Feb 2005 02:15:15 +0200." <42226293.7040603@FreeBSD.org> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Sun, 27 Feb 2005 19:33:26 -0500 From: Roland Dowdeswell Message-Id: <20050228003326.9055A3700F@arioch.imrryr.org> X-Mailman-Approved-At: Mon, 28 Feb 2005 12:59:18 +0000 cc: freebsd-hackers@FreeBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 00:33:44 -0000 On 1109549715 seconds since the Beginning of the UNIX epoch Maxim Sobolev wrote: > >Well, I think that this is quite minor item, since GBDE doesn't govern >transformation of the passphrase into the actual key, so that another >scheme more bullet-prof against dictionary attacks (PKCS#5 or any other) >can be developed in virtually no time at all and will require making >only minor changes to the userland utility which gets password from the >keyboard or command line, hashes it and feeds to the kernel. These changes have not been made. Until they are, the security of the entire system depends on choosing very strong passphrases which most users do not do. So, one should not inform users either explicitly or implicitly that their data is safe [at least not without the proviso that the passphrase is actually easier to attack in practise than an entry in /etc/master.passwd and hence much more care should be taken in choosing them.] >Well, it's hard to comment on this, since the only paper that I have >found on CGD is http://www.imrryr.org/~elric/cgd/cgd.pdf, which >unfortunately doesn't provide any details on how CGD encrypts data and >lays it out on disk. Actually, it does. But, I can reiterate here. CGD does not move the blocks on the disk around at all. It doesn't make much sense to do that. Each block is encrypted separately using the chosen algorithm with your key. An IV is chosen using a configurable mechanism, although I have yet only implemented one which is the encrypted block number. >So what? If the write fails in the middle, reading sector will just >produce garbage. I don't think that it's different from plain old HDD >which has been powered down in the middle of doing disk write. Disk >encryption layer is definitely not the level at which journaling should >be implemented. It's task of file system to do this. The task of >encryption layer is merely to inform the file system when transaction >(i.e. both of those two writes in this case) have been completed >successfully, so that FS can adjust its journal accordingly. That is actually quite different that what normally happens. Basically what this means is that if your OS crashes or you suffer a power out then you have a reasonable chance that you've lost blocks on the disk. This will lead to a situation where fsck may not be able to recover your file system. A file system depends on certain assumptions about the underlying disk device, namely that a single sector write is an atomic operation in order to accomplish its task. It looks to me from the paper and the code that GBDE breaks this fundamental assumption. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 08:54:04 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC6AA16A4CE for ; Mon, 28 Feb 2005 08:54:04 +0000 (GMT) Received: from hotmail.com (bay15-f9.bay15.hotmail.com [65.54.185.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0C6B43D39 for ; Mon, 28 Feb 2005 08:54:04 +0000 (GMT) (envelope-from ppmmssgg@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 28 Feb 2005 00:54:03 -0800 Message-ID: Received: from 220.194.103.228 by by15fd.bay15.hotmail.msn.com with HTTP; Mon, 28 Feb 2005 08:53:38 GMT X-Originating-IP: [220.194.103.228] X-Originating-Email: [ppmmssgg@hotmail.com] X-Sender: ppmmssgg@hotmail.com From: =?gb2312?B?wfUg0e8=?= To: freebsd-hackers@freebsd.org Date: Mon, 28 Feb 2005 08:53:38 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed X-OriginalArrivalTime: 28 Feb 2005 08:54:03.0830 (UTC) FILETIME=[0DB46D60:01C51D73] X-Mailman-Approved-At: Mon, 28 Feb 2005 12:59:18 +0000 Subject: about the source of loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 08:54:04 -0000 Dear All: I have some questions of source of loader 1.Where is the source of the "ls" command? 2.How it mount the ufs boot partition as "/" when it start,Is it a function or something else?. Any answers are appreciated:) _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 13:13:50 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09A3816A4CE for ; Mon, 28 Feb 2005 13:13:50 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9871943D55 for ; Mon, 28 Feb 2005 13:13:49 +0000 (GMT) (envelope-from zombyfork@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so860240rng for ; Mon, 28 Feb 2005 05:13:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Zsl3qQJydt52BYAi9GBX7YWTafpLIFELalrvb5J7t/34wPYRdzwQSQ9aMNHJMCTW3XhEpzGZn3FUKilJ3Qck6Qbgb9UvjbfSKbpioFKAbNJYTpbryTQaXe+YmRoGNgdmds2ai9GDMFq19ZlEffQ0RVTqsekUhd4oYNHfxb1ZJ8s= Received: by 10.38.162.1 with SMTP id k1mr57718rne; Mon, 28 Feb 2005 05:13:48 -0800 (PST) Received: by 10.38.22.22 with HTTP; Mon, 28 Feb 2005 05:13:48 -0800 (PST) Message-ID: <346a802205022805137ef19b48@mail.gmail.com> Date: Mon, 28 Feb 2005 08:13:48 -0500 From: Coleman Kane To: Ashwin Chandra In-Reply-To: <000c01c51d51$ce6243b0$abe243a4@ash> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <000c01c51d51$ce6243b0$abe243a4@ash> cc: freebsd-hackers@freebsd.org Subject: Re: Fw: Priority Increasing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cokane@cokane.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 13:13:50 -0000 On Sun, 27 Feb 2005 20:56:03 -0800, Ashwin Chandra wrote: > The forkbomb program I wrote is just one parent that forks 750 or so > children that each malloc around 40 MB's of memory and do a mem traversal > through it. The children do not fork. I see the overhead of forking could > be > causing this, but shouldn't there be some difference in the load of the > system when each forkbomb process is set to the lowest priority? To fork > 750 > processes would incur overhead until those processes are created (Which > shouldnt take much of real time) and once they are running, if they other > processes that have already been created are running "nicely", I don't see > why there is so much overhead too. > You are talking about malloc'ing almost 30GB of memory and having 750 readers paw through it to search for something. That is a lot of swap-backed memory. You are probably experiencing swap thrashing from all of this memory access/usage. Might I ask why this needs to be done 750 times in parallel? If you are trying to be efficient, try only forking off readers for each CPU, and waiting until they finish before you start anew. You also won't be swapping so much information to disk, which will make your program run alot faster than the method you are using. That is, of course, unless you actually do have > 30GB RAM. In that case, I am way off, but you may want to reduce the number of procs anyhow. > Do you recommend anotoher way to solve this forkbomb problem and keep the > system DoS free for others? > Ash > Also, this isn't really a forkbomb, as you seem to have a limit instituted on the number of forks. In a traditional fork-bomb, the forkers fork themselves, and so on, and so on, .... -- coleman kane From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 13:39:28 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEA2916A4CE for ; Mon, 28 Feb 2005 13:39:28 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B64043D1D for ; Mon, 28 Feb 2005 13:39:28 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j1SDd1Z6090227; Mon, 28 Feb 2005 08:39:01 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j1SDd0ti090226; Mon, 28 Feb 2005 08:39:00 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 28 Feb 2005 08:39:00 -0500 From: David Schultz To: Yan Yu Message-ID: <20050228133900.GA90034@VARK.MIT.EDU> Mail-Followup-To: Yan Yu , freebsd-hackers@FreeBSD.ORG References: <20050226072645.76950.qmail@web26802.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-hackers@FreeBSD.ORG Subject: Re: function prototype of fdrop() and fdrop_locked() in kern_descrip.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 13:39:29 -0000 On Sat, Feb 26, 2005, Yan Yu wrote: > HI, all, > I have a Q on the input parameter of fdrop() and fdrop_locked() in > kern/kern_descrip.c. > > i am curious about the design choice of their input parameter. > currently, it is defined as > ---------------------------------------- > A) fdrop( struct file *, struct thread *) > ---------------------------------------- > I added some field in the file descriptor table, and need to do some > bookkeeping whenever a file descriptor is freed. It would be much easier > for me if fdrop() is defined as > --------------------------------- > B) fdrop( int fd, struct thread *) > --------------------------------- > then i could just instrument the fdrop function as opposed to change every > place that calls the fdrop() function. btw, there are more than 100 places > that calls fdrop():( There isn't a one-to-one mapping between file structures and userland file descriptors. After dup(2) is called, for instance, there are two numbers that both map to the same struct file. David Malone gave some other good examples. You will probably want to rethink your design to take this into account. Note that you could instrument the places where syscalls look up userland file descriptors in the fd table if you need to refer to the descriptor number. Just be aware that the number you get won't necessarily correspond to a unique struct file. There are at least two places where this mapping is done: fget_locked() and getvnode(). I think patches to combine them would be gladly accepted. ;-) From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 14:14:52 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9145716A4CE for ; Mon, 28 Feb 2005 14:14:52 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D5CE43D5A for ; Mon, 28 Feb 2005 14:14:48 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id 978683700F; Mon, 28 Feb 2005 09:14:30 -0500 (EST) To: Mike Silbersack In-reply-to: Your message of "Mon, 28 Feb 2005 03:30:01 CST." <20050228032537.H11576@odysseus.silby.com> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Mon, 28 Feb 2005 09:14:30 -0500 From: Roland Dowdeswell Message-Id: <20050228141430.978683700F@arioch.imrryr.org> cc: freebsd-hackers@freebsd.org cc: Ashwin Chandra Subject: Re: Priority Increasing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 14:14:52 -0000 On 1109583001 seconds since the Beginning of the UNIX epoch Mike Silbersack wrote: > >If you're sure that the program is a forkbomb, why not modify the forkbomb >protection that is already present in kern_fork.c: > >tsleep(&forksleep, PUSER, "fork", hz / 2); > >What it does at present is whenever you try to fork and you've hit your >process limit (see limits(1)), it puts your process to sleep for .5 >seconds. If you have a better way to tell if something is a forkbomb, why >not just do the same thing, perhaps with a shorter sleep. > >Don't try too hard to defeat forkbombs, though. Whenever it's been >discussed, someone has invariably pointed out that you could just fork 750 >processes, and then have those 750 do something else which is kernel >intensive, like reading/writing 1 byte at a time. Also be careful of unintended consequences. When it was suggested that we import this tsleep fork-bomb protection into NetBSD, I mentioned that it would cause pathological behaviour in certain well behaved applications. E.g. thttpd. Thttpd is an event driven web server which performs quite well. It does need to fork to process CGI scripts, though. If it hits the process limit and is put to sleep then it will stop serving static web pages---certainly not the desired behaviour. I.e. a perfectly reasonably running web server will quickly fall to its knees if a few too many CGIs were requested. There is no way to solve the problem, too, because thttpd cannot know reliably whether it can fork before it tries to. I think that we ended up putting in this ``fork-bomb protection'' conditionally with the default of off. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 15:39:59 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48AF216A4CE for ; Mon, 28 Feb 2005 15:39:59 +0000 (GMT) Received: from house.arach.net.au (house2.arach.net.au [203.30.44.85]) by mx1.FreeBSD.org (Postfix) with SMTP id A4D2543D39 for ; Mon, 28 Feb 2005 15:39:55 +0000 (GMT) (envelope-from kat-free@kaqelectronics.dyndns.org) Received: (qmail 19577 invoked from network); 28 Feb 2005 15:39:53 -0000 Received: from unknown (HELO pythagorus.kaqelectronics.dyndns.org) (202.89.183.21) by house2.arach.net.au with SMTP for ; 28 Feb 2005 15:39:53 -0000 Received: from [192.168.0.2] (kathy.kaqelectronics.dyndns.org. [192.168.0.2]) id j1SFfxrd083089 for ; Mon, 28 Feb 2005 23:42:00 +0800 (WST) (envelope-from kat-free@kaqelectronics.dyndns.org) Received: from 127.0.0.1 (AVG SMTP 7.0.300 [266.5.1]); Mon, 28 Feb 2005 23:39:52 +0800 Message-ID: <42233B48.4010108@kaqelectronics.dyndns.org> Date: Mon, 28 Feb 2005 23:39:52 +0800 From: Kathy Quinlan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-au, en, en-us To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Subject: clock.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 15:39:59 -0000 I have this: #include In program I use this: DELAY(1000); I get this: undefined referance to 'DELAY' when I compile the program with GCC with flags -Wall -g -o com main.c ANY ideas ?? I have looked in the relevent header and it seems to be there Regards, Kat. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.5.1 - Release Date: 27/02/2005 From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 15:57:37 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 115B616A4CE for ; Mon, 28 Feb 2005 15:57:37 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98BF743D39 for ; Mon, 28 Feb 2005 15:57:36 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.1) id j1SFvYpF035766; Mon, 28 Feb 2005 09:57:34 -0600 (CST) (envelope-from dan) Date: Mon, 28 Feb 2005 09:57:34 -0600 From: Dan Nelson To: ?? ?? Message-ID: <20050228155734.GF8778@dan.emsphone.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.3-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: freebsd-hackers@freebsd.org Subject: Re: about the source of loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 15:57:37 -0000 In the last episode (Feb 28), ?? ?? said: > I have some questions of source of loader > > 1. Where is the source of the "ls" command? /sys/boot/common/ls.c > 2. How it mount the ufs boot partition as "/" when it start,Is it a > function or something else?. The loader can't mount anything, since it isn't the kernel. Since it can read UFS filesystems, though, if it can find an /etc/fstab, it will try and pass the path to the root volume to the kernel in the tunable "vfs.root.mountfrom". See /sys/boot/common/boot.c:getrootmount() and /sys/kern/vfs_mount.c:vfs_mountroot() . -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 16:06:53 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86BCF16A4CE for ; Mon, 28 Feb 2005 16:06:53 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id DF60D43D46 for ; Mon, 28 Feb 2005 16:06:51 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 31467 invoked from network); 28 Feb 2005 16:06:46 -0000 Received: from unknown (HELO straylight.ringlet.net) (213.16.36.92) by gandalf.online.bg with SMTP; 28 Feb 2005 16:06:46 -0000 Received: (qmail 35304 invoked by uid 1000); 28 Feb 2005 16:06:49 -0000 Date: Mon, 28 Feb 2005 18:06:49 +0200 From: Peter Pentchev To: Kathy Quinlan Message-ID: <20050228160649.GC34617@straylight.m.ringlet.net> Mail-Followup-To: Kathy Quinlan , freebsd-hackers@freebsd.org References: <42233B48.4010108@kaqelectronics.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H8ygTp4AXg6deix2" Content-Disposition: inline In-Reply-To: <42233B48.4010108@kaqelectronics.dyndns.org> User-Agent: Mutt/1.5.8i cc: freebsd-hackers@freebsd.org Subject: Re: clock.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 16:06:53 -0000 --H8ygTp4AXg6deix2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 28, 2005 at 11:39:52PM +0800, Kathy Quinlan wrote: > I have this: >=20 > #include >=20 > In program I use this: >=20 > DELAY(1000); >=20 > I get this: >=20 > undefined referance to 'DELAY' >=20 > when I compile the program with GCC with flags -Wall -g -o com main.c >=20 > ANY ideas ?? >=20 > I have looked in the relevent header and it seems to be there Yes, it is in clock.h, but... /*- * Kernel interface to machine-dependent clock driver. That's the way that clock.h starts. The 'kernel interface' part means that this is a header file that declares functions that are used *only* within the FreeBSD kernel - since they are only implemented in another part of the kernel code. You cannot use these definitions and functions =66rom a userland program, as you are trying to do. The reason that the DELAY() declaration seems to be in the header file, yet the compiler does not see it, is the #ifdef _KERNEL at the top of clock.h :) This is just a level of protection that accomplishes exactly that - no userland program should *ever* define the _KERNEL symbol, so no userland program will be fooled into believing that there is a DELAY() function that it could possibly use. It simply cannot, since the DELAY() function is declared within kernel code for use by the kernel only. If you want a high-precision delay/sleep interface in a userland program, take a look at the usleep(2) and nanosleep(2) syscalls. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the meaning of this sentence. --H8ygTp4AXg6deix2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCI0GZ7Ri2jRYZRVMRAoktAJ9K/UpRs6avaaoTxWkTF9+AA8XUeACeOHRW FNHGOEWopXiAhVRfgQZD0wo= =JWPU -----END PGP SIGNATURE----- --H8ygTp4AXg6deix2-- From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 16:08:04 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4435E16A50B for ; Mon, 28 Feb 2005 16:08:04 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id C39A143D39 for ; Mon, 28 Feb 2005 16:08:03 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.1) id j1SG834A054436; Mon, 28 Feb 2005 10:08:03 -0600 (CST) (envelope-from dan) Date: Mon, 28 Feb 2005 10:08:03 -0600 From: Dan Nelson To: Kathy Quinlan Message-ID: <20050228160802.GG8778@dan.emsphone.com> References: <42233B48.4010108@kaqelectronics.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42233B48.4010108@kaqelectronics.dyndns.org> X-OS: FreeBSD 5.3-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: freebsd-hackers@freebsd.org Subject: Re: clock.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 16:08:04 -0000 In the last episode (Feb 28), Kathy Quinlan said: > I have this: > > #include > > In program I use this: > > DELAY(1000); > > I get this: > > undefined referance to 'DELAY' > > when I compile the program with GCC with flags -Wall -g -o com main.c DELAY is a kernel function. In user processes, just use sleep() or nanosleep(). When you directly #include headers from userland, the only useable things are structure definitions and macro constants (and even then it's recommended that you use a userland interface instead). You can't call any of the functions. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 16:11:30 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3654716A4CE for ; Mon, 28 Feb 2005 16:11:30 +0000 (GMT) Received: from house.arach.net.au (house2.arach.net.au [203.30.44.85]) by mx1.FreeBSD.org (Postfix) with SMTP id D073743D58 for ; Mon, 28 Feb 2005 16:11:28 +0000 (GMT) (envelope-from kat-free@kaqelectronics.dyndns.org) Received: (qmail 14102 invoked from network); 28 Feb 2005 16:11:27 -0000 Received: from unknown (HELO pythagorus.kaqelectronics.dyndns.org) (202.89.183.21) by house2.arach.net.au with SMTP for ; 28 Feb 2005 16:11:27 -0000 Received: from [192.168.0.2] (kathy.kaqelectronics.dyndns.org. [192.168.0.2]) id j1SGDXIa084384; Tue, 1 Mar 2005 00:13:33 +0800 (WST) (envelope-from kat-free@kaqelectronics.dyndns.org) Received: from 127.0.0.1 (AVG SMTP 7.0.300 [266.5.1]); Tue, 01 Mar 2005 00:11:26 +0800 Message-ID: <422342AE.9040207@kaqelectronics.dyndns.org> Date: Tue, 01 Mar 2005 00:11:26 +0800 From: Kathy Quinlan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-au, en, en-us To: Dan Nelson References: <42233B48.4010108@kaqelectronics.dyndns.org> <20050228160802.GG8778@dan.emsphone.com> In-Reply-To: <20050228160802.GG8778@dan.emsphone.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: clock.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 16:11:30 -0000 Dan Nelson wrote: > In the last episode (Feb 28), Kathy Quinlan said: > >>I have this: >> >>#include >> >>In program I use this: >> >>DELAY(1000); >> >>I get this: >> >>undefined referance to 'DELAY' >> >>when I compile the program with GCC with flags -Wall -g -o com main.c > > > DELAY is a kernel function. In user processes, just use sleep() or > nanosleep(). When you directly #include headers from > userland, the only useable things are structure definitions and macro > constants (and even then it's recommended that you use a userland > interface instead). You can't call any of the functions. > Thanks, using sleep now, only need a second :) Slowly learning programming in a real enviroment whene we do not have microsloth program to hold our hands (never had a VC++ ap able to do anything to a system, this program has already core dumped a few times) Regards, Kat. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 266.5.1 - Release Date: 27/02/2005 From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 17:10:52 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5906A16A4CE for ; Mon, 28 Feb 2005 17:10:52 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68C5D43D58 for ; Mon, 28 Feb 2005 17:10:51 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j1SH9oLI038803; Mon, 28 Feb 2005 10:09:50 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 28 Feb 2005 10:10:03 -0700 (MST) Message-Id: <20050228.101003.59082645.imp@bsdimp.com> To: kat-free@kaqelectronics.dyndns.org From: "M. Warner Losh" In-Reply-To: <42233B48.4010108@kaqelectronics.dyndns.org> References: <42233B48.4010108@kaqelectronics.dyndns.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: clock.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 17:10:52 -0000 In message: <42233B48.4010108@kaqelectronics.dyndns.org> Kathy Quinlan writes: : I have this: : : #include : : In program I use this: : : DELAY(1000); : : I get this: : : undefined referance to 'DELAY' : : when I compile the program with GCC with flags -Wall -g -o com main.c : : ANY ideas ?? : : I have looked in the relevent header and it seems to be there don't use DELAY in userland code. Use sleep, usleep or nanosleep. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 21:44:05 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3005D16A4CE; Mon, 28 Feb 2005 21:44:05 +0000 (GMT) Received: from kalypso.opteqint.net (kalypso.opteqint.net [160.124.112.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DBC843D49; Mon, 28 Feb 2005 21:44:02 +0000 (GMT) (envelope-from cole@opteqint.net) Received: from c1-5-rrba.isadsl.co.za ([196.34.192.5] helo=deadmind) by kalypso.opteqint.net with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43 (FreeBSD)) id 1D5sgG-000OkO-40; Mon, 28 Feb 2005 23:44:00 +0200 Message-ID: <003101c51ddf$347fa420$4206000a@deadmind> From: "Cole" To: Date: Mon, 28 Feb 2005 23:48:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: -97.5 (---------------------------------------------------) X-Spam-Report: Spam detection software, running on the system "kalypso.opteqint.net", hasmessagelabel similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hey. I have a Freebsd server runningthen had no problems what so ever building ntop, except for the xml plugin though I have libxml installed, and specified the right paths to the .h. But that is not the problem. Ntop runs and works fine on this box, not a single problem that I can see. [...] Content analysis details: (-97.5 points, 4.3 required) pts rule name description -------------------------------------------------- -100 USER_IN_WHITELIST From: address is in the user's white-list 2.5 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL [196.34.192.5 listed in sbl-xbl.spamhaus.org] cc: freebsd-net@freebsd.org Subject: Dynamically Linked Library Problem (maybe) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Cole List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 21:44:05 -0000 Hey. I have a Freebsd server running freebsd-4.9-stable. I cvsupped the ntop src last week for 3.1.1. I then had no problems what so ever building ntop, except for the xml plugin saying it was not built, cause it cannot find xmlversion.h, even though I have libxml installed, and specified the right paths to the .h. But that is not the problem. Ntop runs and works fine on this box, not a single problem that I can see. The problem is that, I have a few other servers, that I want to copy ntop too, but dont want to build it on all those boxes. I created a tar with all the ntop binaries, as well as all the libraries that its linked too, as well as all the plugins that ntop uses from both the /usr/local/lib directory as well as the plugins from the /usr/local/lib/ntop/plugins directory. I rebuilt all the symbolic links for all the libraries and plugins and all the files that ntop was linked too. I have also checked all the permissions on all the files and they are all the same. One other thing, the boxes that I am copying ntop to, are almost exact duplicates of the first box that I built ntop on, and where it works fine. The problem is, when running ntop on the boxes that I copied it to, after checking all the permissions and links and everything, I get these errors with regards to the plugins. Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/icmpPlugin.so' entry function [Invalid shared object handle 0x29a14000] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/snmpPlugin.so' entry function [Invalid shared object handle 0x29a16400] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/sflowPlugin.so' entry function [Invalid shared object handle 0x29a19800] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/rrdPlugin.so' entry function [Invalid shared object handle 0x29a1bc00] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/pdaPlugin.so' entry function [Invalid shared object handle 0x2bcae400] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/netflowPlugin.so' entry function [Invalid shared object handle 0x2d862800] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/lastSeenPlugin.so' entry function [Invalid shared object handle 0x2d866c00] Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/xmldumpPlugin.so' entry function [Invalid shared object handle 0x2f697000] I have absolutely no idea how this has happened, and I have had this problem before, and not a single other person was able to help me in any regards what so ever. I was hoping maybe someone would at least know what this error even means, so that I have some idea of what I am meant to be doing to fix this. If anyone has any idea, I would gladly apprecaite any suggestions. Thanks /Cole From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 22:55:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA65D16A4CE for ; Mon, 28 Feb 2005 22:55:36 +0000 (GMT) Received: from intranet.ru (intranet.ru [212.164.71.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id D572143D66 for ; Mon, 28 Feb 2005 22:55:34 +0000 (GMT) (envelope-from denus@ngs.ru) Received: from [172.16.0.10] (HELO smtp.ngs.ru) by intranet.ru (CommuniGate Pro SMTP 4.2.4) with ESMTP id 204396586 for freebsd-hackers@freebsd.org; Tue, 01 Mar 2005 04:56:56 +0600 Received: from ngs.ru (unknown [83.237.133.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ngs.ru (Postfix) with ESMTP id 1E07D774C0C for ; Tue, 1 Mar 2005 04:55:30 +0600 (NOVT) Message-ID: <4223A1D1.6000104@ngs.ru> Date: Tue, 01 Mar 2005 01:57:21 +0300 From: Denis Ustimenko User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20041215 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: TDF_NEEDRESCHED when extending pcb on x86 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 22:55:37 -0000 Hi, there! I've tried s3switch utility from ports on 5.2.1 and found that i386_set_ioperm syscall doesn't work properly. The next code illustrates the problem. It will get SIGBUS with very high probability. #include #include #include int main() { if ( i386_set_ioperm( 0x80, 1, 1)) { perror("XXX"); return 1; } inb( 0x80); return 0; } Now I have no 5.3 or CURRENT system but brief looking on code shows that it should give the same result on them. The problem occurs when we extend pcb and set TDF_NEEDRESCHED bit hoping that thread will be rescheduled and new TSS will be loaded. But sched_switch function skips cpu_switch when thread was not changed and ltr is not executed. So I've patched sys_machdep.c the patch is below. But two thoughts in this situation are not clear to me: 1. May be patching of scheduler code to call cpu_switch in case of TDF_NEEDRESCHED is more appropriate decision 2. Is it necessary to protect all new lines of i386_extend_pcb function by sched_lock? It looks like we could move at least ltr out of syncronized code. *** /usr/src/sys/i386/include/segments.h.orig Mon Feb 28 23:34:30 2005 --- /usr/src/sys/i386/include/segments.h Mon Feb 28 23:34:53 2005 *************** *** 243,248 **** --- 243,249 ---- extern struct gate_descriptor *idt; extern union descriptor ldt[NLDT]; extern struct region_descriptor r_gdt, r_idt; + extern int private_tss; void lgdt(struct region_descriptor *rdp); void sdtossd(struct segment_descriptor *sdp, *** /usr/src/sys/i386/i386/sys_machdep.c.orig Mon Feb 28 23:29:31 2005 --- /usr/src/sys/i386/i386/sys_machdep.c Mon Feb 28 23:33:31 2005 *************** *** 172,179 **** mtx_lock_spin(&sched_lock); td->td_pcb->pcb_ext = ext; ! /* switch to the new TSS after syscall completes */ ! td->td_flags |= TDF_NEEDRESCHED; mtx_unlock_spin(&sched_lock); return 0; --- 172,180 ---- mtx_lock_spin(&sched_lock); td->td_pcb->pcb_ext = ext; ! private_tss |= 1 << PCPU_GET(cpuid); ! *PCPU_GET(tss_gdt) = td->td_pcb->pcb_ext->ext_tssd; ! ltr(GSEL(GPROC0_SEL, SEL_KPL)); mtx_unlock_spin(&sched_lock); return 0; -- Best regards Denis From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 23:08:15 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07B5F16A4DA for ; Mon, 28 Feb 2005 23:08:15 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D80843D3F for ; Mon, 28 Feb 2005 23:08:14 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 7957 invoked from network); 28 Feb 2005 23:08:14 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 28 Feb 2005 23:08:14 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j1SN84OC066576; Mon, 28 Feb 2005 18:08:08 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Mon, 28 Feb 2005 17:23:33 -0500 User-Agent: KMail/1.6.2 References: <421E7867.9060101@samsco.org> <20050225093917.GA90508@cirb503493.alcatel.com.au> In-Reply-To: <20050225093917.GA90508@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502281723.33667.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Peter Jeremy cc: Scott Long cc: hackers@FreeBSD.org Subject: Re: Driver Update Disk discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 23:08:15 -0000 On Friday 25 February 2005 04:39 am, Peter Jeremy wrote: > On Thu, 2005-Feb-24 17:59:19 -0700, Scott Long wrote: > >- kernel option support. How do we support vendor modules in a kernel > >that might be compiled with PAE (rather common these days), SMP, MAC, > >etc. The loader and /boot infrastructure has no concept of this. It's > >highly important, though. > > AFAIK, PAE is only relevant on iA32. I second the suggestion that PAE > be treated as a distinct architecture for these purposes. > > INVARIANTS and WITNESS are the other options that impact ABI. These > are probably unnecessary on -RELEASE but it would be nice if people > could build a kernel with WITNESS and not have it panic if they loaded > a module that wasn't compiled with WITNESS (which I think it the > current behaviour). No, WITNESS is completely opaque to modules. If a module uses a spin lock, there is extra trickiness involved, but that should really be a rare case. INVARIANTS modules work fine if INVARIANT_SUPPORT is in the kernel. INVARIANT_SUPPORT usually means that functions like _mtx_assert() are present in the kernel. Perhaps INVARIANT_SUPPORT should simply be on by default. MUTEX_PROFILING is one option that changes the ABI, but that is purposeful as that's really a development tool. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 28 23:08:15 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CDFF16A4DD for ; Mon, 28 Feb 2005 23:08:15 +0000 (GMT) Received: from mail22.sea5.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D97843D4C for ; Mon, 28 Feb 2005 23:08:14 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 7957 invoked from network); 28 Feb 2005 23:08:14 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 28 Feb 2005 23:08:14 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j1SN84OC066576; Mon, 28 Feb 2005 18:08:08 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Mon, 28 Feb 2005 17:23:33 -0500 User-Agent: KMail/1.6.2 References: <421E7867.9060101@samsco.org> <20050225093917.GA90508@cirb503493.alcatel.com.au> In-Reply-To: <20050225093917.GA90508@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502281723.33667.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Peter Jeremy cc: Scott Long cc: hackers@FreeBSD.org Subject: Re: Driver Update Disk discussion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 23:08:15 -0000 On Friday 25 February 2005 04:39 am, Peter Jeremy wrote: > On Thu, 2005-Feb-24 17:59:19 -0700, Scott Long wrote: > >- kernel option support. How do we support vendor modules in a kernel > >that might be compiled with PAE (rather common these days), SMP, MAC, > >etc. The loader and /boot infrastructure has no concept of this. It's > >highly important, though. > > AFAIK, PAE is only relevant on iA32. I second the suggestion that PAE > be treated as a distinct architecture for these purposes. > > INVARIANTS and WITNESS are the other options that impact ABI. These > are probably unnecessary on -RELEASE but it would be nice if people > could build a kernel with WITNESS and not have it panic if they loaded > a module that wasn't compiled with WITNESS (which I think it the > current behaviour). No, WITNESS is completely opaque to modules. If a module uses a spin lock, there is extra trickiness involved, but that should really be a rare case. INVARIANTS modules work fine if INVARIANT_SUPPORT is in the kernel. INVARIANT_SUPPORT usually means that functions like _mtx_assert() are present in the kernel. Perhaps INVARIANT_SUPPORT should simply be on by default. MUTEX_PROFILING is one option that changes the ABI, but that is purposeful as that's really a development tool. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 00:07:15 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2DCE16A4CE for ; Tue, 1 Mar 2005 00:07:14 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8C5843D46 for ; Tue, 1 Mar 2005 00:07:14 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 8A9602A8DD for ; Mon, 28 Feb 2005 16:07:14 -0800 (PST) (envelope-from peter@wemm.org) Received: from peter-laptop.wemm.org (dhcp51.wemm.org [10.0.0.51]) by fw.wemm.org (Postfix) with ESMTP id 2CA3DE2B3 for ; Mon, 28 Feb 2005 16:07:14 -0800 (PST) (envelope-from peter@wemm.org) Received: from peter-laptop.wemm.org (localhost [127.0.0.1]) by peter-laptop.wemm.org (8.13.3/8.13.3) with ESMTP id j2106pxM001604; Mon, 28 Feb 2005 16:06:51 -0800 (PST) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by peter-laptop.wemm.org (8.13.3/8.13.3/Submit) id j2106oNT001603; Mon, 28 Feb 2005 16:06:50 -0800 (PST) (envelope-from peter@wemm.org) X-Authentication-Warning: peter-laptop.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-hackers@freebsd.org Date: Mon, 28 Feb 2005 16:06:49 -0800 User-Agent: KMail/1.7.2 References: <4223A1D1.6000104@ngs.ru> In-Reply-To: <4223A1D1.6000104@ngs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502281606.50074.peter@wemm.org> cc: Denis Ustimenko Subject: Re: TDF_NEEDRESCHED when extending pcb on x86 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 00:07:15 -0000 On Monday 28 February 2005 02:57 pm, Denis Ustimenko wrote: > Hi, there! > > I've tried s3switch utility from ports on 5.2.1 and found that > i386_set_ioperm syscall doesn't work properly. The next code illustrates > the problem. It will get SIGBUS with very high probability. > > #include > #include > #include > > int main() > { > if ( i386_set_ioperm( 0x80, 1, 1)) { > perror("XXX"); > return 1; > } > inb( 0x80); > return 0; > } > > Now I have no 5.3 or CURRENT system but brief looking on code shows that > it should give the same result on them. > The problem occurs when we extend pcb and set TDF_NEEDRESCHED bit hoping > that thread will be rescheduled and new TSS will be loaded. But > sched_switch function skips cpu_switch when thread was not changed and > ltr is not executed. I think it would be better to fix the semantics of TDF_NEEDRESCHED. I was thinking that mi_switch could negate the cpu_switch optimization if TDF_NEEDRESCHED was set. That would avoid duplicating the internal knowledge of the pcb/tss/etc handling in this code. -Peter From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 00:08:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D49716A4CE for ; Tue, 1 Mar 2005 00:08:33 +0000 (GMT) Received: from smtp809.mail.ukl.yahoo.com (smtp809.mail.ukl.yahoo.com [217.12.12.199]) by mx1.FreeBSD.org (Postfix) with SMTP id 6AB7443D64 for ; Tue, 1 Mar 2005 00:08:32 +0000 (GMT) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from unknown (HELO w2fzz0vc01.aah-go-on.com) (thomas.sparrevohn@hg1.btinternet.com@81.157.127.252 with plain) by smtp809.mail.ukl.yahoo.com with SMTP; 1 Mar 2005 00:08:31 -0000 From: Thomas Sparrevohn To: freebsd-hackers@freebsd.org Date: Tue, 1 Mar 2005 00:08:20 +0000 User-Agent: KMail/1.7.2 References: <20050227213032.CCB973700F@arioch.imrryr.org> <42226293.7040603@FreeBSD.org> In-Reply-To: <42226293.7040603@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503010008.20675.Thomas.Sparrevohn@btinternet.com> Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Thomas.Sparrevohn@btinternet.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 00:08:33 -0000 On Monday 28 February 2005 00:15, Maxim Sobolev wrote: > Roland Dowdeswell wrote: > > [ cc'ing tech-security@NetBSD.org, because there has been talk > > of GBDE there in the past.] > > So what? If the write fails in the middle, reading sector will just > produce garbage. I don't think that it's different from plain old HDD > which has been powered down in the middle of doing disk write. Disk > encryption layer is definitely not the level at which journaling should > be implemented. It's task of file system to do this. The task of > encryption layer is merely to inform the file system when transaction > (i.e. both of those two writes in this case) have been completed > successfully, so that FS can adjust its journal accordingly. > > -Maxim I could be wrong but I would assume that if it is correctly handled within softupdates there should be no need for journalling - e.g. If both transactions are not completed the writes are ignored From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 03:41:35 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EBB416A4CE for ; Tue, 1 Mar 2005 03:41:35 +0000 (GMT) Received: from smtp204.mail.sc5.yahoo.com (smtp204.mail.sc5.yahoo.com [216.136.130.127]) by mx1.FreeBSD.org (Postfix) with SMTP id 2870843D3F for ; Tue, 1 Mar 2005 03:41:35 +0000 (GMT) (envelope-from river_robert@yahoo.com.cn) Received: from unknown (HELO ZJZ) (river?robert@219.239.240.220 with login) by smtp204.mail.sc5.yahoo.com with SMTP; 1 Mar 2005 03:41:34 -0000 Date: Tue, 1 Mar 2005 11:41:08 +0800 From: "River" To: "freebsd-hackers " X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Message-Id: <20050301034135.2870843D3F@mx1.FreeBSD.org> Subject: Help about debugging FreeBSD kernel core dump file X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: river_robert@yahoo.com.cn List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 03:41:35 -0000 Hi, Everyone: How can I debug the core dump file created by kernel panic? I try to use "gdb -core vmcore.0" (vmcore.0 is 4G file because I have 4G memory) and the gdb said: this is not a vaild core file. Why? Thanks From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 03:47:57 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8786A16A4CE for ; Tue, 1 Mar 2005 03:47:57 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A19843D3F for ; Tue, 1 Mar 2005 03:47:56 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 6E75985684; Tue, 1 Mar 2005 14:17:53 +1030 (CST) Date: Tue, 1 Mar 2005 14:17:53 +1030 From: Greg 'groggy' Lehey To: River Message-ID: <20050301034753.GS73162@wantadilla.lemis.com> References: <20050301034135.2870843D3F@mx1.FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Er1qpsOqk0l6oMce" Content-Disposition: inline In-Reply-To: <20050301034135.2870843D3F@mx1.FreeBSD.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: freebsd-hackers Subject: Re: Help about debugging FreeBSD kernel core dump file X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 03:47:57 -0000 --Er1qpsOqk0l6oMce Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Format recovered--see http://www.lemis.com/email/email-format.html] Single line message. On Tuesday, 1 March 2005 at 11:41:08 +0800, River wrote: > Hi, Everyone: > > How can I debug the core dump file created by kernel panic? I try to > use "gdb -core vmcore.0" (vmcore.0 is 4G file because I have 4G > memory) and the gdb said: this is not a vaild core file. Why? Processor dumps have a different format for core dumps. Depending on the version of FreeBSD, you use one of these forms: (older) gdb -k kernel.debug vmcore.0 (newer) kgdb kernel.debug vmcore.0 You'll need a kernel compiled with debug symbols to make much sense of the dump. See http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf for more details. Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html See complete headers for address and phone numbers. --Er1qpsOqk0l6oMce Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCI+XpIubykFB6QiMRAql5AJ9saqsYGRMctrdandbbRKn/KtUFpgCeM1Gl 6t9D4OXqxdvSkoevMdbOWiA= =KUb5 -----END PGP SIGNATURE----- --Er1qpsOqk0l6oMce-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 03:48:23 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60BE216A4D0 for ; Tue, 1 Mar 2005 03:48:23 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8A9143D46 for ; Tue, 1 Mar 2005 03:48:22 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E70BA51310; Mon, 28 Feb 2005 19:48:21 -0800 (PST) Date: Mon, 28 Feb 2005 19:48:21 -0800 From: Kris Kennaway To: River Message-ID: <20050301034821.GA98258@xor.obsecurity.org> References: <20050301034135.2870843D3F@mx1.FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20050301034135.2870843D3F@mx1.FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers Subject: Re: Help about debugging FreeBSD kernel core dump file X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 03:48:23 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 01, 2005 at 11:41:08AM +0800, River wrote: > Hi, Everyone: >=20 > > How can I debug the core dump file created by kernel panic? I try to > use "gdb -core vmcore.0" (vmcore.0 is 4G file because I have 4G > memory) and the gdb said: this is not a vaild core file. Why? Read the chapter on kernel debugging in the developers' handbook, on the FreeBSD website. Kris P.S. Please wrap your lines at 70 characters so your emails may be easily read. --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCI+YFWry0BWjoQKURAqtXAJ4pI66VGn66X3bZkjfv6t80Nt9d8wCdEQSt fIaev1gQvvUqTdvs3mhvcbA= =3N2X -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 03:51:41 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92DF116A4CE for ; Tue, 1 Mar 2005 03:51:41 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BF2943D5D for ; Tue, 1 Mar 2005 03:51:41 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so1002209rnf for ; Mon, 28 Feb 2005 19:51:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Hcf9MEB92EoNoa6Xe/Tr+0HD198J2xM0e8GxoOT5pZ1lnq/1AnrwlPVq1N7bA8vGuDpatPsb5Mr1WDS1dMXpxDHaCAz2ararNtZs36MErz92B83lH17zKn0MwXNNGAQRoNpE36w06KG8i7Lj0JcLAVN/zIVb8sP3WTVBsXnOkxE= Received: by 10.38.65.28 with SMTP id n28mr328848rna; Mon, 28 Feb 2005 19:51:05 -0800 (PST) Received: by 10.38.209.22 with HTTP; Mon, 28 Feb 2005 19:51:05 -0800 (PST) Message-ID: <84dead72050228195144c13e59@mail.gmail.com> Date: Tue, 1 Mar 2005 03:51:05 +0000 From: Joseph Koshy To: river_robert@yahoo.com.cn In-Reply-To: <20050301034135.2870843D3F@mx1.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050301034135.2870843D3F@mx1.FreeBSD.org> cc: freebsd-hackers Subject: Re: Help about debugging FreeBSD kernel core dump file X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 03:51:41 -0000 > How can I debug the core dump file created by kernel panic? I try to use "gdb -core vmcore.0" (vmcore.0 is 4G file because I have 4G memory) and the gdb said: this is not a vaild core file. Why? AFAIK you have to use 'gdb -k' (or 'kgdb') to use GDB's kernel debugging mode. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 05:17:00 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99DD316A4FF for ; Tue, 1 Mar 2005 05:17:00 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED82B43D60 for ; Tue, 1 Mar 2005 05:16:59 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id B59C33700F; Tue, 1 Mar 2005 00:16:41 -0500 (EST) To: Thomas.Sparrevohn@btinternet.com In-reply-to: Your message of "Tue, 01 Mar 2005 00:08:20 GMT." <200503010008.20675.Thomas.Sparrevohn@btinternet.com> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Tue, 01 Mar 2005 00:16:41 -0500 From: Roland Dowdeswell Message-Id: <20050301051641.B59C33700F@arioch.imrryr.org> cc: freebsd-hackers@freebsd.org cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 05:17:00 -0000 On 1109635700 seconds since the Beginning of the UNIX epoch Thomas Sparrevohn wrote: > >I could be wrong but I would assume that if it is correctly handled within >softupdates there should be no need for journalling - e.g. If both >transactions are not completed the writes are ignored This does not work. The problem is that in GBDE for sector n which is written, there are two operations: 1. change the key by which sector n is encrypted, and 2. write sector n ecnrypted with the new key. If one of these fails, how could the write be ignored? If one of the two completes but not both, then one is left in the situation of either: 1. trying to decrypt the old sector with the new encryption key, or 2. trying to decrypt the new sector with the old encryption key. Either way, the sector has been lost. Neither the original contents of the sector nor the new contents can be recovered without breaking AES-128. Fsck(8) does not contain this functionality (and it would be rather impressive if it did.) Softupdates does not maintain old copies of sectors which it is writing. Hence the sector is gone forever (or for however long it takes to break AES-128.) There is no [reasonable] possibility of recovery. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 17:57:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29CC916A4CE for ; Tue, 1 Mar 2005 17:57:33 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCC4543D5A for ; Tue, 1 Mar 2005 17:57:32 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j1SM2BoH042753; Mon, 28 Feb 2005 14:02:18 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j1SM21qs042751; Mon, 28 Feb 2005 14:02:01 -0800 (PST) (envelope-from www) Date: Mon, 28 Feb 2005 14:02:01 -0800 (PST) Message-Id: <200502282202.j1SM21qs042751@marlena.vvi.at> To: elric@imrryr.org From: "ALeine" cc: freebsd-hackers@freebsd.org cc: kernel@crater.dragonflybsd.org cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 17:57:33 -0000 elric@imrryr.org wrote: > This does not work. The problem is that in GBDE for sector n > which is written, there are two operations: > > 1. change the key by which sector n is encrypted, and > 2. write sector n ecnrypted with the new key. > > If one of these fails, how could the write be ignored? If one of > the two completes but not both, then one is left in the situation > of either: > > 1. trying to decrypt the old sector with the new > encryption key, or No. > 2. trying to decrypt the new sector with the old > encryption key. Yes, the data sector is written first and then the key sector. Since, as you pointed out, GBDE is more susceptible to dictionary attacks than CGD one can then use this advantage (it's a feature, not a design flaw!) to recover the lost key so no data is lost. :-> Seriously, how can one make writing atomic without breaking compatibility with existing GBDE volumes? Which approach does CGD use to solve the problem of atomic writing? How about changing GBDE in a backwards-incompatible way by adding one key shadow sector for every n key sectors (n would be chosen at volume initialization)? The key shadow sector would hold the xor of the last encrypted key in the zone to be replaced and its replacement key, a 32 byte status chunk to indicate the status of the operation: all zeros (0x0) would indicate the new key has not been written to the key sector yet (but it is present in xor-ed form in the key shadow sector), all ones (0xFF) would indicate the new encrypted data sector has been written successfully and random garbage would indicate that both the new key and the encrypted data have been successfully written to disk. Then the relative offset of the key sector from the key shadow sector would follow and then the offset of the key within the key sector. The rest of the sector would also be padded with random garbage which would be regenerated every x writes (this value could be tunable via sysctl, kern.geom.bde.garbage_recycle_freq). The whole write procedure would look something like this: 1. read old key from key sector 2. xor-ed key = new key ^ old key 3. pad xor-ed key with: - status chunk: 32 0x0 characters - relative offset of key sector from key shadow sector (chosen at volume initialization, 8 bytes by default) - relative offset of key within key sector (8 bytes by default) 4. write padded xored key to key shadow sector 5. encrypt data with new key 6. write encrypted data to disk 7. set status chunk in key shadow sector to 0xFF 8. write new key to key sector 9. if (number of key writes % kern.geom.bde.garbage_recycle_freq == 0) then overwrite control chunk in key shadow sector and the rest of sector with random garbage else overwrite only control chunk in key shadow sector with random garbage (not to waste entropy) endif > Either way, the sector has been lost. Neither the original > contents of the sector nor the new contents can be recovered without > breaking AES-128. Fsck(8) does not contain this functionality (and it > would be rather impressive if it did.) The solution I proposed always provides consistent atomic writes. If only the encrypted data sector gets written and the key does not get written to the key sector, you can recover the new key by xor-ing the xor-ed key from the key shadow sector with the old key. That way fsck(8) would only need to walk through all the key shadow sectors and check for 0xFF status chunks and recover new keys automatically. Zero control chunks would have to be handled by the user since fsck(8) would have no way of telling whether a zero chunk means the newly encrypted data got written to disk (and the plug was pulled just before the control chunk was to be set to 0xFF) or not (the new key just got written to disk in xor-ed form, but the existing key and data are unchanged). The simplest way would be to let fsck(8) report and record all zero chunks in the form which could be fed to a utility which would set the key directly. The input (output generated by fsck(8)) for such a utility would consist of the device name, relative offset and the key. Both options would always be listed and then the user could try all the alternatives and see which key is the right one. There would be a performance hit, but I would like to see this implemented to see just how big the difference would be. What do you guys think of this solution? ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 19:02:14 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E05F16A4CE for ; Tue, 1 Mar 2005 19:02:14 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16CC443D1F for ; Tue, 1 Mar 2005 19:02:14 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id 415CF37017; Tue, 1 Mar 2005 14:01:56 -0500 (EST) To: "ALeine" In-reply-to: Your message of "Mon, 28 Feb 2005 14:02:01 PST." <200502282202.j1SM21qs042751@marlena.vvi.at> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Tue, 01 Mar 2005 14:01:56 -0500 From: Roland Dowdeswell Message-Id: <20050301190156.415CF37017@arioch.imrryr.org> cc: freebsd-hackers@freebsd.org cc: kernel@crater.dragonflybsd.org cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 19:02:14 -0000 On 1109628121 seconds since the Beginning of the UNIX epoch "ALeine" wrote: > >Yes, the data sector is written first and then the key sector. >Since, as you pointed out, GBDE is more susceptible to dictionary >attacks than CGD one can then use this advantage (it's a feature, >not a design flaw!) to recover the lost key so no data is lost. :-> > >Seriously, how can one make writing atomic without breaking >compatibility with existing GBDE volumes? Which approach does CGD >use to solve the problem of atomic writing? You would need to maintain some sort of journal. With CGD, I specifically avoided any strategy which tied the write of one sector to the write of another sector for this reason. And so, I use one key to encrypt the disk rather than storing randomly generated keys upon every write. GBDE already explodes a single sector write into two sector writes, which makes its performance quite suboptimal. Adding a journal would make it even worse. I do not think that maintaining a different key for each sector actually provides enough benefit to justify this. >How about changing GBDE in a backwards-incompatible way by adding >one key shadow sector for every n key sectors (n would be chosen at >volume initialization)? The key shadow sector would hold the xor of This is basically implementing a journal. It adds a lot of complexity for IMO very little gain over moving to a simpler solution such as CGD. The whole thing (GBDE) is already pretty brittle, i.e. hard to change without breaking. This would make it more so. And, GBDE is obviously already less secure than a simpler approach such as CGD with AES-256 (which is around twice as fast). Many rather dubious claims have been made about GBDE such as in: http://www.bsdcan.org/2004/papers/gbde.pdf PHK claims that it will take O(2^384) to crack GBDE if the lock sector is destroyed. Perhaps my maths is a little rusty, but it perplexes me how it could possibly take 2^384 steps to individually crack 2^30 sectors that are encrypted with 128 bit AES. That comes out to a [not at all strict] upper bound of 2^158 steps to entirely crack a 512GB disk. So, already it is less secure than CGD using 256 bit AES. But, obviously you'd just crack the ``key-key sectors'' which would knock another 5 bits off. Now, consider that really an attacker doesn't really care about the whole disk. By chasing directory structures, etc., they could find what they wanted in very little more than O(2^128). So, what's the point of all of the gymnastics... a few bits. It is also structured in such a way that substantial breakthroughs in the cracking of many different encryption algorithms, hashes and random number generators will bring the house of cards down. I do not believe that it has had an appropriate amount of peer review to be considered trustworthy, and I have seen some pretty obvious weaknesses that I've been meaning to write up but haven't quite found the time that would knock a few more bits off. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 19:20:54 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8260A16A4CE for ; Tue, 1 Mar 2005 19:20:54 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1028C43D1F for ; Tue, 1 Mar 2005 19:20:53 +0000 (GMT) (envelope-from sarath.kamisetty@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so1319687rnf for ; Tue, 01 Mar 2005 11:20:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=X+lQQFSl4Wj4oUkTCOrPc9z1Ls4VFlIysbRsXDqeB6R6BBcN6XktansaoqyeKX+eR54/SXA3gfvWYTY9Tgid7b5+gbjrhVBfVnWTkYMq6dNI1hbacxt5Xu054+QfJfhkjCUT6BIhLMNVr4X7e8Sz/GYJLqfm6iUKC6/2E+bgNSI= Received: by 10.38.75.43 with SMTP id x43mr134755rna; Tue, 01 Mar 2005 11:20:25 -0800 (PST) Received: by 10.39.3.1 with HTTP; Tue, 1 Mar 2005 11:20:23 -0800 (PST) Message-ID: <641e6aa9050301112016d316bb@mail.gmail.com> Date: Tue, 1 Mar 2005 11:20:23 -0800 From: Sarath Kamisetty To: Julian Elischer In-Reply-To: <4222D5A2.9010301@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <001a01c51d6d$d50ce500$abe243a4@ash> <4222D5A2.9010301@elischer.org> cc: freebsd-hackers@freebsd.org cc: Ashwin Chandra Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Sarath Kamisetty List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 19:20:54 -0000 Hi, How does Linux handle this ? Any idea ? Thanks, Sarat On Mon, 28 Feb 2005 00:26:10 -0800, Julian Elischer wrote: > Ashwin Chandra wrote: > > I wanted to get some clarification about the 4BSD scheduler. I am sort of > > confused why there are two forms of scheduling, one done between processes and > > another done between threads in a process. The priority calculations seem to be > > done only with processes and I assume that the global run queue holds processes, > > not threads. Also why is there only 1 run queue for 1 CPU. What happens to > > blocked processes and ready to be runned processes? > > Part of the challenge of adding threads to a system is to make it hard for a > threaded process to "flood" the system run queues so that other processes > get no cpu time. > > The scheme in the current freeBSD schedulers is a "crude" method, by which > only a limitted number of threads per process are allowed to be added to > the system run queue. RUnnable hreads fo r aprocess are kept on a run queue for > the process and only the highest N prioriy hreads are actually put on the > system run queue. > > This is by no means the best way, but rather the > easiest way. I am hoping that some PhD candidate somewhere will decide > that thread scheduling is his topic and will figure out a better way > of doing this. > > both run queues hold threads. This is still a place wjere a lot > of work can be done. > > :-) > > > > > > Ash > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 19:25:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A16416A4CF for ; Tue, 1 Mar 2005 19:25:06 +0000 (GMT) Received: from web31008.mail.mud.yahoo.com (web31008.mail.mud.yahoo.com [68.142.200.171]) by mx1.FreeBSD.org (Postfix) with SMTP id 7B1D143D5D for ; Tue, 1 Mar 2005 19:25:05 +0000 (GMT) (envelope-from dyeske@yahoo.com) Received: (qmail 12549 invoked by uid 60001); 1 Mar 2005 19:25:04 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=fuBVQs+GZHYvCTFio14pKcZstmuBWFVjtbJTChKSXOfrtIyqFi+Cjsg9izF8PrIKqdgJ7IgFCPf51l3k5J8lhpbpdwJ5BfebahoQIQ0Qw7lO0Bv4ohVbmwK7fa8NJYBZobEZpdZMzfylUYt5jpVcMBBENxdS2v/RpbndKSjgvNs= ; Message-ID: <20050301192503.12547.qmail@web31008.mail.mud.yahoo.com> Received: from [65.182.34.163] by web31008.mail.mud.yahoo.com via HTTP; Tue, 01 Mar 2005 11:25:03 PST Date: Tue, 1 Mar 2005 11:25:03 -0800 (PST) From: David Yeske To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: hackers@freebsd.org cc: scottl@freebsd.org cc: wes@freebsd.org Subject: smbfs install option for sysinstall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 19:25:06 -0000 I modified the installer a while back to be able to install from a smb share. http://futurebsd.sourceforge.net/freebsd/smbfs/ It needs a little work though. I'm looking for some feedback although I have tested it recently. I have done a recent install from a Windows XP machine joined to a domain using a share that required domain admin credentials. Here are a couple of issues that should be fixed. 1. I am not sure how to get the smbfs kernel support into the installer without also putting it into the GENERIC kernel of the release. 2. If a user uses is prompted for a password, then the output will make sysinstall look kinda funny, although the user can enter the password properly. There is probably a way to intercept the stdin and stdout of mount_smbfs and have it display in a menu? This should work similar to the root password change option? 3. This may add too much space to the floppy installer? 4. The English used in the menus could be better. Regards, David Yeske __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 19:49:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EF7A16A4CE for ; Tue, 1 Mar 2005 19:49:33 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF9EA43D2F for ; Tue, 1 Mar 2005 19:49:30 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 6A72A7A403; Tue, 1 Mar 2005 11:49:30 -0800 (PST) Message-ID: <4224C74A.2030205@elischer.org> Date: Tue, 01 Mar 2005 11:49:30 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Sarath Kamisetty References: <001a01c51d6d$d50ce500$abe243a4@ash> <4222D5A2.9010301@elischer.org> <641e6aa9050301112016d316bb@mail.gmail.com> In-Reply-To: <641e6aa9050301112016d316bb@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: Ashwin Chandra Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 19:49:33 -0000 Sarath Kamisetty wrote: >Hi, > >How does Linux handle this ? Any idea ? > > If you make 1000 threads, you get 1000 slots on the scheduler. (last time I looked.. Let me know if I'm wrong). The guy next to you with 'vi' gets 1 slot.. who gets more cpu? >Thanks, >Sarat > >On Mon, 28 Feb 2005 00:26:10 -0800, Julian Elischer wrote: > > >>Ashwin Chandra wrote: >> >> >>>I wanted to get some clarification about the 4BSD scheduler. I am sort of >>>confused why there are two forms of scheduling, one done between processes and >>>another done between threads in a process. The priority calculations seem to be >>>done only with processes and I assume that the global run queue holds processes, >>>not threads. Also why is there only 1 run queue for 1 CPU. What happens to >>>blocked processes and ready to be runned processes? >>> >>> >>Part of the challenge of adding threads to a system is to make it hard for a >>threaded process to "flood" the system run queues so that other processes >>get no cpu time. >> >>The scheme in the current freeBSD schedulers is a "crude" method, by which >>only a limitted number of threads per process are allowed to be added to >>the system run queue. RUnnable hreads fo r aprocess are kept on a run queue for >>the process and only the highest N prioriy hreads are actually put on the >>system run queue. >> >>This is by no means the best way, but rather the >>easiest way. I am hoping that some PhD candidate somewhere will decide >>that thread scheduling is his topic and will figure out a better way >>of doing this. >> >>both run queues hold threads. This is still a place wjere a lot >>of work can be done. >> >>:-) >> >> >> >> >>>Ash >>>_______________________________________________ >>>freebsd-hackers@freebsd.org mailing list >>>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >>> >>> >>_______________________________________________ >>freebsd-hackers@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> >> >> From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 20:22:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B5BF16A4CE for ; Tue, 1 Mar 2005 20:22:33 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49C9743D3F for ; Tue, 1 Mar 2005 20:22:33 +0000 (GMT) (envelope-from mhersant@comcast.net) Received: from [192.168.2.102] (c-24-22-136-36.client.comcast.net[24.22.136.36]) by comcast.net (rwcrmhc12) with ESMTP id <2005030120223301400hqqe8e>; Tue, 1 Mar 2005 20:22:33 +0000 Message-ID: <4224CF06.7060103@comcast.net> Date: Tue, 01 Mar 2005 12:22:30 -0800 From: Matt User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: retricted environment X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 20:22:33 -0000 When providing a shell environment for a larger number of users, what is the best way to retrict access to commands/resources? I've already setup quotas. I don't want users playing with system commands. I've read something about a retricted shell, but can't find any details. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 20:31:18 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC7BB16A4CE for ; Tue, 1 Mar 2005 20:31:18 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 677D743D1D for ; Tue, 1 Mar 2005 20:31:18 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D6E1V-0003oa-00; Tue, 01 Mar 2005 21:31:17 +0100 Received: from [84.128.137.157] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1D6E1V-0005Nk-00; Tue, 01 Mar 2005 21:31:17 +0100 From: Max Laier To: freebsd-hackers@freebsd.org Date: Tue, 1 Mar 2005 21:31:07 +0100 User-Agent: KMail/1.7.2 References: <4224CF06.7060103@comcast.net> In-Reply-To: <4224CF06.7060103@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart277483390.gHWZcVMIyF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200503012131.15528.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Matt Subject: Re: retricted environment X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 20:31:19 -0000 --nextPart277483390.gHWZcVMIyF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 01 March 2005 21:22, Matt wrote: > When providing a shell environment for a larger number of users, what is > the best way to retrict access to commands/resources? I've already > setup quotas. I don't want users playing with system commands. I've > read something about a retricted shell, but can't find any details. I am not sure a restricted shell is the best sollution for interactive setu= ps,=20 but one is availale from src/contrib/sendmail/smrsh. See README for usage= =20 and build information. This, however, is more a thing for cvs-wrappers or= =20 stuff like that. =46or interactive environments you can use the normal group/user permission= s and=20 of course jail(8)s. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart277483390.gHWZcVMIyF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCJNETXyyEoT62BG0RAjJwAJ4zj0sU7JYWJ5Y5aFsp2YlsmKnlegCdH0sF dtygorzTmqigFJ0SrHReAuk= =MueK -----END PGP SIGNATURE----- --nextPart277483390.gHWZcVMIyF-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 20:47:32 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42A3F16A4CE for ; Tue, 1 Mar 2005 20:47:32 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8AE743D2F for ; Tue, 1 Mar 2005 20:47:31 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 11716 invoked from network); 1 Mar 2005 20:47:31 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 1 Mar 2005 20:47:31 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j21KlPbW074756; Tue, 1 Mar 2005 15:47:25 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Tue, 1 Mar 2005 13:31:17 -0500 User-Agent: KMail/1.6.2 References: <4223A1D1.6000104@ngs.ru> <200502281606.50074.peter@wemm.org> In-Reply-To: <200502281606.50074.peter@wemm.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503011331.17677.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Denis Ustimenko Subject: Re: TDF_NEEDRESCHED when extending pcb on x86 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 20:47:32 -0000 On Monday 28 February 2005 07:06 pm, Peter Wemm wrote: > On Monday 28 February 2005 02:57 pm, Denis Ustimenko wrote: > > Hi, there! > > > > I've tried s3switch utility from ports on 5.2.1 and found that > > i386_set_ioperm syscall doesn't work properly. The next code illustrates > > the problem. It will get SIGBUS with very high probability. > > > > #include > > #include > > #include > > > > int main() > > { > > if ( i386_set_ioperm( 0x80, 1, 1)) { > > perror("XXX"); > > return 1; > > } > > inb( 0x80); > > return 0; > > } > > > > Now I have no 5.3 or CURRENT system but brief looking on code shows that > > it should give the same result on them. > > The problem occurs when we extend pcb and set TDF_NEEDRESCHED bit hoping > > that thread will be rescheduled and new TSS will be loaded. But > > sched_switch function skips cpu_switch when thread was not changed and > > ltr is not executed. > > I think it would be better to fix the semantics of TDF_NEEDRESCHED. I was > thinking that mi_switch could negate the cpu_switch optimization if > TDF_NEEDRESCHED was set. That would avoid duplicating the internal > knowledge of the pcb/tss/etc handling in this code. Forcing a context switch is a rather round-about way of getting ltr to be executed though. We already have intimate knowledge of TSS, etc. in this file anyway, so I wonder if just doing the ltr() directly is the better approach? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 21:01:41 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5163616A4CE for ; Tue, 1 Mar 2005 21:01:41 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id E39B043D39 for ; Tue, 1 Mar 2005 21:01:39 +0000 (GMT) (envelope-from mhersant@comcast.net) Received: from [192.168.2.102] (c-24-22-136-36.client.comcast.net[24.22.136.36]) by comcast.net (sccrmhc13) with ESMTP id <2005030121013701600sgtsde>; Tue, 1 Mar 2005 21:01:38 +0000 Message-ID: <4224D830.4080401@comcast.net> Date: Tue, 01 Mar 2005 13:01:36 -0800 From: Matt User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: freebsd-hackers@freebsd.org References: <4224CF06.7060103@comcast.net> <200503012131.15528.max@love2party.net> In-Reply-To: <200503012131.15528.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: retricted environment X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 21:01:41 -0000 Max Laier wrote: >On Tuesday 01 March 2005 21:22, Matt wrote: > > >>When providing a shell environment for a larger number of users, what is >>the best way to retrict access to commands/resources? I've already >>setup quotas. I don't want users playing with system commands. I've >>read something about a retricted shell, but can't find any details. >> >> > >I am not sure a restricted shell is the best sollution for interactive setups, >but one is availale from src/contrib/sendmail/smrsh. See README for usage >and build information. This, however, is more a thing for cvs-wrappers or >stuff like that. > >For interactive environments you can use the normal group/user permissions and >of course jail(8)s. > > > Thanks, I'll look at that. To allow retricted access using groups/users, is the normal procedure to remote o+rwx permissions from the selected commands/directories? Hmm. I thought the kernel secure level setting which helped restrict users. I've much to learn. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 21:15:21 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C87516A4CE for ; Tue, 1 Mar 2005 21:15:21 +0000 (GMT) Received: from coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3690B43D3F for ; Tue, 1 Mar 2005 21:15:19 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from localhost (localhost [127.0.0.1]) by coe.ufrj.br (Postfix) with ESMTP id D7F761701D; Tue, 1 Mar 2005 18:15:17 -0300 (BRT) Received: from coe.ufrj.br ([146.164.53.65]) by localhost (roma.coe.ufrj.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68218-04; Tue, 1 Mar 2005 18:15:14 -0300 (BRT) Received: from [10.0.8.17] (nat.int.gov.br [200.20.196.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by coe.ufrj.br (Postfix) with ESMTP id E8E1017017; Tue, 1 Mar 2005 18:15:13 -0300 (BRT) Message-ID: <4224DB61.3060704@jonny.eng.br> Date: Tue, 01 Mar 2005 18:15:13 -0300 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <001a01c51d6d$d50ce500$abe243a4@ash> <4222D5A2.9010301@elischer.org> <641e6aa9050301112016d316bb@mail.gmail.com> <4224C74A.2030205@elischer.org> In-Reply-To: <4224C74A.2030205@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at coe.ufrj.br cc: freebsd-hackers@freebsd.org cc: Sarath Kamisetty cc: Ashwin Chandra Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 21:15:21 -0000 Julian Elischer wrote: > Sarath Kamisetty wrote: >> Hi, >> >> How does Linux handle this ? Any idea ? > > If you make 1000 threads, you get 1000 slots on the scheduler. (last > time I looked.. > Let me know if I'm wrong). > > The guy next to you with 'vi' gets 1 slot.. > who gets more cpu? And how is that different from forking 1000 processes and use shared memory to communicate? I'll tell you: the thread option will be better for every user in that machine, so let's promote threads. IMHO, a thread should have the same privilege as a full processes, and it should count as a process for resource limits. > > > >> Thanks, >> Sarat >> >> On Mon, 28 Feb 2005 00:26:10 -0800, Julian Elischer >> wrote: >> >> >>> Ashwin Chandra wrote: >>> >>> >>>> I wanted to get some clarification about the 4BSD scheduler. I am >>>> sort of >>>> confused why there are two forms of scheduling, one done between >>>> processes and >>>> another done between threads in a process. The priority calculations >>>> seem to be >>>> done only with processes and I assume that the global run queue >>>> holds processes, >>>> not threads. Also why is there only 1 run queue for 1 CPU. What >>>> happens to >>>> blocked processes and ready to be runned processes? >>>> >>> >>> Part of the challenge of adding threads to a system is to make it >>> hard for a >>> threaded process to "flood" the system run queues so that other >>> processes >>> get no cpu time. >>> >>> The scheme in the current freeBSD schedulers is a "crude" method, by >>> which >>> only a limitted number of threads per process are allowed to be added to >>> the system run queue. RUnnable hreads fo r aprocess are kept on a run >>> queue for >>> the process and only the highest N prioriy hreads are actually put >>> on the >>> system run queue. >>> >>> This is by no means the best way, but rather the >>> easiest way. I am hoping that some PhD candidate somewhere will decide >>> that thread scheduling is his topic and will figure out a better way >>> of doing this. >>> >>> both run queues hold threads. This is still a place wjere a lot >>> of work can be done. >>> >>> :-) >>> >>> >>> >>> >>>> Ash >>>> _______________________________________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> To unsubscribe, send any mail to >>>> "freebsd-hackers-unsubscribe@freebsd.org" >>>> >>> >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >>> >>> > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 21:40:39 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C879416A4CE for ; Tue, 1 Mar 2005 21:40:39 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F2BA43D46 for ; Tue, 1 Mar 2005 21:40:39 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j211jNoH046189; Mon, 28 Feb 2005 17:45:24 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j211jF1s046188; Mon, 28 Feb 2005 17:45:15 -0800 (PST) (envelope-from www) Date: Mon, 28 Feb 2005 17:45:15 -0800 (PST) Message-Id: <200503010145.j211jF1s046188@marlena.vvi.at> To: elric@imrryr.org From: "ALeine" cc: freebsd-hackers@freebsd.org cc: kernel@crater.dragonflybsd.org cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 21:40:39 -0000 elric@imrryr.org wrote: > You would need to maintain some sort of journal. With CGD, I > specifically avoided any strategy which tied the write of one > sector to the write of another sector for this reason. And so, > I use one key to encrypt the disk rather than storing randomly > generated keys upon every write. > > GBDE already explodes a single sector write into two sector > writes, which makes its performance quite suboptimal. Adding a > journal would make it even worse. I do not think that maintaining a > different key for each sector actually provides enough benefit to > justify this. I find using a single key for the whole disk less secure and not very practical when one wants to change the key because it takes a very long time to re-encrypt the entire disk. However, having a separate per-sector key which is changed on every write seems to go too far in the opposite direction, so IMHO the best solution would be to use the same key for a definable number of sectors (set at initialization) and then having a sysctl variable to control after how many writes you want the key changed. This would speed things up quite a bit and users would be allowed to decide how much assumed security they are willing to sacrifice for noticable speed. This would also make it possible to implement my key shadow sector idea without a performance penalty in comparison to the current implementation of GBDE. > This is basically implementing a journal. It adds a lot of > complexity for IMO very little gain over moving to a simpler solution such > as CGD. The whole thing (GBDE) is already pretty brittle, i.e. hard > to change without breaking. This would make it more so. Well, it does not need to be very complex and I am more interested in getting this kind of functionality in 4.x, so I think that porting GBDE would be more work than writing my own implementation from scratch and just using the same principles, only adapted and implemented in a way to suit my ideas and needs. > And, GBDE is obviously already less secure than a simpler > approach such as CGD with AES-256 (which is around twice as fast). I believe it is not less secure because eventhough it might require less steps to brute force a sensitive part of the filesystem (some directory structure), the impact is completely localized and can't be used to leverage a wider compromise, while that is not the case with CGD. As I said, I believe the speed of GBDE could be greatly improved by implementing my ideas, but AFAIK there seems to be very little you can do to improve the speed of CGD beyond how fast it is now because it is already using the most simple approach and any additional optimization attempts would only increase the complexity, which is something you seem to want to avoid at all cost. > Many rather dubious claims have been made about GBDE such as in: > > http://www.bsdcan.org/2004/papers/gbde.pdf > > PHK claims that it will take O(2^384) to crack GBDE if the lock > sector is destroyed. Perhaps my maths is a little rusty, but it > perplexes me how it could possibly take 2^384 steps to > individually crack 2^30 sectors that are encrypted with 128 bit AES. > That comes out to a [not at all strict] upper bound of 2^158 steps to > entirely crack a 512GB disk. So, already it is less secure than CGD > using 256 bit AES. But, obviously you'd just crack the ``key-key > sectors'' which would knock another 5 bits off. Now, consider that > really an attacker doesn't really care about the whole disk. By chasing > directory structures, etc., they could find what they wanted in > very little more than O(2^128). So, what's the point of all of > the gymnastics... a few bits. I believe PHK's calculations are based on the fact that even if you want to brute force a GBDE volume, you have to assume it's encrypted using GBDE and then try to break the structured multilayered mechanism, because otherwise you can only hope to brute force a very minimal part of the disk that would do you no good in leveraging that knowledge to break the encryption of the rest of the disk. > It is also structured in such a way that substantial > breakthroughs in the cracking of many different encryption algorithms, > hashes and random number generators will bring the house of cards down. > I do not believe that it has had an appropriate amount of peer > review to be considered trustworthy, and I have seen some pretty > obvious weaknesses that I've been meaning to write up but haven't > quite found the time that would knock a few more bits off. I believe PHK is well aware of the threats, he even commented on them in the code itself and his papers, his choice of SHA2/512, for example, shows that he is planning for those advances that pose a threat. I am sure there is room for a lot of improvement in GBDE and eventhough not that many reputable cryptographers have reviewed GBDE so far, those who have are very well respected, like Lucky Green, for example. I hope you will find the time to write an analysis of the weaknesses you found, I would be very interested in seeing if they would apply to what I have in mind. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 22:04:40 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 577AD16A4CE; Tue, 1 Mar 2005 22:04:40 +0000 (GMT) Received: from intranet.ru (intranet.ru [212.164.71.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 314B643D53; Tue, 1 Mar 2005 22:04:38 +0000 (GMT) (envelope-from denus@ngs.ru) Received: from [172.16.0.10] (HELO smtp.ngs.ru) by intranet.ru (CommuniGate Pro SMTP 4.2.4) with ESMTP id 205170427; Wed, 02 Mar 2005 04:05:59 +0600 Received: from ngs.ru (unknown [83.237.135.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ngs.ru (Postfix) with ESMTP id E0D18774CC6; Wed, 2 Mar 2005 04:04:33 +0600 (NOVT) Message-ID: <4224E73E.6080105@ngs.ru> Date: Wed, 02 Mar 2005 01:05:50 +0300 From: Denis Ustimenko User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20041215 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: John Baldwin References: <4223A1D1.6000104@ngs.ru> <200502281606.50074.peter@wemm.org> <200503011331.17677.jhb@FreeBSD.org> In-Reply-To: <200503011331.17677.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@FreeBSD.org Subject: Re: TDF_NEEDRESCHED when extending pcb on x86 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 22:04:40 -0000 John Baldwin wrote: > On Monday 28 February 2005 07:06 pm, Peter Wemm wrote: > >>On Monday 28 February 2005 02:57 pm, Denis Ustimenko wrote: >> >>>The problem occurs when we extend pcb and set TDF_NEEDRESCHED bit hoping >>>that thread will be rescheduled and new TSS will be loaded. But >>>sched_switch function skips cpu_switch when thread was not changed and >>>ltr is not executed. >> >>I think it would be better to fix the semantics of TDF_NEEDRESCHED. I was >>thinking that mi_switch could negate the cpu_switch optimization if >>TDF_NEEDRESCHED was set. That would avoid duplicating the internal >>knowledge of the pcb/tss/etc handling in this code. > > > Forcing a context switch is a rather round-about way of getting ltr to be > executed though. We already have intimate knowledge of TSS, etc. in this > file anyway, so I wonder if just doing the ltr() directly is the better > approach? > Yes, John, I think it's better to load TR directly. Usage of TDF_NEEDRESCHED for loading TR is the only platform specific resort of this bit, so elimination of it makes design more clear and we do not need drop out cpu_switch optimization. -- Best regards Denis From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 23:15:49 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A72F216A4CE for ; Tue, 1 Mar 2005 23:15:49 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44EA643D1D for ; Tue, 1 Mar 2005 23:15:49 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j213KPoH047667; Mon, 28 Feb 2005 19:20:26 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j213KI8U047666; Mon, 28 Feb 2005 19:20:18 -0800 (PST) (envelope-from www) Date: Mon, 28 Feb 2005 19:20:18 -0800 (PST) Message-Id: <200503010320.j213KI8U047666@marlena.vvi.at> To: smb@cs.columbia.edu From: "ALeine" cc: freebsd-hackers@freebsd.org cc: elric@imrryr.org cc: kernel@crater.dragonflybsd.org cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 23:15:49 -0000 smb@cs.columbia.edu wrote: > I confess that I still don't see the threat model here. What > sort of cryptanalytic breakthrough would make this a requirement? > I will state categorically that I know of no threat to AES that > would be addressed by this, but wouldn't require replacing AES entirely. > > The canonical example is "encrypting too much data with the same > key". That can be a real concern. With DES or 3DES (or any other > cipher with a 64-bit blocksize), one should never encrypt more than > 8*2^32 bytes -- about 32G -- with a single key if you're using CBC mode. > The corresponding figure for AES is 16*2^64 -- a *much* larger number, > and one well beyond any conceivable disk drive. > > Historically, there have been ciphers that were attackable with > lots of traffic, but typically the issue was repetition of the key > stream. > > That's not going to happen here. I leave as an exercise for the > reader computing just how unlikely it is -- but it's *very* unlikely. > Remember that we're dealing with 128-bit input blocks. > > It is, of course, conceivable that someone will find a way to use > hundreds of gigabytes of data encrypted with one key to find some > shortcut attack on AES -- perhaps 2^112 trials instead of 2^128. > Given the reaction in the cryptographic community to the SHA1 attack, > which cuts the time to 2^69 from 2^80, I'm quite confident of what > would happen: a replacement for AES. Thank you for taking the time to write that insightful post, I have read a number of your books and let me say it's an honour to hear your comments on this. :-) Regarding the threat model - imagine an attacker sending you a number of large (> 128kb), specially crafted emails and then getting hold of your CGD encrypted disk with those emails stored on that encrypted disk. Let's also assume the attacker would be roughly familiar with the disk layout on your computer and could locate the 4 Mb block on the disk inside which his emails are located. This would make CGD an easier target to a kind of known plaintext attack than if the emails were stored in chunks encrypted with different keys, as that is the case with GBDE. Algebraic attacks on AES show that AES may indeed be broken sooner than we would hope, at least according to the information at: http://www.cryptosystem.net/aes/ In a recent paper (Asiacrypt 2002), Nicolas Courtois and Josef Pieprzyk show that Rijndael can be written as an overdefined system of multivariate quadratic equations (MQ). For example authors show that for 128-bit Rijndael, the problem of recovering the secret key from one single plaintext can be written as a system of 8000 quadratic equations with 1600 binary unknowns. Thus the security of Rijndael requires that there are no efficient algorithms for solving such systems. In a paper published at Eurocrypt 2000 Shamir et al. describe an algorithm called XL (or/and FXL) able to solve efficiently many such systems of equations. Attacking AES/Rijndael by such a method requires only a few known plaintexts to succeed. If this method can be made to work in practice, it is a major revolution in cryptanalysis: all classical attacks on block ciphers such as linear/differential and other approximation attacks require a number of plaintexts that is very big and grows exponentially in the number of rounds. In practice the algorithm XL fails (quite miserably) to break Rijndael. However the system obtained from Rijndael is not random, and has many special properties: it is overdefined, sparse and very structured. From this, in a recent paper, Nicolas Courtois and Josef Pieprzyk investigate how to improve XL and adapt it to such special systems. They propose a new class of attacks, attack, called XSL attacks. There is no doubt that attacks such as XL and XSL do work in many interesting cases. Unfortunately they are heuristic, and their behaviour is not well understood. There are examples where these or similar attacks do behave in practice as it is predicted, and there are examples where they don't. This is how the security of AES became a hot topic. > That said, if you were concerned there's a very simple solution: > to encrypt block B with master key K, calculate some cryptographic > function F(K, B) -- ECB encryption is the obvious choice -- and > use that as the block key. Use F'(B) or F'(K, B) to get the > per-block IV. > > Add any wrinkles you want, such as caching F and F' values, or > having F apply to a range of blocks. That is roughly what I had in mind. > I see no need to rekey the disk. I do see a need to change the > user-specified key, but that can be handled by a layer of > indirection. If there were some sort of compromise that made you > want to rekey the entire disk, having per-block keys won't help; > you still need to read, decrypt, re-encrypt, and rewrite each block, > since any likely compromise scenario would involve compromise of the > key block as well. Agreed, the user-specified key would be used to encrypt keys for data encryption, so only those keys would have to be rekeyed, the data itself would remain unchanged. This would be done in a way which would not make it possible for someone to reconstruct the master key or decrypt any other keys, so any compromise would be very localized. The user-specified key would naturally have to be changed regularly because it is the weakest link in that chain. > There's a school of cryptographic design that tosses in > mechanisms on the vague hunch that there's threat out there. Unless you > understand the threats and the tradeoffs, though, you're likely to make > matters worse, not better. Often, there is no perfect solution, but if > you don't understand the *real* threats you'll make the wrong tradeoffs. > > It's worth noting that there is a very real threat not addressed > here: detecting unauthorized changes to an encrypted disk. For a very > elegant solution, see > http://www.isoc.org/isoc/conferences/ndss/05/proceedings/papers/storageint.pdf Thank you, I will definitely take a closer look, perhaps that approach might also be used to provide faster guaranteed atomic writes in a multistep scenario such as the one I described. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 00:45:54 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7A5E16A4CE for ; Wed, 2 Mar 2005 00:45:54 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04F9E43D3F for ; Wed, 2 Mar 2005 00:45:52 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id DFF6737012; Tue, 1 Mar 2005 19:45:34 -0500 (EST) To: "ALeine" In-reply-to: Your message of "Mon, 28 Feb 2005 17:45:15 PST." <200503010145.j211jF1s046188@marlena.vvi.at> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Tue, 01 Mar 2005 19:45:34 -0500 From: Roland Dowdeswell Message-Id: <20050302004534.DFF6737012@arioch.imrryr.org> cc: freebsd-hackers@freebsd.org cc: kernel@crater.dragonflybsd.org cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 00:45:54 -0000 On 1109641515 seconds since the Beginning of the UNIX epoch "ALeine" wrote: > >> And, GBDE is obviously already less secure than a simpler >> approach such as CGD with AES-256 (which is around twice as fast). > >I believe it is not less secure because eventhough it might require >less steps to brute force a sensitive part of the filesystem (some >directory structure), the impact is completely localized and can't >be used to leverage a wider compromise, while that is not the case But, I said that it requires less steps to brute force the entire disk not just some parts of the filesystem. Every last sector of a 512GB disk can be brute forced in 2^158 steps using the most naive method. All of the key-key sectors can be brute forced in 2^153 steps. This is much less than 2^256 which is what it would take to brute force 256 bit AES. So, until someone can crack 256 bit AES in < (2^25 * O(AES128)) steps, yes it is less secure. Or, one should say 256 bit AES with a lot of known plaintext in less than 2^25 * O(AES128). >with CGD. As I said, I believe the speed of GBDE could be greatly >improved by implementing my ideas, but AFAIK there seems to be very >little you can do to improve the speed of CGD beyond how fast it is >now because it is already using the most simple approach and any >additional optimization attempts would only increase the complexity, >which is something you seem to want to avoid at all cost. I am not against adding complexity, just against adding needless complexity which has every appearance of introducing new methods of attacking the disk without appreciably increasing the cost of brute forcing it. CGD does contain a reasonable amount of complexity in some areas: 1. it has a modular mechanism for defining crypto algorithms, these do not need to be restricted to AES vs DES but could include things like ``GBDE'', 2. it takes care to turn passphrases into keys properly, and 3. it allows for the addition of new mechanisms to do (2). 4. etc. But, I also believe that one should solve first things first. That's why I put most of my effort into defeating dictionary attacks and making the sytem modular, etc. There is no point in worrying about what happens if someone breaks AES next year if you are putting out a system this year which can be compromised in months with a dictionary attack. Focus on the weakest links first and right now AES is not the weakest link. There is little point in replacing your front door with a steel reinforced door if all of your windows are open. >I believe PHK's calculations are based on the fact that even if you want >to brute force a GBDE volume, you have to assume it's encrypted using GBDE >and then try to break the structured multilayered mechanism, because >otherwise you can only hope to brute force a very minimal part of the >disk that would do you no good in leveraging that knowledge to break >the encryption of the rest of the disk. But, you do not have to break the structured multilayered mechanism at all. You can just brute force each sector one by one in much less than 2^384 steps and hence the claim is both trivially and obviously false. Or just crack one key-key sector in 2^128, reverse the MD5 in 2^128 to obtain the salt and get the rest of the disk in < 2^128, for a grand total of O(2^129). Together these methods seem to indicate that 2^384 is a little exaggerated. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 01:15:05 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 577C616A4CE for ; Wed, 2 Mar 2005 01:15:05 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id B95FF43D2D for ; Wed, 2 Mar 2005 01:15:04 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id CF7333700F; Tue, 1 Mar 2005 20:14:47 -0500 (EST) To: "Steven M. Bellovin" In-reply-to: Your message of "Tue, 01 Mar 2005 17:15:11 EST." <20050301221511.3423C3C023E@berkshire.machshav.com> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Tue, 01 Mar 2005 20:14:47 -0500 From: Roland Dowdeswell Message-Id: <20050302011447.CF7333700F@arioch.imrryr.org> cc: ALeine cc: freebsd-hackers@freebsd.org cc: kernel@crater.dragonflybsd.org cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 01:15:05 -0000 On 1109715311 seconds since the Beginning of the UNIX epoch "Steven M. Bellovin" wrote: > >It's worth noting that there is a very real threat not addressed here: >detecting unauthorized changes to an encrypted disk. For a very >elegant solution, see http://www.isoc.org/isoc/conferences/ndss/05/proceedings >/papers/storageint.pdf I thought about this a little when I was writing CGD and decided that since it would involve changing the block size or updating multiple blocks when one block was modified that it would be handled much better at the file system layer than at the disk layer. E.g. right now LFS uses a checksum to determine if a segment write has fully completed upon recovery from a crash. It would be easy to modify that checksum into an HMAC. That would provide integrity protection almost for free. If we did it at the disk level, then we would be in the game of trying to make 2 disk writes appear atomic which would be a serious performance problem. On the other hand Thor Lancelot Simon made an interesting suggestion recently, which was one could reformat the underlying disk to have 522 byte blocks but have CGD present 512 byte blocks to the layers above it and still maintain the appropriate atomicity while gaining a 160 bit HMAC for each block. I think that the integrity checking has a more limited threat model, namely only removable media (for NetBSD, at least). If someone is able to steal my laptop and return it, they could just bug the keyboard much more quickly than figure out how to change my encrypted partitions in a non-obvious way. Or they could circumvent the boot blocks, reflash the BIOS, etc. etc. So, I think that this only matters for media which is more likely to pass out of my direct control than my laptop---or as in the article NAS/SAN architectures, where the storage is not nec. coresident with the computer. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 02:40:44 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF82A16A4CF for ; Wed, 2 Mar 2005 02:40:44 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32F6F43D1D for ; Wed, 2 Mar 2005 02:40:44 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 8533D7A403; Tue, 1 Mar 2005 18:40:43 -0800 (PST) Message-ID: <422527AB.1020302@elischer.org> Date: Tue, 01 Mar 2005 18:40:43 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= References: <001a01c51d6d$d50ce500$abe243a4@ash> <4222D5A2.9010301@elischer.org> <641e6aa9050301112016d316bb@mail.gmail.com> <4224C74A.2030205@elischer.org> <4224DB61.3060704@jonny.eng.br> In-Reply-To: <4224DB61.3060704@jonny.eng.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-hackers@freebsd.org cc: Sarath Kamisetty cc: Ashwin Chandra Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 02:40:44 -0000 Jo鉶 Carlos Mendes Lu韘 wrote: > Julian Elischer wrote: > >> Sarath Kamisetty wrote: >> >>> Hi, >>> >>> How does Linux handle this ? Any idea ? >> >> >> If you make 1000 threads, you get 1000 slots on the scheduler. (last >> time I looked.. >> Let me know if I'm wrong). >> >> The guy next to you with 'vi' gets 1 slot.. >> who gets more cpu? > > > And how is that different from forking 1000 processes and use > shared memory to communicate? I'll tell you: the thread option will > be better for every user in that machine, so let's promote threads. It's not different, but in that schenario there is no way the programmer can AVOID being nasty. with process scope threads as mentioned before the process itself is limitted so that iti doesn't unfairly peanalise other users for not using threads. > > IMHO, a thread should have the same privilege as a full processes, > and it should count as a process for resource limits. > >> >> >> >>> Thanks, >>> Sarat >>> >>> On Mon, 28 Feb 2005 00:26:10 -0800, Julian Elischer >>> wrote: >>> >>> >>>> Ashwin Chandra wrote: >>>> >>>> >>>>> I wanted to get some clarification about the 4BSD scheduler. I am >>>>> sort of >>>>> confused why there are two forms of scheduling, one done between >>>>> processes and >>>>> another done between threads in a process. The priority >>>>> calculations seem to be >>>>> done only with processes and I assume that the global run queue >>>>> holds processes, >>>>> not threads. Also why is there only 1 run queue for 1 CPU. What >>>>> happens to >>>>> blocked processes and ready to be runned processes? >>>>> >>>> >>>> >>>> Part of the challenge of adding threads to a system is to make it >>>> hard for a >>>> threaded process to "flood" the system run queues so that other >>>> processes >>>> get no cpu time. >>>> >>>> The scheme in the current freeBSD schedulers is a "crude" method, >>>> by which >>>> only a limitted number of threads per process are allowed to be >>>> added to >>>> the system run queue. RUnnable hreads fo r aprocess are kept on a >>>> run queue for >>>> the process and only the highest N prioriy hreads are actually put >>>> on the >>>> system run queue. >>>> >>>> This is by no means the best way, but rather the >>>> easiest way. I am hoping that some PhD candidate somewhere will decide >>>> that thread scheduling is his topic and will figure out a better way >>>> of doing this. >>>> >>>> both run queues hold threads. This is still a place wjere a lot >>>> of work can be done. >>>> >>>> :-) >>>> >>>> >>>> >>>> >>>>> Ash >>>>> _______________________________________________ >>>>> freebsd-hackers@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>>> To unsubscribe, send any mail to >>>>> "freebsd-hackers-unsubscribe@freebsd.org" >>>>> >>>> >>>> >>>> _______________________________________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> To unsubscribe, send any mail to >>>> "freebsd-hackers-unsubscribe@freebsd.org" >>>> >>>> >>> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 04:31:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA39C16A4CE; Wed, 2 Mar 2005 04:31:06 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0130843D2F; Wed, 2 Mar 2005 04:31:06 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j224X7ZD003761; Tue, 1 Mar 2005 21:33:08 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <42254106.8070006@samsco.org> Date: Tue, 01 Mar 2005 21:28:54 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Yeske References: <20050301175414.29170.qmail@web31007.mail.mud.yahoo.com> In-Reply-To: <20050301175414.29170.qmail@web31007.mail.mud.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: hackers@freebsd.org cc: re@freebsd.org cc: current@freebsd.org Subject: Re: smbfs install option for sysinstall X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 04:31:06 -0000 David Yeske wrote: > I modified the installer a while back to be able to install from a smb share. > It needs a little work though. I'm looking for some feedback although I have > tested it recently. I have done a recent install from a Windows XP machine > joined to a domain using a share that had domain admin credentials. > > http://futurebsd.sourceforge.net/freebsd/smbfs/ > > Here are a couple of issues that should be fixed. > > 1. I am not sure how to get the smbfs kernel support into the installer without > also putting it into the GENERIC kernel of the release. Probably not a big deal, unless it presents a security risk by default. I don't know enough about smbfs to say. > > 2. If a user uses is prompted for a password, then the output will make > sysinstall look kinda funny, although the user can enter the password properly. > There is probably a way to intercept the stdin and stdout of mount_smbfs and > have it display in a menu? This should work similar to the root password > change option? Probably easiest to do it this way. Sysinstall isn't pretty, but making it uglier with misformatted dialogs isn't good either. > > 3. This may add too much space to the floppy installer? No longer a problem now that the splitfs support is in. > > 4. The English used in the menus could be better. > > Regards, > David Yeske > Scott From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 10:14:32 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A72816A4CE for ; Wed, 2 Mar 2005 10:14:32 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 514CC43D3F for ; Wed, 2 Mar 2005 10:14:31 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j22AEUn0067877 for ; Wed, 2 Mar 2005 11:14:30 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: hackers@freebsd.org From: Poul-Henning Kamp Date: Wed, 02 Mar 2005 11:14:30 +0100 Message-ID: <67876.1109758470@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 10:14:32 -0000 I'm not regularly reading hackers these days, but I was pointed to the amazing FUD being spread here. Please keep me in the Cc: if you want me to see your replies. The fact that the CGD author(s) engage in this FUD spreading in random mailing lists rather than contact me directly speaks speaks for itself, but here are my replies to some of the points raised: If an attacker decides to attack a GBDE encrypted disk by brute-forcing all the sectors he might have a theoretically very simple task of on average 2^128 * Nsect work. Right now 2^128 is considered a safe workload for brute force, but that is assuming that the algorithms stand up to analytical attack. But the devil is in the detail, and the detail in this case is knowing that you had a hit. The biggest problem in brute-force attacks is very often to _know_ that you had a hit. The actual crypto operations can be put in silicon, but the practical hit-recognition is usually too complex for hardware. A brute force attack will produce 2^128 possible sector contents and the attacker has no way of _knowing_ that he found the right contents until he has checked if the hit is consistent with the rest of his hits and the GBDE key schedule. A brute force attack on a single sector in a trivial disk encryption like CGD will reveal the key for all of the disk and you can very fast verify that you got it right. The fact that filesystems contains highly structured data like superblocks and bitmaps makes this sensitive to almost any kind of weakness in the chipher. A brute force attack on a single sector in GBDE gives that sector and nothing which you can use the rest of the sectors with because the key is PRNG, one-time use for each sector. GBDE is written so there is no two-side leverage on any protocol involved. This means that if a weak key is discovered or if one of the algorithms has a major glaring hole of some kind, breaking one single sector does not reveal any other sectors. GBDE is probably slight overkill in this respect, but the other extreeme, encrypting the entire disk with the same key (as CGD) is very vulnerable to any kind of weakness in the ciphers: On a contemporary disk that approach offers 80.000.000 differential data points. No sane persone should ever encrypt 80.000.000 piece of data with the same key: A one bit chip in the armour of the cipher cuts 26 bits off the key. CGD even uses the key twice (a BIG no-no if I ever learned anything) so they may loose much more. The claim that: "It is also structured in such a way that substantial breakthroughs in the cracking of many different encryption algorithms, hashes and random number generators will bring the house of cards down." Sounds very interesting and I am very much looking forward to, but not seriously expecting ever to, read a substantiation of this claim. (Notice that I made the margin wider here to make sure they don't run out of space :-) As for the encryption algorithms being changeable, GBDE can be used with any cipher and hash you care for. True, at this point it would require a source code change, but it is not "impossible" as claimed. If somebody wants an AES256 bit version of GBDE it wouldn't take an hour to make the necessary changes. The choices of algorithm I made were guided by which algorithms had the best legal standing. It is no use that I think that algorithm FOO is better if all the users of GBDE is bound by a legal requirement for AES. Right now everything I have seen in the real world demands AES128. The claim that CGD can change the passphrase without reencrypting they entire disk falls flat on its face: One cannot seriously claim to have changed the passphrase if the 256 bit key used for the entire disk remains constant. The static master key needs to be at least 1024 bits to satisfy the contemporary security policies I have been given access to. With respect to the dictionary attack. The _real_ key of GBDE is either 512 bits (changeable, for each of the four keys) or 2176 bits static, depending on where you decide to attack. I have not heard of any realistic dictionary attacks of that size, mostly due to shortage of atoms in the universe. Now, currently the 512 bits are derived by running whatever the user provides through SHA2, and if the user provides "password", then a dictionary attack is indeed very feasible. That, however, is not a problem in GBDE, that is a problem in the users key-handling. A very crucial design decision was that I did not want to impose a particular kind of key-management on users of GBDE. Some people want to use smartcards, some wants to split the the key between multiple persons, across multiple locations or multiple media. Some people use PGP/GPG for password management, other people use signed CERTS. PKCS5 can obviously be used too. GBDE allows any and all of these, by simply requring the production of a repeatable bytestring of user selected length. Users so far seem to appreciate this flexibility. All the talk about what happens during a powerfail/crash is rather uninformed: On any contemporary filesystem you will loose data, encrypted or not, if the system crashes before you have a zero return value from fsync(2). If fsync(2) completed successfully, your data is safe on the disk, both with GBDE and CGD. Adding journaling or before/after images to the disk encryption is totally the wrong way to address this problem since all your filesystems and disk device drivers suffer from the same issue. (Adding journaling to your disk encryption has merits for other reasons as it effectively obscures the write access pattern, but the cost in performance and fragility of doing sector renames is prohibitive IMO). Finally, Yes, I will agree that GBDE takes a performance hit to implement the PRNG single-use sector keys, but in practice that hit is barely noticeable and the benefits it brings in cryptographic strength can not be obtained in any cheaper way. There are a lot of things GBDE doesn't try to protect against: illicit modification of disks (If people can modify your disk without you knowing about it, how do you know they did not also modify your other hardware ?) protection of running computers (This is an entirely different ball game). manipulation of entropy/randomness (If the attacker has this level of control over your computer, don't you think you have other problems which are more pressing ?) The goal of GBDE was to write a trustworthy protection for cold disks which also can protect the user and which can be used in practice in real world organizations. All reviews I have heard so far say that this goal was attained. Several people have done detailed reviews for their respective organizations, and none have yet to find anything wrong with GBDE. Unfortunately, most people in this business seems to be very keen on having their names not mentioned, so so far I think only Lucky Green and David Wagner have stood by their opinion with their name. I personally cherish this judgement from a government employed analyst: "It is refreshingly clear that it is just over the dotted line into over-kill, yet simple enough that any theory about loopholes can be disposed with instantly. Nobody will have any doubt that the pass-phrase is the only viable access path". I personally find that the keyhandling is the only bit of CGD with any real merits, what they do to the actual data on the disk appears to be a mere afterthought to their work on key management. Since I will not deny that the keyhandling is probably at little too much left in the hands of the user in GBDE, it is obvious that it would benefit boths parties to make the CGD key handling an option for GBDE. So how about it guys: Instead of spreading FUD, lets work together and make the world an even better place ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 11:32:50 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AFFC16A4CE for ; Wed, 2 Mar 2005 11:32:50 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id B627943D2F for ; Wed, 2 Mar 2005 11:32:49 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j21FbioH055697; Tue, 1 Mar 2005 07:37:45 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j21FbcmA055696; Tue, 1 Mar 2005 07:37:38 -0800 (PST) (envelope-from www) Date: Tue, 1 Mar 2005 07:37:38 -0800 (PST) Message-Id: <200503011537.j21FbcmA055696@marlena.vvi.at> To: phk@phk.freebsd.dk From: "ALeine" cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 11:32:50 -0000 phk@phk.freebsd.dk wrote: > The fact that the CGD author(s) engage in this FUD spreading in > random mailing lists rather than contact me directly speaks > speaks for itself, but here are my replies to some of the points raised: Obviously this is a part of some aggressive NetBSD advocacy campaign that was started just recently, I find it hard to believe that someone just happened to find my original RFC on backporting GEOM to 4.x from like a month ago and then decided to revive the thread. Someone was looking for something recent about GBDE they could claw into. Anyone who has read recent posts by Chritos Zoulas can see the pattern, this seems to be an organized effort not so much pro NetBSD but anti other BSDs. There is really no need for that kind of campaigning, it gives a bad name to all BSDs. All software has some merit, just state the facts and let the users decide what they want. I agree with you on almost all the other points you addressed (journaling being an exception - I would make it optional, not mandatory) as I have stated pretty much the same things myself in my previous posts, so I will not further comment on that, but I would like to ask your opinion on the matters I raised about introducing the following changes to GBDE: 1. Introducing a sysctl variable to control how often (after how many writes) the random key is regenerated: kern.geom.bde.random_key_regeneration_cycle The way it works now would correspond to the value being 1 with regeneration happening on every write. Setting this higher would improve the performance and people could decide for themselves what value fits their needs. 2. Backporting to 4.x - this has more or less come to the point that I would rather write the whole thing from scratch, similar to vncrypt (ports/security/vncrypt), only implementing the main principles found in GBDE. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 11:40:46 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1166B16A4CE for ; Wed, 2 Mar 2005 11:40:46 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 359CC43D1D for ; Wed, 2 Mar 2005 11:40:45 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j22BeeWl069009; Wed, 2 Mar 2005 12:40:40 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "ALeine" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 01 Mar 2005 07:37:38 PST." <200503011537.j21FbcmA055696@marlena.vvi.at> Date: Wed, 02 Mar 2005 12:40:40 +0100 Message-ID: <69008.1109763640@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 11:40:46 -0000 In message <200503011537.j21FbcmA055696@marlena.vvi.at>, "ALeine" writes: >1. Introducing a sysctl variable to control how often (after how many writes) >the random key is regenerated: > >kern.geom.bde.random_key_regeneration_cycle > >The way it works now would correspond to the value being 1 with >regeneration happening on every write. Setting this higher would >improve the performance and people could decide for themselves >what value fits their needs. I don't really think you would gain any performance, but I am open to benchmarks proving me wrong. >2. Backporting to 4.x - this has more or less come to the point that >I would rather write the whole thing from scratch, similar to vncrypt >(ports/security/vncrypt), only implementing the main principles found >in GBDE. I wouldn't bother. 4.x is nearing the EOL and you wouldn't get much useful lifetime out of it. It wouldn't be too much work to do it however. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 22:15:16 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAC7316A4CE for ; Tue, 1 Mar 2005 22:15:15 +0000 (GMT) Received: from machshav.com (machshav.com [147.28.0.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 839FA43D39 for ; Tue, 1 Mar 2005 22:15:15 +0000 (GMT) (envelope-from smb@cs.columbia.edu) Received: by machshav.com (Postfix, from userid 512) id 05E9FFB27D; Tue, 1 Mar 2005 17:15:15 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AB028FB24A; Tue, 1 Mar 2005 17:15:13 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 3423C3C023E; Tue, 1 Mar 2005 17:15:11 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "ALeine" In-Reply-To: Your message of "Mon, 28 Feb 2005 17:45:15 PST." <200503010145.j211jF1s046188@marlena.vvi.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Mar 2005 17:15:11 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050301221511.3423C3C023E@berkshire.machshav.com> X-Mailman-Approved-At: Wed, 02 Mar 2005 13:33:25 +0000 cc: freebsd-hackers@freebsd.org cc: elric@imrryr.org cc: kernel@crater.dragonflybsd.org cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 22:15:16 -0000 In message <200503010145.j211jF1s046188@marlena.vvi.at>, "ALeine" writes: > >I find using a single key for the whole disk less secure and not >very practical when one wants to change the key because it takes >a very long time to re-encrypt the entire disk. However, having >a separate per-sector key which is changed on every write seems >to go too far in the opposite direction, so IMHO the best solution >would be to use the same key for a definable number of sectors >(set at initialization) and then having a sysctl variable to >control after how many writes you want the key changed. This >would speed things up quite a bit and users would be allowed to >decide how much assumed security they are willing to sacrifice for >noticable speed. This would also make it possible to implement my >key shadow sector idea without a performance penalty in comparison >to the current implementation of GBDE. > I confess that I still don't see the threat model here. What sort of cryptanalytic breakthrough would make this a requirement? I will state categorically that I know of no threat to AES that would be addressed by this, but wouldn't require replacing AES entirely. The canonical example is "encrypting too much data with the same key". That can be a real concern. With DES or 3DES (or any other cipher with a 64-bit blocksize), one should never encrypt more than 8*2^32 bytes -- about 32G -- with a single key if you're using CBC mode. The corresponding figure for AES is 16*2^64 -- a *much* larger number, and one well beyond any conceivable disk drive. Historically, there have been ciphers that were attackable with lots of traffic, but typically the issue was repetition of the key stream. That's not going to happen here. I leave as an exercise for the reader computing just how unlikely it is -- but it's *very* unlikely. Remember that we're dealing with 128-bit input blocks. It is, of course, conceivable that someone will find a way to use hundreds of gigabytes of data encrypted with one key to find some shortcut attack on AES -- perhaps 2^112 trials instead of 2^128. Given the reaction in the cryptographic community to the SHA1 attack, which cuts the time to 2^69 from 2^80, I'm quite confident of what would happen: a replacement for AES. That said, if you were concerned there's a very simple solution: to encrypt block B with master key K, calculate some cryptographic function F(K, B) -- ECB encryption is the obvious choice -- and use that as the block key. Use F'(B) or F'(K, B) to get the per-block IV. Add any wrinkles you want, such as caching F and F' values, or having F apply to a range of blocks. I see no need to rekey the disk. I do see a need to change the user-specified key, but that can be handled by a layer of indirection. If there were some sort of compromise that made you want to rekey the entire disk, having per-block keys won't help; you still need to read, decrypt, re-encrypt, and rewrite each block, since any likely compromise scenario would involve compromise of the key block as well. There's a school of cryptographic design that tosses in mechanisms on the vague hunch that there's threat out there. Unless you understand the threats and the tradeoffs, though, you're likely to make matters worse, not better. Often, there is no perfect solution, but if you don't understand the *real* threats you'll make the wrong tradeoffs. It's worth noting that there is a very real threat not addressed here: detecting unauthorized changes to an encrypted disk. For a very elegant solution, see http://www.isoc.org/isoc/conferences/ndss/05/proceedings/papers/storageint.pdf --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 13:57:45 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DF7416A4CF for ; Wed, 2 Mar 2005 13:57:45 +0000 (GMT) Received: from freebsd.czest.pl (silver.iplus.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BF2143D60 for ; Wed, 2 Mar 2005 13:57:43 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id j22E3e9r040851 for ; Wed, 2 Mar 2005 14:03:40 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.12.10/8.12.9/Submit) id j22E3dOX040850 for freebsd-hackers@FreeBSD.org; Wed, 2 Mar 2005 14:03:39 GMT (envelope-from dunstan) Date: Wed, 2 Mar 2005 14:03:38 +0000 From: "Wojciech A. Koszek" To: freebsd-hackers@FreeBSD.org Message-ID: <20050302140338.GA40827@freebsd.czest.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: RFC: [conf/78257, PATCH] /etc/rc.d/memdisk for /dev/md* creation at startup X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 13:57:45 -0000 Hello hackers, Could you take a look at my PR which contains rc.d/ script for attaching memory disks managed with mdconfig(8) on system startup: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/78257 Comments are welcome. Best regards, -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 15:05:57 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 500A616A4DC; Wed, 2 Mar 2005 15:05:56 +0000 (GMT) Received: from magic.adaptec.com (magic.adaptec.com [216.52.22.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id C23DC43D3F; Wed, 2 Mar 2005 15:05:55 +0000 (GMT) (envelope-from Achim_Leubner@adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id j22F5tr09851; Wed, 2 Mar 2005 07:05:55 -0800 Received: from nkse2k01.adaptec.com (nkse2k01.adaptec.com [172.28.193.32]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id j22F5sb00320; Wed, 2 Mar 2005 07:05:54 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 2 Mar 2005 16:05:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Remote kernel debugging using GDB Thread-Index: AcUfOVPlIC5DY8/BQ8eNZWbIqOaxLg== From: "Leubner, Achim" To: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Remote kernel debugging using GDB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 15:05:58 -0000 Hello all, =20 I want to do some remote kernel debugging using GDB on FreeBSD 5.3.=20 I connected host and target with a null-modem cable on COM1 and made a = debug kernel with "options GDB", "options DDB", "options KDB" and = "makeoptions DEBUG=3D-g" and I set the port flags of sio0 to 0x80. But if I start the debug kernel on the target machine with "boot -d" I = always get the message "GDB: no debug ports present" and if I want to = start GDB I get "The remote GDB backend could not be selected". In = "debug.kdb.available" I only see the ddb and "sysctl -w = debug.kdb.current=3Dgdb" fails. Does anybody know what=B4s going wrong here? Any help is greatly = appreciated. =20 Thanks, Achim Leubner ICP vortex GmbH / Adaptec Inc. Phone: +49-351-8718291 =20 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 15:38:40 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36A0016A4CE for ; Wed, 2 Mar 2005 15:38:40 +0000 (GMT) Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.128.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7CE943D39 for ; Wed, 2 Mar 2005 15:38:39 +0000 (GMT) (envelope-from yanyu@CS.UCLA.EDU) Received: from localhost (yanyu@localhost)j22Fcbo22316 for ; Wed, 2 Mar 2005 07:38:37 -0800 (PST) Date: Wed, 2 Mar 2005 07:38:37 -0800 (PST) From: Yan Yu To: freebsd-hackers@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: kernel core dump X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 15:38:40 -0000 Hi, I have a Q on generating kernel core dump when the system boots up.. my kernel crashes when it tries to mount the root device, "/", i.e., before it adding the swap device to the system (so there is no swap device when the system tries to generate core dump).. I am wondering is there a way to adjust this boot order, so that the system will add swap device before it mounting the root device, so hopefully the swap device is there when the kernel crashes.. Is yes, what change i should made to change that boot order? many thanks, yan From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 16:29:49 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5581A16A4CE for ; Wed, 2 Mar 2005 16:29:49 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81C9143D3F for ; Wed, 2 Mar 2005 16:29:48 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id 0916237012; Wed, 2 Mar 2005 11:29:28 -0500 (EST) To: Poul-Henning Kamp In-reply-to: Your message of "Wed, 02 Mar 2005 11:14:30 +0100." <67876.1109758470@critter.freebsd.dk> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Wed, 02 Mar 2005 11:29:28 -0500 From: Roland Dowdeswell Message-Id: <20050302162928.0916237012@arioch.imrryr.org> cc: tech-security@NetBSD.org cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 16:29:49 -0000 On 1109758470 seconds since the Beginning of the UNIX epoch Poul-Henning Kamp wrote: > >So how about it guys: Instead of spreading FUD, lets work together >and make the world an even better place ? I am hoping that the discussion will yield infomation that will allow each of us to improve our respective systems. I shall respond to the points out of order. >All the talk about what happens during a powerfail/crash is rather >uninformed: On any contemporary filesystem you will loose data, >encrypted or not, if the system crashes before you have a zero >return value from fsync(2). If fsync(2) completed successfully, >your data is safe on the disk, both with GBDE and CGD. Adding >journaling or before/after images to the disk encryption is totally >the wrong way to address this problem since all your filesystems >and disk device drivers suffer from the same issue. Let's discuss a simple example and see how it works. Let's walk through a user login, with /etc/passwd on GBDE and the filesystem mounted with mtime. Now: 1. A user logs in, /etc/passwd is consulted, 2. mtime of /etc/passwd is updated, 3. the file system over GBDE at some point decides to rewrite /etc/passwd's inode, 4. a new key is randomly generated for the inode sector, 5. the key-key sector is regenerated and written, and 6. the newly encrypted inode sector is written. Now, if the power is cut or the operating system crashes between steps 5 and 6, you have now lost the inode for /etc/passwd (and a few more files). Contemporary filesystems generally do not lose data when a file is read. But, unless there is some logic under GBDE or in FFS which I have failed to see, this is possible with FFS over GBDE. This has nothing to do with the semantics that fsync(2) guarantees. It is a matter of the atomicity assumptions that the filesystem expects a disk (or pseudo disk) to provide, and as I stated earlier the requirement is that if the sector contains A and I try to write A' then after a crash the sector will contain either A or A' but not A''---the decryption of A with the A' key. Now, what about GBDE or FFS makes this situation impossible? >With respect to the dictionary attack. The _real_ key of GBDE is >either 512 bits (changeable, for each of the four keys) or 2176 >bits static, depending on where you decide to attack. I have not >heard of any realistic dictionary attacks of that size, mostly due >to shortage of atoms in the universe. > >Now, currently the 512 bits are derived by running whatever the >user provides through SHA2, and if the user provides "password", >then a dictionary attack is indeed very feasible. > >That, however, is not a problem in GBDE, that is a problem in >the users key-handling. A dictionary attack refers specifically to the process of guessing passphrases. It is not a generic brute force attack on the whole key space, and it uses the fact that passphrases have substantially weaker security properties than random bags of bits. Under the assumption that my USB dongle is generally an average of 20 feet from my laptop (because I take both of them with me most places), I normally have to assume that the 2-factor authentication that I use will help but the system _must_ be secure in the face of compromise of both the dongle and the laptop. With that in mind, the attacker will simply guess passphrases using reasonably well known and reasonably effective techniques of generating the kinds of passphrases that people use. Given that the human memory is not expanding at nearly the same rate as computer processing power, something needs to be done about this vector. It is all well and good for both of us to talk about 2^256 and 2^2176 and 2^128 * 2^30, etc. But, a dictionary attack is likely to be a lot closer to 2^35 or 2^40. This is, I think, in the general use case the real threat. It is the low hanging fruit. With GBDE, the dictionary attack can be performed half offline because the SHA2/512 is not salted. And, after you get to the online portion, it basically comes down to a simple AES setkey and encrypt to verify whether the passphrase is valid. My laptop can perform abut 100k of these operations per second (if it is plugged into the wall) and it is not exactly a fast computer. That means that I can run through about 2^30 guesses in 2.5 hours. This will obtain naive user's passphrases within the first few days. More savvy users may take a bit longer, but it is all within the realm of the very possible without any advances in cryptography---unlike cracking CGD' AES256 or GEOM's AES128 on the sectors. >The claim that CGD can change the passphrase without reencrypting >they entire disk falls flat on its face: One cannot seriously claim >to have changed the passphrase if the 256 bit key used for the >entire disk remains constant. The static master key needs to be >at least 1024 bits to satisfy the contemporary security policies I >have been given access to. Actually, given your statements the claim does not fall flat on its face. It just does not meet the requirement that the key is at least 1024 bits. Those appear to me to be different statements. GBDE does not actually change its salt/master key when the passphrase is changed, so the systems are equivalent from the perspective of how they change passphrases. The only exception is that GBDE has a longer key. With GBDE the keys used to encrypt each of the key-key sectors remain static. So, like CGD there is no effective way to revoke access to the disk from wily and intelligent insiders who at some point had access to the disk, except by re-encrypting the whole thing. With both systems, the `master key' remains static and hence if you can calculate it once you have it. While we are at it, I do not believe that having a key that is larger than 1024 bits necessarily guarantees that the effort required to crack it is commensurate with its size. E.g. given the bit-blender approach of GBDE [from 7.4 of your paper], if you know the salt then you can use a divide-and-conquer strategy to tease the master key out in a ``reasonably short'' time. Less than 2^128 steps certainly, if I look at things correctly. Which means that if you do not have the salt then to brute force both you need to put in an effort equivalent to less than 2^128 * 2^128 = 2^256. Which seems to me to indicate that there is less than 2^256 of `effective' key material. >If an attacker decides to attack a GBDE encrypted disk by brute-forcing >all the sectors he might have a theoretically very simple task of >on average 2^128 * Nsect work. > >Right now 2^128 is considered a safe workload for brute force, but >that is assuming that the algorithms stand up to analytical attack. > >But the devil is in the detail, and the detail in this case is >knowing that you had a hit. > >The biggest problem in brute-force attacks is very often to _know_ >that you had a hit. The actual crypto operations can be put in >silicon, but the practical hit-recognition is usually too complex >for hardware. > >A brute force attack will produce 2^128 possible sector contents >and the attacker has no way of _knowing_ that he found the right >contents until he has checked if the hit is consistent with the >rest of his hits and the GBDE key schedule. Knowing that you had a hit is substantially easier than you claim. Filesystems are quite well structured and attackers are generally looking for specific information which is quite well structured. So, if I were attacking GBDE, what I would do would be to look for the superblock which is ~trivial to recognise and then walk down the directory chain until I found the files/directories that I want. Again, most of this is quite recognisable. Eventually, I would get to the file(s) that I wanted to see. These are probably reasonably well structured as well. Now, I would be trying to crack key-key sectors, so I can correlate 32 different sectors at a time---so I think that there's a very good chance that I would have enough information at hand to verify the results in a programatic way. >The claim that: > "It is also structured in such a way that substantial > breakthroughs in the cracking of many different encryption > algorithms, hashes and random number generators will bring > the house of cards down." > >Sounds very interesting and I am very >much looking forward to, but not >seriously expecting ever to, read a >substantiation of this claim. (Notice >that I made the margin wider here to >make sure they don't run out of space >:-) If a breakthrough makes AES128 very easy to crack, then you can just crack the sectors individually, ignoring the rest of the system. If the results of Yarrow are found to be predictable, then guessing the sector keys becomes much easier. So, there are two algorithms that will individually make cracking the disk substantially easier independently. If md5 is found to have predictable output then guessing the key for the key-key sectors becomes easier. Depending on how the predictabity manifests itself it could make a crack a lot easier. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 16:55:50 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90B8416A4CE for ; Wed, 2 Mar 2005 16:55:50 +0000 (GMT) Received: from mail.foolishgames.com (mail.foolishgames.com [216.55.178.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53EEF43D39 for ; Wed, 2 Mar 2005 16:55:50 +0000 (GMT) (envelope-from luke@foolishgames.com) Received: from [192.168.0.49] (24.247.120.6.kzo.mi.chartermi.net [24.247.120.6]) (authenticated bits=0)j22GtdXH035718 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 2 Mar 2005 08:55:40 -0800 (PST) (envelope-from luke@foolishgames.com) X-Authentication-Warning: mail.foolishgames.com: Host 24.247.120.6.kzo.mi.chartermi.net [24.247.120.6] claimed to be [192.168.0.49] Message-Id: X-Habeas-Swe-6: email in exchange for a license for this Habeas X-Habeas-Swe-3: like Habeas SWE (tm) Date: Tue, 1 Mar 2005 16:05:08 -0500 X-Habeas-Swe-8: Message (HCM) and not spam. Please report use of this From: Lucas Holt X-Habeas-Swe-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-Swe-2: brightly anticipated In-Reply-To: <4224C74A.2030205@elischer.org> References: <001a01c51d6d$d50ce500$abe243a4@ash> <4222D5A2.9010301@elischer.org> <641e6aa9050301112016d316bb@mail.gmail.com> <4224C74A.2030205@elischer.org> To: Julian Elischer X-Habeas-Swe-7: warrant mark warrants that this is a Habeas Compliant Mime-Version: 1.0 (Apple Message framework v619.2) X-Habeas-Swe-4: Copyright 2002 Habeas (tm) Content-Type: text/plain; charset=US-ASCII; format=flowed X-Habeas-Swe-1: winter into spring Content-Transfer-Encoding: 7bit X-Habeas-Swe-9: mark in spam to . X-Mailer: Apple Mail (2.619.2) cc: freebsd-hackers@freebsd.org cc: Sarath Kamisetty cc: Ashwin Chandra Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 16:55:50 -0000 Wouldn't a multi threaded program potentially need more cpu time than vi? Multithreaded apps are created to do a lot of computation or because they have a lot of concurrent activity that might block right? On Mar 1, 2005, at 2:49 PM, Julian Elischer wrote: >> > > If you make 1000 threads, you get 1000 slots on the scheduler. (last > time I looked.. > Let me know if I'm wrong). > > The guy next to you with 'vi' gets 1 slot.. > who gets more cpu? > Lucas Holt Luke@FoolishGames.com ________________________________________________________ FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) FoolishGames.net (Enemy Territory IoM site) From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 17:26:00 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCAD016A4CE for ; Wed, 2 Mar 2005 17:26:00 +0000 (GMT) Received: from web52702.mail.yahoo.com (web52702.mail.yahoo.com [206.190.39.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 5F0F643D1D for ; Wed, 2 Mar 2005 17:26:00 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 99966 invoked by uid 60001); 2 Mar 2005 17:25:59 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=yQje6EQbwxsPAb+ju6x3GwBioE2L92oS3qcjudpUQ+WqJGwnHG5R7WlSGkVV7Es1z96WMbipP3PyVkVa8tYSbh9QtGoTDaB6V9pFU2zseK6VDHh815j2g+837wzt+BSQrXOciHHDiFrWf25z1eMipNGoBk/4qwobhDwcKFgPXxw= ; Message-ID: <20050302172559.99964.qmail@web52702.mail.yahoo.com> Received: from [202.91.78.244] by web52702.mail.yahoo.com via HTTP; Wed, 02 Mar 2005 09:25:59 PST Date: Wed, 2 Mar 2005 09:25:59 -0800 (PST) From: "Kamal R. Prasad" To: Lucas Holt , Julian Elischer In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-hackers@freebsd.org Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kamalp@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 17:26:01 -0000 --- Lucas Holt wrote: > Wouldn't a multi threaded program potentially need > more cpu time than > vi? No. That is not a given. > Multithreaded apps are created to do a lot of > computation or > because they have a lot of concurrent activity that > might block right? > Threads are meant to take advantage of concurrency. Maybe the freebsd implementation should implement NPTL in entirety. > > On Mar 1, 2005, at 2:49 PM, Julian Elischer wrote: > >> > > > > If you make 1000 threads, you get 1000 slots on > the scheduler. (last > > time I looked.. > > Let me know if I'm wrong). > > depends on whether it is defined to execute in system scope or not. regards -kamal ===== ------------------------------------------------------------ Kamal R. Prasad UNIX systems consultant kamalp@acm.org In theory, there is no difference between theory and practice. In practice, there is:-). ------------------------------------------------------------ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 17:27:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0276416A4CE; Wed, 2 Mar 2005 17:27:42 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 143AA43D31; Wed, 2 Mar 2005 17:27:41 +0000 (GMT) (envelope-from igor@doom.homeunix.org) Received: from dialup84109-13.ip.peterstar.net ([84.204.109.13] helo=doom.homeunix.org) by voodoo.oberon.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1D6XdF-000DyM-7n; Wed, 02 Mar 2005 18:27:35 +0100 Received: from doom.homeunix.org (localhost [127.0.0.1]) by doom.homeunix.org (8.13.3/8.13.3) with ESMTP id j22HPPUx000671; Wed, 2 Mar 2005 20:25:25 +0300 (MSK) (envelope-from igor@doom.homeunix.org) Received: (from igor@localhost) by doom.homeunix.org (8.13.3/8.13.3/Submit) id j21JkUcj000988; Tue, 1 Mar 2005 22:46:30 +0300 (MSK) (envelope-from igor) Date: Tue, 1 Mar 2005 22:46:29 +0300 From: Igor Pokrovsky To: Cole Message-ID: <20050301194629.GA948@doom.homeunix.org> Mail-Followup-To: Cole , freebsd-hackers@freebsd.org, freebsd-net@freebsd.org References: <003101c51ddf$347fa420$4206000a@deadmind> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003101c51ddf$347fa420$4206000a@deadmind> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Dynamically Linked Library Problem (maybe) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 17:27:42 -0000 On Mon, Feb 28, 2005 at 11:48:14PM +0200, Cole wrote: > Hey. > > I have a Freebsd server running freebsd-4.9-stable. > I cvsupped the ntop src last week for 3.1.1. > > I then had no problems what so ever building ntop, except for the xml plugin saying it was not built, cause it cannot find > xmlversion.h, even though I have libxml installed, and specified the right paths to the .h. But that is not the problem. > Ntop runs and works fine on this box, not a single problem that I can see. > > The problem is that, I have a few other servers, that I want to copy ntop too, but dont want to build it on all those boxes. I > created a tar with all the ntop binaries, as well as all the libraries that its linked too, as well as all the plugins that ntop > uses from both the /usr/local/lib directory as well as the plugins from the /usr/local/lib/ntop/plugins directory. I rebuilt all the > symbolic links for all the libraries and plugins and all the files that ntop was linked too. I have also checked all the permissions > on all the files and they are all the same. > > One other thing, the boxes that I am copying ntop to, are almost exact duplicates of the first box that I built ntop on, and where > it works fine. > > The problem is, when running ntop on the boxes that I copied it to, after checking all the permissions and links and everything, I > get these errors with regards to the plugins. > > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/icmpPlugin.so' entry function [Invalid > shared object handle 0x29a14000] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/snmpPlugin.so' entry function [Invalid > shared object handle 0x29a16400] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/sflowPlugin.so' entry function [Invalid > shared object handle 0x29a19800] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/rrdPlugin.so' entry function [Invalid > shared object handle 0x29a1bc00] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/pdaPlugin.so' entry function [Invalid > shared object handle 0x2bcae400] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/netflowPlugin.so' entry function [Invalid > shared object handle 0x2d862800] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/lastSeenPlugin.so' entry function > [Invalid shared object handle 0x2d866c00] > Tue Mar 1 05:37:16 2005 **WARNING** Unable to locate plugin '/usr/local/lib/ntop/plugins/xmldumpPlugin.so' entry function [Invalid > shared object handle 0x2f697000] > > I have absolutely no idea how this has happened, and I have had this problem before, and not a single other person was able to help > me in any regards what so ever. I was hoping maybe someone would at least know what this error even means, so that I have some idea > of what I am meant to be doing to fix this. > > If anyone has any idea, I would gladly apprecaite any suggestions. It seems to me error messages mean one thing - those plugins were corrupted in some way. It is also not clear from your message - are you using net/ntop from ports tree or you are building it from sources manually? In case of problems when building from a port you'd better ping port maintainer. -ip -- You are never given enough time or money. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 18:46:41 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C7A116A4CE for ; Wed, 2 Mar 2005 18:46:41 +0000 (GMT) Received: from mxsf10.cluster1.charter.net (mxsf10.cluster1.charter.net [209.225.28.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E59B43D46 for ; Wed, 2 Mar 2005 18:46:41 +0000 (GMT) (envelope-from c0ldbyte@myrealbox.com) Received: from mxip02.cluster1.charter.net (mxip02a.cluster1.charter.net [209.225.28.132])j22Ike9x001409 for ; Wed, 2 Mar 2005 13:46:40 -0500 Received: from 24.247.253.134.gha.mi.chartermi.net (HELO eleanor.us1.wmi.uvac.net) (24.247.253.134) by mxip02.cluster1.charter.net with ESMTP; 02 Mar 2005 13:46:39 -0500 X-Ironport-AV: i="3.90,130,1107752400"; d="scan'208"; a="642676715:sNHT3930803830" Date: Wed, 2 Mar 2005 13:46:38 -0500 (EST) From: c0ldbyte To: Matt In-Reply-To: <4224CF06.7060103@comcast.net> Message-ID: <20050302134039.G7456@eleanor.us1.wmi.uvac.net> References: <4224CF06.7060103@comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: retricted environment X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 18:46:41 -0000 On Tue, 1 Mar 2005, Matt wrote: > When providing a shell environment for a larger number of users, what is the > best way to retrict access to commands/resources? I've already setup quotas. > I don't want users playing with system commands. I've read something about a > retricted shell, but can't find any details. Sorry if this is a little too late but your best bets are of (chmod,chown,chflags) also in (/etc/login.conf). Besides that it doesnt matter in a normal environment if a reg'd user messes with system commands, they wont beable to change anything with the system anyway and even if you didnt resitrict the commands that they can execute they just might report to syslog that the $UID was trying to use them and give you a heads up on trying to keep track of the user at hand. Best of luck: for more great info on FreeBSD and its options check out freebsd.org/handbook /faq and http://draenor.org/securebsd/secure.txt Best of luck --c0ldbyte This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 19:43:56 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46A4216A4CE for ; Wed, 2 Mar 2005 19:43:56 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFA0543D1F for ; Wed, 2 Mar 2005 19:43:54 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id A74B77A41E; Wed, 2 Mar 2005 11:43:54 -0800 (PST) Message-ID: <4226177A.4050607@elischer.org> Date: Wed, 02 Mar 2005 11:43:54 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Lucas Holt References: <001a01c51d6d$d50ce500$abe243a4@ash> <4222D5A2.9010301@elischer.org> <641e6aa9050301112016d316bb@mail.gmail.com> <4224C74A.2030205@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: Sarath Kamisetty cc: Ashwin Chandra Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 19:43:56 -0000 Lucas Holt wrote: > Wouldn't a multi threaded program potentially need more cpu time than > vi? Multithreaded apps are created to do a lot of computation or > because they have a lot of concurrent activity that might block right? Isn't that what nice is for? if (only) two processes are using all the cpu they can get, and one is written using 1000 threads, then why should it get 1000/1001 of the cpu? > > > On Mar 1, 2005, at 2:49 PM, Julian Elischer wrote: > >>> >> >> If you make 1000 threads, you get 1000 slots on the scheduler. (last >> time I looked.. >> Let me know if I'm wrong). >> >> The guy next to you with 'vi' gets 1 slot.. >> who gets more cpu? >> > > Lucas Holt > Luke@FoolishGames.com > ________________________________________________________ > FoolishGames.com (Jewel Fan Site) > JustJournal.com (Free blogging) > FoolishGames.net (Enemy Territory IoM site) From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 20:09:58 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFAE216A4CE for ; Wed, 2 Mar 2005 20:09:58 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB34B43D1F for ; Wed, 2 Mar 2005 20:09:58 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 04EE67A403; Wed, 2 Mar 2005 12:09:58 -0800 (PST) Message-ID: <42261D95.9020506@elischer.org> Date: Wed, 02 Mar 2005 12:09:57 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: kamalp@acm.org References: <20050302172559.99964.qmail@web52702.mail.yahoo.com> In-Reply-To: <20050302172559.99964.qmail@web52702.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: Lucas Holt Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 20:09:59 -0000 Kamal R. Prasad wrote: >--- Lucas Holt wrote: > > > >>Wouldn't a multi threaded program potentially need >>more cpu time than >>vi? >> >> > >No. That is not a given. > > > >>Multithreaded apps are created to do a lot of >>computation or >>because they have a lot of concurrent activity that >>might block right? >> >> >> >Threads are meant to take advantage of concurrency. >Maybe the freebsd implementation should implement NPTL >in entirety. > > NPTL? New Pthreads Library from Library? isn't that GPL'd? > > >>On Mar 1, 2005, at 2:49 PM, Julian Elischer wrote: >> >> >>>If you make 1000 threads, you get 1000 slots on >>> >>> >>the scheduler. (last >> >> >>>time I looked.. >>>Let me know if I'm wrong). >>> >>> >>> >depends on whether it is defined to execute in system >scope or not. > > I presume you have looked at it recently then.. I have not looked at the linux scheduler in a while.. how do they stop 100o threads from getting 1000 shots at the scheduler? >regards >-kamal > > >===== >------------------------------------------------------------ >Kamal R. Prasad >UNIX systems consultant >kamalp@acm.org > >In theory, there is no difference between theory and practice. In practice, there is:-). >------------------------------------------------------------ > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 21:21:02 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9366016A4CE for ; Wed, 2 Mar 2005 21:21:02 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60C4343D54 for ; Wed, 2 Mar 2005 21:21:02 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5B2385C9E0; Wed, 2 Mar 2005 13:21:02 -0800 (PST) Date: Wed, 2 Mar 2005 13:21:02 -0800 From: Alfred Perlstein To: hackers@freebsd.org Message-ID: <20050302212102.GK11079@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: truss bug + PATCH, pls review X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 21:21:02 -0000 Can someone review this? I think 'u' is incorrectly added to instead of assigned to. This causes the initial calculation to be garage based and screws up displaying poll information. I'd like this to be MFC'd before 5.4 if possible. Index: syscalls.c =================================================================== RCS file: /home/ncvs/src/usr.bin/truss/syscalls.c,v retrieving revision 1.45 diff -u -r1.45 syscalls.c --- syscalls.c 5 Sep 2004 05:27:30 -0000 1.45 +++ syscalls.c 2 Mar 2005 21:19:13 -0000 @@ -414,7 +414,7 @@ (POLLIN | POLLPRI | POLLOUT | POLLERR | POLLHUP | POLLNVAL | \ POLLRDNORM |POLLRDBAND | POLLWRBAND | POLLINIGNEOF) - u += snprintf(tmp + used, per_fd, + u = snprintf(tmp + used, per_fd, "%s%d 0x%hx%s%s%s%s%s%s%s%s%s ", i > 0 ? " " : "", pfd[i].fd, -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684 From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 00:30:20 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70E1A16A4CE for ; Thu, 3 Mar 2005 00:30:20 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C76F43D1F for ; Thu, 3 Mar 2005 00:30:19 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j230UFHf002760; Thu, 3 Mar 2005 01:30:17 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Roland Dowdeswell From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 02 Mar 2005 11:29:28 EST." <20050302162928.0916237012@arioch.imrryr.org> Date: Thu, 03 Mar 2005 01:30:15 +0100 Message-ID: <2759.1109809815@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@NetBSD.org cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 00:30:20 -0000 In message <20050302162928.0916237012@arioch.imrryr.org>, Roland Dowdeswell wri tes: >Let's discuss a simple example and see how it works. Let's walk >through a user login, with /etc/passwd on GBDE and the filesystem >mounted with mtime. These days, on the majority of low cost disks used in enduser configurations you risk looking an entire track if the disk were writing when you pulled power. (People complain about this, but doesn't seem to be willing to pay to avoid it.) So the cummulative increase of risk from using GBDE doesn't really register on the radar for people. And therein lies a very important lesson for you: It may not be a 100% theoretical ironclad guarantee, because few people are prepared to pay for that in the first place. >Contemporary filesystems generally do not lose data when a file is >read. ... unless they operate on contemporary products for data storage. >A dictionary attack refers specifically to the process of guessing >passphrases. As I said in so many words: GBDE does not in any way shape or form address this problem. GBDE provides a simple model for authentication on which many different key handing schemes, can be built. "There is no problems left in crypto research except key-handling", and I (or anybody else) would be very wrong if we claimed to have the Endl謘ung for that problem. The important feature in this situation is to be able to work with whatever keyhandling scheme the user (or administrator) wants to implement, not to ram our preference down their throat. >It is all well and good for both of us to talk about 2^256 and >2^2176 and 2^128 * 2^30, etc. But, a dictionary attack is likely >to be a lot closer to 2^35 or 2^40. This is, I think, in the >general use case the real threat. It is the low hanging fruit. Yes, absolutely. The difference between CGD and GBDE in this area is that for CGD it is not convincibly shown that it is the only feasible attack (because you use the same key for all sectors thus exposing the ciphers possible weaknesses big time), for GBDE everybody so far agrees that the key is the only feasible attack. >With GBDE, the dictionary attack can be performed half offline >because the SHA2/512 is not salted. Sure, but if the dictionary includes guessing the 1KB of random bits on my USB gadget, you are more than welcome to do so. If you as a user are worried about dictionary attacks, then you obviously will employ a key handling method which mitigates it. My preference is a storage gadget with a large slap of bits which are one part of the passphrase, other people have other preferences. GBDE supports them all. But there are also users who are rightly not worried about dictionary attacks: People transmitting data via CDroms in envelopes. They ship the bulk of thier data that way (and I mean BULK! in the case I'm thinking about. BofA could learn something here BTW!), but the GBDE key is generated from a PRNG and emailed using PGP. The entire process is automated. >With GBDE the keys used to encrypt each of the key-key sectors >remain static. So, like CGD there is no effective way to revoke >access to the disk from wily and intelligent insiders who at some >point had access to the disk, except by re-encrypting the whole >thing. With both systems, the `master key' remains static and >hence if you can calculate it once you have it. That is a non-problem which GBDE doesn't claim to address: The vily insider is very likely to already have taken a copy of the data he wanted. >While we are at it, I do not believe that having a key that is >larger than 1024 bits necessarily guarantees that the effort required >to crack it is commensurate with its size. That obviously depends on the attack method and direction. >E.g. given the bit-blender >approach of GBDE [from 7.4 of your paper], if you know the salt >then you can use a divide-and-conquer strategy to tease the master >key out in a ``reasonably short'' time. Less than 2^128 steps >certainly, if I look at things correctly. I don't think you do. 2^128 will give you only one data sector. Then you need 2^128 to bruteforce the key encryption. Then you need 2^128 inverse MD5 operations, however much effort we assign that it is not zero, it will take you at least one clock cycle for each to store the result. By the time you've done that, you know 16 byte values which appear in the master key, but you do not know their indices in the master key There are between (256!/(256-16)!) and 256^16 (= 2^127...2^128) different possibilities for those sixteen indices and you won't know which it is until you know how many, if any, of those 16 values are identical. You may have a detection mechanism for the data sector which allows you to stop as soon as you have a hit, but there is no detection mechanism to let you know when you have a hit for the key encryption (or the MD5 unless "MD5^-1" is truly found), so you will be forced to operate with all 2^128 possibilities for the key-key, and spend some effort on the inverse MD5 for all of those before you continue. (MD5 may or may not add any real strengt at this point, it's there only as a bit blender. If MD5 adds strength, it is multiplicative not additive, because it applies to all of the 2^128 possibilities.) At this point you will need to find storage space for the 2^128 * 16 bytes if you want to avoid recomputations. I belive this means that you'll need to store 2^32 bits on every hydrogen atom in the universe (and then some.) Once you break the second data sector open, you can start to weed some of the 2^128 possibilities out, but it will be a long time before you get that down to a manageable number because only impossible output codes from MD5 will prune it for you. Of the 2^128 possibilities from the first sector and the 2^128 possibilities for the second data sector you broke, some, but not all, will have shared values for some of the 16 bytes from the masterkey. Being identical is no guarantee that they have the same index in the masterkey, but you can nontheless at this point start to attack the toplevel MD5 based on that theory. Getting more like 10-20 sectors would improve your chances a lot but then you need more storage space. Attacking from the top side means breaking the 512 bytes which protect one of the master keys. Given that there are four of them, I will conceeede to 508 bits of work. If we cut that in half just on general principles of being very very conservative, we get down to where the 256 bit version of CGD is if we ignore the CGD's little issue with key reuse. >So, if I were attacking GBDE, what I would do would be to look for >the superblock which is ~trivial to recognise and then walk down >the directory chain until I found the files/directories that I >want. I'll give you the headstart that you know where the superblock is. So you brute force the superblock. (2^128). >From that you can find the relative sector position of the inode table (we totally ignore the uncertainty of the for keysectors interleaving here). Then you bruteforce the first inode block (2^128) Then you bruteforce the first sector of the root directory (2^128) and you are lucky and find the file right there. You're even more lucky that the file has an inode in the same inode sector you already handled. And now you can start to bruteforce the data sector of the file (of which there is only one) (2^128). Now, you can't possibly be more lucky than this so that was 2^132 in the ultimate best case, downhill etc etc. But let us be a bit realistic: In case you get a false hit on the superblock, when do you find out ? The superblock is highly structured, but it is not free of entropy, so this is a very real risk. The answer is that you will not be sure to find out until you have broken the inode sector as well. Well, what if that gives you false hit too ? You get the picture. With CGD if I suspect a hit I can just run fsck or mount it. Fsck may be slow when you are in a hurry, but it is a lot faster than bruteforcing a 128 bit AES. By the way: you keep comparing your AES256 version of CGD to my AES128 version of GBDE, but at the same time you want me to conceede that your 256 bit key is almost 1024 bits when seen in the right light. Lets us be fair and use a level ground: Let us compare two 128 bit version or two 256 bit versions. Now, which algorithm is stronger ? >If a breakthrough makes AES128 very easy to crack, then you can >just crack the sectors individually, ignoring the rest of the >system. Yes, but is would be Nsect easier with CGD as the entire thing unravels at the first sector I break. With GBDE I have to attack them one by one. And since it is almost a given that any attack on AES will be statistical in nature, GBDE is much more resistant because there is no two-way leverage on any of the algoritms. So, I will still claim that you get points for your key handling and flunk on the disk encryption side. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 04:10:43 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CAEF16A4CE for ; Thu, 3 Mar 2005 04:10:43 +0000 (GMT) Received: from web52709.mail.yahoo.com (web52709.mail.yahoo.com [206.190.39.160]) by mx1.FreeBSD.org (Postfix) with SMTP id 97F7B43D2F for ; Thu, 3 Mar 2005 04:10:42 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 3200 invoked by uid 60001); 3 Mar 2005 04:10:42 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=mc/kopIJsaiH0UZwTl1t+UG2bYi4VM6/KFvNNbkMcW0ZgyYRS35/AZfAqp8O2yJYejzS5/FyHuFLqLmc+ZEeEQqshLY3VVwURDnjDVmf9v9EIWem1doQSVmWgeG6pGuCq771J8y9pt2nSJyxqR8KDLXFSfaVtaFniNM6vRNpbRQ= ; Message-ID: <20050303041042.3198.qmail@web52709.mail.yahoo.com> Received: from [202.91.78.244] by web52709.mail.yahoo.com via HTTP; Wed, 02 Mar 2005 20:10:42 PST Date: Wed, 2 Mar 2005 20:10:42 -0800 (PST) From: "Kamal R. Prasad" To: Julian Elischer , kamalp@acm.org In-Reply-To: <42261D95.9020506@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-hackers@freebsd.org cc: Lucas Holt Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kamalp@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 04:10:43 -0000 --- Julian Elischer wrote: > > > Kamal R. Prasad wrote: > > >--- Lucas Holt wrote: > > > > > > > >>Wouldn't a multi threaded program potentially need > >>more cpu time than > >>vi? > >> > >> > > > >No. That is not a given. > > > > > > > >>Multithreaded apps are created to do a lot of > >>computation or > >>because they have a lot of concurrent activity > that > >>might block right? > >> > >> > >> > >Threads are meant to take advantage of concurrency. > > >Maybe the freebsd implementation should implement > NPTL > >in entirety. > > > > > NPTL? > New Pthreads Library from Library? Yes. > isn't that GPL'd? > No -it is a standard. The linux implementation of nptl is gpl'ed. regards -kamal ===== ------------------------------------------------------------ Kamal R. Prasad UNIX systems consultant kamalp@acm.org In theory, there is no difference between theory and practice. In practice, there is:-). ------------------------------------------------------------ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 06:39:35 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0F8716A4CE; Thu, 3 Mar 2005 06:39:35 +0000 (GMT) Received: from mail0.jaist.ac.jp (mail0.jaist.ac.jp [150.65.5.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C72843D4C; Thu, 3 Mar 2005 06:39:33 +0000 (GMT) (envelope-from zrelli@jaist.ac.jp) Received: from mail-vc.jaist.ac.jp (mail-vc.jaist.ac.jp [150.65.5.31]) by mail0.jaist.ac.jp (3.7W-jaist_mail) with ESMTP id j236dXl22581; Thu, 3 Mar 2005 15:39:33 +0900 (JST) Received: from mail-vc.jaist.ac.jp (localhost [127.0.0.1]) by localhost.jaist.ac.jp (Postfix) with ESMTP id AFA8884B4; Thu, 3 Mar 2005 15:39:32 +0900 (JST) Received: from smtp.jaist.ac.jp (smtp.jaist.ac.jp [150.65.38.97]) by mail-vc.jaist.ac.jp (Postfix) with ESMTP id 83D4A84B1; Thu, 3 Mar 2005 15:39:32 +0900 (JST) Received: from [150.65.42.125] (dm6d25.jaist.ac.jp [150.65.42.125]) by smtp.jaist.ac.jp (3.7W-smtp) with ESMTP id j236dV817246; Thu, 3 Mar 2005 15:39:31 +0900 (JST) Message-ID: <4226B122.4090607@jaist.ac.jp> Date: Thu, 03 Mar 2005 15:39:30 +0900 From: Saber Zrelli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="------------000101030302090306090502" Subject: system temperature too high, shutting down soon! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 06:39:35 -0000 This is a multi-part message in MIME format. --------------000101030302090306090502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all , I'm runnig FreeBSD 5.3-RELEASE #0 on an IBM Thinkpad R50p , when I run some make install in the ports distribution. I got the following message : tornado root: WARNING: system temperature too high, shutting down soon! After 2-3 secs the system shuts down. when I looked in /var/log/messages after booting , I found : Mar 2 21:24:18 tornado kernel: cpu0: Performance states changed Mar 2 21:24:39 tornado kernel: cpu0: Performance states changed Mar 2 21:24:39 tornado root: WARNING: system temperature too high, shutting down soon! I was using 5.3 CURRENT ( and previous releases ) a while before , and I did not have this problem. my first thoughts is that it is a ACIP problem. but I dont have knowledge about ACPI stuff. I think that some parameters in hw.acpi.thermal are not correct. hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.tz0.temperature: 3312 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3647 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3672 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 specially hw.acpi.thermal.tz0._ACx , there is no cooling level temperatures defined. Also , the hw.acpi.thermal.tz0._CRT: 3672 ,hw.acpi.thermal.tz0._PSV: 3647 are too close , the cpu don't have enough time to cool down before reaching the critical temp. I tried debugging the ACPI module , so I compiled it with debuggin options . but the kernel could not load it and I was running without acpi. I attached < sysctl -a > and < cat /var/log/messages > I want to keep using ACPI , and I really need to fix this. For any suggestions , Many thanks -- Saber. --------------000101030302090306090502 Content-Type: text/plain; name="messages" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="messages" Feb 28 21:00:00 tornado newsyslog[732]: logfile turned over due to size>100K Feb 28 21:21:08 tornado halt: halted by zrelli Feb 28 21:21:08 tornado syslogd: exiting on signal 15 Feb 28 21:33:41 tornado syslogd: kernel boot file is /boot/kernel/kernel Feb 28 21:33:41 tornado kernel: Copyright (c) 1992-2004 The FreeBSD Project. Feb 28 21:33:41 tornado kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Feb 28 21:33:41 tornado kernel: The Regents of the University of California. All rights reserved. Feb 28 21:33:41 tornado kernel: FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 Feb 28 21:33:41 tornado kernel: root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Feb 28 21:33:41 tornado kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Feb 28 21:33:41 tornado kernel: CPU: Intel(R) Pentium(R) M processor 1700MHz (1698.57-MHz 686-class CPU) Feb 28 21:33:41 tornado kernel: Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Feb 28 21:33:41 tornado kernel: Features=0xa7e9f9bf Feb 28 21:33:41 tornado kernel: real memory = 1073086464 (1023 MB) Feb 28 21:33:41 tornado kernel: avail memory = 1040527360 (992 MB) Feb 28 21:33:41 tornado kernel: npx0: [FAST] Feb 28 21:33:41 tornado kernel: npx0: on motherboard Feb 28 21:33:41 tornado kernel: npx0: INT 16 interface Feb 28 21:33:41 tornado kernel: acpi0: on motherboard Feb 28 21:33:41 tornado kernel: acpi_ec0: port 0x66,0x62 on acpi0 Feb 28 21:33:41 tornado kernel: acpi0: Power Button (fixed) Feb 28 21:33:41 tornado kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Feb 28 21:33:41 tornado kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 Feb 28 21:33:41 tornado kernel: cpu0: on acpi0 Feb 28 21:33:41 tornado kernel: acpi_tz0: on acpi0 Feb 28 21:33:41 tornado kernel: acpi_lid0: on acpi0 Feb 28 21:33:41 tornado kernel: acpi_button0: on acpi0 Feb 28 21:33:41 tornado kernel: pcib0: port 0xcf8-0xcff on acpi0 Feb 28 21:33:41 tornado kernel: pci0: on pcib0 Feb 28 21:33:41 tornado kernel: agp0: mem 0xd0000000-0xdfffffff at device 0.0 on pci0 Feb 28 21:33:41 tornado kernel: pcib1: at device 1.0 on pci0 Feb 28 21:33:41 tornado kernel: pci1: on pcib1 Feb 28 21:33:41 tornado kernel: pci1: at device 0.0 (no driver attached) Feb 28 21:33:41 tornado kernel: uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 Feb 28 21:33:41 tornado kernel: uhci0: [GIANT-LOCKED] Feb 28 21:33:41 tornado kernel: usb0: on uhci0 Feb 28 21:33:41 tornado kernel: usb0: USB revision 1.0 Feb 28 21:33:41 tornado kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Feb 28 21:33:41 tornado kernel: uhub0: 2 ports with 2 removable, self powered Feb 28 21:33:41 tornado kernel: uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 Feb 28 21:33:41 tornado kernel: uhci1: [GIANT-LOCKED] Feb 28 21:33:41 tornado kernel: usb1: on uhci1 Feb 28 21:33:41 tornado kernel: usb1: USB revision 1.0 Feb 28 21:33:41 tornado kernel: uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Feb 28 21:33:41 tornado kernel: uhub1: 2 ports with 2 removable, self powered Feb 28 21:33:41 tornado kernel: uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 Feb 28 21:33:41 tornado kernel: uhci2: [GIANT-LOCKED] Feb 28 21:33:41 tornado kernel: usb2: on uhci2 Feb 28 21:33:41 tornado kernel: usb2: USB revision 1.0 Feb 28 21:33:41 tornado kernel: uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Feb 28 21:33:41 tornado kernel: uhub2: 2 ports with 2 removable, self powered Feb 28 21:33:41 tornado kernel: pci0: at device 29.7 (no driver attached) Feb 28 21:33:41 tornado kernel: pcib2: at device 30.0 on pci0 Feb 28 21:33:41 tornado kernel: pci2: on pcib2 Feb 28 21:33:41 tornado kernel: cbb0: mem 0xb0000000-0xb0000fff irq 11 at device 0.0 on pci2 Feb 28 21:33:41 tornado kernel: cardbus0: on cbb0 Feb 28 21:33:41 tornado kernel: pccard0: <16-bit PCCard bus> on cbb0 Feb 28 21:33:41 tornado kernel: cbb1: mem 0xb1000000-0xb1000fff irq 11 at device 0.1 on pci2 Feb 28 21:33:41 tornado kernel: cardbus1: on cbb1 Feb 28 21:33:41 tornado kernel: pccard1: <16-bit PCCard bus> on cbb1 Feb 28 21:33:41 tornado kernel: em0: port 0x8000-0x803f mem 0xc0200000-0xc020ffff,0xc0220000-0xc023ffff irq 11 at device 1.0 on pci2 Feb 28 21:33:41 tornado kernel: em0: Ethernet address: 00:0d:60:89:c2:67 Feb 28 21:33:41 tornado kernel: em0: Speed:N/A Duplex:N/A Feb 28 21:33:41 tornado kernel: pci2: at device 2.0 (no driver attached) Feb 28 21:33:41 tornado kernel: isab0: at device 31.0 on pci0 Feb 28 21:33:41 tornado kernel: isa0: on isab0 Feb 28 21:33:41 tornado kernel: atapci0: port 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 Feb 28 21:33:41 tornado kernel: ata0: channel #0 on atapci0 Feb 28 21:33:41 tornado kernel: ata1: channel #1 on atapci0 Feb 28 21:33:41 tornado kernel: pci0: at device 31.3 (no driver attached) Feb 28 21:33:41 tornado kernel: pci0: at device 31.5 (no driver attached) Feb 28 21:33:41 tornado kernel: pci0: at device 31.6 (no driver attached) Feb 28 21:33:41 tornado kernel: atkbdc0: port 0x64,0x60 irq 1 on acpi0 Feb 28 21:33:41 tornado kernel: atkbd0: irq 1 on atkbdc0 Feb 28 21:33:41 tornado kernel: kbd0 at atkbd0 Feb 28 21:33:41 tornado kernel: atkbd0: [GIANT-LOCKED] Feb 28 21:33:41 tornado kernel: psm0: irq 12 on atkbdc0 Feb 28 21:33:41 tornado kernel: psm0: [GIANT-LOCKED] Feb 28 21:33:41 tornado kernel: psm0: model Generic PS/2 mouse, device ID 0 Feb 28 21:33:41 tornado kernel: fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 Feb 28 21:33:41 tornado kernel: fdc0: [FAST] Feb 28 21:33:41 tornado kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Feb 28 21:33:41 tornado kernel: sio0: port may not be enabled Feb 28 21:33:41 tornado kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Feb 28 21:33:41 tornado kernel: sio0: type 8250 or not responding Feb 28 21:33:41 tornado kernel: ppc0: port 0x3bc-0x3be irq 7 on acpi0 Feb 28 21:33:41 tornado kernel: ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode Feb 28 21:33:41 tornado kernel: ppbus0: on ppc0 Feb 28 21:33:41 tornado kernel: plip0: on ppbus0 Feb 28 21:33:41 tornado kernel: lpt0: on ppbus0 Feb 28 21:33:41 tornado kernel: lpt0: Interrupt-driven port Feb 28 21:33:41 tornado kernel: ppi0: on ppbus0 Feb 28 21:33:41 tornado kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Feb 28 21:33:41 tornado kernel: sio1: port may not be enabled Feb 28 21:33:41 tornado kernel: acpi_cmbat0: on acpi0 Feb 28 21:33:41 tornado kernel: acpi_acad0: on acpi0 Feb 28 21:33:41 tornado kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Feb 28 21:33:41 tornado kernel: sio1: port may not be enabled Feb 28 21:33:41 tornado kernel: orm0: at iomem 0xdc000-0xdffff,0xd1000-0xd1fff,0xd0000-0xd0fff on isa0 Feb 28 21:33:41 tornado kernel: pmtimer0 on isa0 Feb 28 21:33:41 tornado kernel: sc0: at flags 0x100 on isa0 Feb 28 21:33:41 tornado kernel: sc0: VGA <16 virtual consoles, flags=0x300> Feb 28 21:33:41 tornado kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Feb 28 21:33:41 tornado kernel: sio1: port may not be enabled Feb 28 21:33:41 tornado kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Feb 28 21:33:41 tornado kernel: Timecounter "TSC" frequency 1698565963 Hz quality 800 Feb 28 21:33:41 tornado kernel: Timecounters tick every 10.000 msec Feb 28 21:33:41 tornado kernel: acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% Feb 28 21:33:41 tornado kernel: ad0: 53564MB [108828/16/63] at ata0-master UDMA100 Feb 28 21:33:41 tornado kernel: ata1-slave: FAILURE - ATAPI_IDENTIFY timed out Feb 28 21:33:41 tornado last message repeated 2 times Feb 28 21:33:41 tornado kernel: acd0: DVDR at ata1-master UDMA33 Feb 28 21:33:41 tornado kernel: Mounting root from ufs:/dev/ad0s2a Feb 28 21:33:41 tornado kernel: em0: Link is up 10 Mbps Half Duplex Feb 28 21:34:00 tornado login: ROOT LOGIN (root) ON ttyv0 Feb 28 21:34:24 tornado reboot: rebooted by root Feb 28 21:34:24 tornado syslogd: exiting on signal 15 Mar 2 19:43:09 tornado syslogd: kernel boot file is /boot/kernel/kernel Mar 2 19:43:09 tornado kernel: Copyright (c) 1992-2004 The FreeBSD Project. Mar 2 19:43:09 tornado kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 2 19:43:09 tornado kernel: The Regents of the University of California. All rights reserved. Mar 2 19:43:09 tornado kernel: FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 Mar 2 19:43:09 tornado kernel: root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Mar 2 19:43:09 tornado kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Mar 2 19:43:09 tornado kernel: CPU: Intel(R) Pentium(R) M processor 1700MHz (1698.56-MHz 686-class CPU) Mar 2 19:43:09 tornado kernel: Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Mar 2 19:43:09 tornado kernel: Features=0xa7e9f9bf Mar 2 19:43:09 tornado kernel: real memory = 1073086464 (1023 MB) Mar 2 19:43:09 tornado kernel: avail memory = 1040527360 (992 MB) Mar 2 19:43:09 tornado kernel: npx0: [FAST] Mar 2 19:43:09 tornado kernel: npx0: on motherboard Mar 2 19:43:09 tornado kernel: npx0: INT 16 interface Mar 2 19:43:09 tornado kernel: acpi0: on motherboard Mar 2 19:43:09 tornado kernel: acpi_ec0: port 0x66,0x62 on acpi0 Mar 2 19:43:09 tornado kernel: acpi0: Power Button (fixed) Mar 2 19:43:09 tornado kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Mar 2 19:43:09 tornado kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 Mar 2 19:43:09 tornado kernel: cpu0: on acpi0 Mar 2 19:43:09 tornado kernel: acpi_tz0: on acpi0 Mar 2 19:43:09 tornado kernel: acpi_lid0: on acpi0 Mar 2 19:43:09 tornado kernel: acpi_button0: on acpi0 Mar 2 19:43:09 tornado kernel: pcib0: port 0xcf8-0xcff on acpi0 Mar 2 19:43:09 tornado kernel: pci0: on pcib0 Mar 2 19:43:09 tornado kernel: agp0: mem 0xd0000000-0xdfffffff at device 0.0 on pci0 Mar 2 19:43:09 tornado kernel: pcib1: at device 1.0 on pci0 Mar 2 19:43:09 tornado kernel: pci1: on pcib1 Mar 2 19:43:09 tornado kernel: pci1: at device 0.0 (no driver attached) Mar 2 19:43:09 tornado kernel: uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 Mar 2 19:43:09 tornado kernel: uhci0: [GIANT-LOCKED] Mar 2 19:43:09 tornado kernel: usb0: on uhci0 Mar 2 19:43:09 tornado kernel: usb0: USB revision 1.0 Mar 2 19:43:09 tornado kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 2 19:43:09 tornado kernel: uhub0: 2 ports with 2 removable, self powered Mar 2 19:43:09 tornado kernel: uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 Mar 2 19:43:09 tornado kernel: uhci1: [GIANT-LOCKED] Mar 2 19:43:09 tornado kernel: usb1: on uhci1 Mar 2 19:43:09 tornado kernel: usb1: USB revision 1.0 Mar 2 19:43:09 tornado kernel: uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 2 19:43:09 tornado kernel: uhub1: 2 ports with 2 removable, self powered Mar 2 19:43:09 tornado kernel: uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 Mar 2 19:43:09 tornado kernel: uhci2: [GIANT-LOCKED] Mar 2 19:43:09 tornado kernel: usb2: on uhci2 Mar 2 19:43:09 tornado kernel: usb2: USB revision 1.0 Mar 2 19:43:09 tornado kernel: uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 2 19:43:09 tornado kernel: uhub2: 2 ports with 2 removable, self powered Mar 2 19:43:09 tornado kernel: pci0: at device 29.7 (no driver attached) Mar 2 19:43:09 tornado kernel: pcib2: at device 30.0 on pci0 Mar 2 19:43:09 tornado kernel: pci2: on pcib2 Mar 2 19:43:09 tornado kernel: cbb0: mem 0xb0000000-0xb0000fff irq 11 at device 0.0 on pci2 Mar 2 19:43:09 tornado kernel: cardbus0: on cbb0 Mar 2 19:43:09 tornado kernel: pccard0: <16-bit PCCard bus> on cbb0 Mar 2 19:43:09 tornado kernel: cbb1: mem 0xb1000000-0xb1000fff irq 11 at device 0.1 on pci2 Mar 2 19:43:09 tornado kernel: cardbus1: on cbb1 Mar 2 19:43:09 tornado kernel: pccard1: <16-bit PCCard bus> on cbb1 Mar 2 19:43:09 tornado kernel: em0: port 0x8000-0x803f mem 0xc0200000-0xc020ffff,0xc0220000-0xc023ffff irq 11 at device 1.0 on pci2 Mar 2 19:43:09 tornado kernel: em0: Ethernet address: 00:0d:60:89:c2:67 Mar 2 19:43:09 tornado kernel: em0: Speed:N/A Duplex:N/A Mar 2 19:43:09 tornado kernel: pci2: at device 2.0 (no driver attached) Mar 2 19:43:09 tornado kernel: isab0: at device 31.0 on pci0 Mar 2 19:43:09 tornado kernel: isa0: on isab0 Mar 2 19:43:09 tornado kernel: atapci0: port 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 Mar 2 19:43:09 tornado kernel: ata0: channel #0 on atapci0 Mar 2 19:43:09 tornado kernel: ata1: channel #1 on atapci0 Mar 2 19:43:09 tornado kernel: pci0: at device 31.3 (no driver attached) Mar 2 19:43:09 tornado kernel: pci0: at device 31.5 (no driver attached) Mar 2 19:43:09 tornado kernel: pci0: at device 31.6 (no driver attached) Mar 2 19:43:09 tornado kernel: atkbdc0: port 0x64,0x60 irq 1 on acpi0 Mar 2 19:43:09 tornado kernel: atkbd0: irq 1 on atkbdc0 Mar 2 19:43:09 tornado kernel: kbd0 at atkbd0 Mar 2 19:43:09 tornado kernel: atkbd0: [GIANT-LOCKED] Mar 2 19:43:09 tornado kernel: psm0: irq 12 on atkbdc0 Mar 2 19:43:09 tornado kernel: psm0: [GIANT-LOCKED] Mar 2 19:43:09 tornado kernel: psm0: model Generic PS/2 mouse, device ID 0 Mar 2 19:43:09 tornado kernel: fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 Mar 2 19:43:09 tornado kernel: fdc0: [FAST] Mar 2 19:43:09 tornado kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Mar 2 19:43:09 tornado kernel: sio0: port may not be enabled Mar 2 19:43:09 tornado kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Mar 2 19:43:09 tornado kernel: sio0: type 8250 or not responding Mar 2 19:43:09 tornado kernel: ppc0: port 0x3bc-0x3be irq 7 on acpi0 Mar 2 19:43:09 tornado kernel: ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode Mar 2 19:43:09 tornado kernel: ppbus0: on ppc0 Mar 2 19:43:09 tornado kernel: plip0: on ppbus0 Mar 2 19:43:09 tornado kernel: lpt0: on ppbus0 Mar 2 19:43:09 tornado kernel: lpt0: Interrupt-driven port Mar 2 19:43:09 tornado kernel: ppi0: on ppbus0 Mar 2 19:43:09 tornado kernel: sio1: port 0x2f8-0x2ff irq 3 drq 3 on acpi0 Mar 2 19:43:09 tornado kernel: sio1: type 16550A Mar 2 19:43:09 tornado kernel: acpi_cmbat0: on acpi0 Mar 2 19:43:09 tornado kernel: acpi_acad0: on acpi0 Mar 2 19:43:09 tornado kernel: orm0: at iomem 0xdc000-0xdffff,0xd1000-0xd1fff,0xd0000-0xd0fff on isa0 Mar 2 19:43:09 tornado kernel: pmtimer0 on isa0 Mar 2 19:43:09 tornado kernel: sc0: at flags 0x100 on isa0 Mar 2 19:43:09 tornado kernel: sc0: VGA <16 virtual consoles, flags=0x300> Mar 2 19:43:09 tornado kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Mar 2 19:43:09 tornado kernel: Timecounter "TSC" frequency 1698564535 Hz quality 800 Mar 2 19:43:09 tornado kernel: Timecounters tick every 10.000 msec Mar 2 19:43:09 tornado kernel: acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% Mar 2 19:43:09 tornado kernel: ad0: 53564MB [108828/16/63] at ata0-master UDMA100 Mar 2 19:43:09 tornado kernel: ata1-slave: FAILURE - ATAPI_IDENTIFY timed out Mar 2 19:43:09 tornado last message repeated 2 times Mar 2 19:43:09 tornado kernel: acd0: DVDR at ata1-master UDMA33 Mar 2 19:43:09 tornado kernel: Mounting root from ufs:/dev/ad0s2a Mar 2 19:43:09 tornado kernel: em0: Link is up 10 Mbps Half Duplex Mar 2 19:44:12 tornado login: ROOT LOGIN (root) ON ttyv0 Mar 2 19:45:40 tornado gconfd (zrelli-536): Owner of /var/tmp/orbit-zrelli-a8e8c858 is not the current user Mar 2 19:46:17 tornado su: zrelli to root on /dev/ttyp0 Mar 2 19:46:17 tornado kernel: cd9660: Joliet Extension (Level 3) Mar 2 19:46:35 tornado kernel: pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff mem 0xc0000800-0xc00008ff,0xc0000c00-0xc0000dff irq 11 at device 31.5 on pci0 Mar 2 19:46:35 tornado kernel: pcm0: [GIANT-LOCKED] Mar 2 19:46:35 tornado kernel: pcm0: Mar 2 20:04:09 tornado kernel: cd9660: RockRidge Extension Mar 2 20:06:55 tornado kernel: cd9660: RockRidge Extension Mar 2 21:24:18 tornado kernel: cpu0: Performance states changed Mar 2 21:24:39 tornado kernel: cpu0: Performance states changed Mar 2 21:24:39 tornado root: WARNING: system temperature too high, shutting down soon! Mar 2 21:24:39 tornado syslogd: /dev/:0: No such file or directory Mar 2 21:24:45 tornado syslogd: exiting on signal 15 Mar 2 21:26:10 tornado syslogd: kernel boot file is /boot/kernel/kernel Mar 2 21:26:10 tornado kernel: Copyright (c) 1992-2004 The FreeBSD Project. Mar 2 21:26:10 tornado kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 2 21:26:10 tornado kernel: The Regents of the University of California. All rights reserved. Mar 2 21:26:10 tornado kernel: FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 Mar 2 21:26:10 tornado kernel: root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Mar 2 21:26:10 tornado kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Mar 2 21:26:10 tornado kernel: CPU: Intel(R) Pentium(R) M processor 1700MHz (1698.56-MHz 686-class CPU) Mar 2 21:26:10 tornado kernel: Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Mar 2 21:26:10 tornado kernel: Features=0xa7e9f9bf Mar 2 21:26:10 tornado kernel: real memory = 1073086464 (1023 MB) Mar 2 21:26:10 tornado kernel: avail memory = 1040527360 (992 MB) Mar 2 21:26:10 tornado kernel: npx0: [FAST] Mar 2 21:26:10 tornado kernel: npx0: on motherboard Mar 2 21:26:10 tornado kernel: npx0: INT 16 interface Mar 2 21:26:10 tornado kernel: acpi0: on motherboard Mar 2 21:26:10 tornado kernel: acpi_ec0: port 0x66,0x62 on acpi0 Mar 2 21:26:10 tornado kernel: acpi0: Power Button (fixed) Mar 2 21:26:10 tornado kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Mar 2 21:26:10 tornado kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 Mar 2 21:26:10 tornado kernel: cpu0: on acpi0 Mar 2 21:26:10 tornado kernel: acpi_tz0: on acpi0 Mar 2 21:26:10 tornado kernel: acpi_lid0: on acpi0 Mar 2 21:26:10 tornado kernel: acpi_button0: on acpi0 Mar 2 21:26:10 tornado kernel: pcib0: port 0xcf8-0xcff on acpi0 Mar 2 21:26:10 tornado kernel: pci0: on pcib0 Mar 2 21:26:10 tornado kernel: agp0: mem 0xd0000000-0xdfffffff at device 0.0 on pci0 Mar 2 21:26:10 tornado kernel: pcib1: at device 1.0 on pci0 Mar 2 21:26:10 tornado kernel: pci1: on pcib1 Mar 2 21:26:10 tornado kernel: pci1: at device 0.0 (no driver attached) Mar 2 21:26:10 tornado kernel: uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 Mar 2 21:26:10 tornado kernel: uhci0: [GIANT-LOCKED] Mar 2 21:26:10 tornado kernel: usb0: on uhci0 Mar 2 21:26:10 tornado kernel: usb0: USB revision 1.0 Mar 2 21:26:10 tornado kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 2 21:26:10 tornado kernel: uhub0: 2 ports with 2 removable, self powered Mar 2 21:26:10 tornado kernel: uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 Mar 2 21:26:10 tornado kernel: uhci1: [GIANT-LOCKED] Mar 2 21:26:10 tornado kernel: usb1: on uhci1 Mar 2 21:26:10 tornado kernel: usb1: USB revision 1.0 Mar 2 21:26:10 tornado kernel: uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 2 21:26:10 tornado kernel: uhub1: 2 ports with 2 removable, self powered Mar 2 21:26:10 tornado kernel: uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 Mar 2 21:26:10 tornado kernel: uhci2: [GIANT-LOCKED] Mar 2 21:26:10 tornado kernel: usb2: on uhci2 Mar 2 21:26:10 tornado kernel: usb2: USB revision 1.0 Mar 2 21:26:10 tornado kernel: uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 2 21:26:10 tornado kernel: uhub2: 2 ports with 2 removable, self powered Mar 2 21:26:10 tornado kernel: pci0: at device 29.7 (no driver attached) Mar 2 21:26:10 tornado kernel: pcib2: at device 30.0 on pci0 Mar 2 21:26:10 tornado kernel: pci2: on pcib2 Mar 2 21:26:10 tornado kernel: cbb0: mem 0xb0000000-0xb0000fff irq 11 at device 0.0 on pci2 Mar 2 21:26:10 tornado kernel: cardbus0: on cbb0 Mar 2 21:26:10 tornado kernel: pccard0: <16-bit PCCard bus> on cbb0 Mar 2 21:26:10 tornado kernel: cbb1: mem 0xb1000000-0xb1000fff irq 11 at device 0.1 on pci2 Mar 2 21:26:10 tornado kernel: cardbus1: on cbb1 Mar 2 21:26:10 tornado kernel: pccard1: <16-bit PCCard bus> on cbb1 Mar 2 21:26:10 tornado kernel: em0: port 0x8000-0x803f mem 0xc0200000-0xc020ffff,0xc0220000-0xc023ffff irq 11 at device 1.0 on pci2 Mar 2 21:26:10 tornado kernel: em0: Ethernet address: 00:0d:60:89:c2:67 Mar 2 21:26:10 tornado kernel: em0: Speed:N/A Duplex:N/A Mar 2 21:26:10 tornado kernel: pci2: at device 2.0 (no driver attached) Mar 2 21:26:10 tornado kernel: isab0: at device 31.0 on pci0 Mar 2 21:26:10 tornado kernel: isa0: on isab0 Mar 2 21:26:10 tornado kernel: atapci0: port 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 Mar 2 21:26:10 tornado kernel: ata0: channel #0 on atapci0 Mar 2 21:26:10 tornado kernel: ata1: channel #1 on atapci0 Mar 2 21:26:10 tornado kernel: pci0: at device 31.3 (no driver attached) Mar 2 21:26:10 tornado kernel: pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff mem 0xc0000800-0xc00008ff,0xc0000c00-0xc0000dff irq 11 at device 31.5 on pci0 Mar 2 21:26:10 tornado kernel: pcm0: [GIANT-LOCKED] Mar 2 21:26:10 tornado kernel: pcm0: Mar 2 21:26:10 tornado kernel: pci0: at device 31.6 (no driver attached) Mar 2 21:26:10 tornado kernel: atkbdc0: port 0x64,0x60 irq 1 on acpi0 Mar 2 21:26:10 tornado kernel: atkbd0: irq 1 on atkbdc0 Mar 2 21:26:10 tornado kernel: kbd0 at atkbd0 Mar 2 21:26:10 tornado kernel: atkbd0: [GIANT-LOCKED] Mar 2 21:26:10 tornado kernel: psm0: irq 12 on atkbdc0 Mar 2 21:26:10 tornado kernel: psm0: [GIANT-LOCKED] Mar 2 21:26:10 tornado kernel: psm0: model Generic PS/2 mouse, device ID 0 Mar 2 21:26:10 tornado kernel: fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 Mar 2 21:26:10 tornado kernel: fdc0: [FAST] Mar 2 21:26:10 tornado kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Mar 2 21:26:10 tornado kernel: sio0: port may not be enabled Mar 2 21:26:10 tornado kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Mar 2 21:26:10 tornado kernel: sio0: type 8250 or not responding Mar 2 21:26:10 tornado kernel: ppc0: port 0x3bc-0x3be irq 7 on acpi0 Mar 2 21:26:10 tornado kernel: ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode Mar 2 21:26:10 tornado kernel: ppbus0: on ppc0 Mar 2 21:26:10 tornado kernel: plip0: on ppbus0 Mar 2 21:26:10 tornado kernel: lpt0: on ppbus0 Mar 2 21:26:10 tornado kernel: lpt0: Interrupt-driven port Mar 2 21:26:10 tornado kernel: ppi0: on ppbus0 Mar 2 21:26:10 tornado kernel: sio1: port 0x2f8-0x2ff irq 3 drq 3 on acpi0 Mar 2 21:26:10 tornado kernel: sio1: type 16550A Mar 2 21:26:10 tornado kernel: acpi_cmbat0: on acpi0 Mar 2 21:26:10 tornado kernel: acpi_acad0: on acpi0 Mar 2 21:26:10 tornado kernel: orm0: at iomem 0xdc000-0xdffff,0xd1000-0xd1fff,0xd0000-0xd0fff on isa0 Mar 2 21:26:10 tornado kernel: pmtimer0 on isa0 Mar 2 21:26:10 tornado kernel: sc0: at flags 0x100 on isa0 Mar 2 21:26:10 tornado kernel: sc0: VGA <16 virtual consoles, flags=0x300> Mar 2 21:26:10 tornado kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Mar 2 21:26:10 tornado kernel: Timecounter "TSC" frequency 1698564926 Hz quality 800 Mar 2 21:26:10 tornado kernel: Timecounters tick every 10.000 msec Mar 2 21:26:10 tornado kernel: acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% Mar 2 21:26:10 tornado kernel: ad0: 53564MB [108828/16/63] at ata0-master UDMA100 Mar 2 21:26:10 tornado kernel: ata1-slave: FAILURE - ATAPI_IDENTIFY timed out Mar 2 21:26:10 tornado last message repeated 2 times Mar 2 21:26:10 tornado kernel: acd0: DVDR at ata1-master UDMA33 Mar 2 21:26:10 tornado kernel: Mounting root from ufs:/dev/ad0s2a Mar 2 21:26:10 tornado kernel: em0: Link is up 10 Mbps Half Duplex Mar 2 21:26:16 tornado login: ROOT LOGIN (root) ON ttyv0 Mar 2 21:26:32 tornado gconfd (zrelli-505): Owner of /var/tmp/orbit-zrelli-a8e8c858 is not the current user --------------000101030302090306090502 Content-Type: text/plain; name="sysctl-output.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sysctl-output.txt" kern.ostype: FreeBSD kern.osrelease: 5.3-RELEASE kern.osrevision: 199506 kern.version: FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC kern.maxvnodes: 69950 kern.maxproc: 6164 kern.maxfiles: 12328 kern.argmax: 65536 kern.securelevel: -1 kern.hostname: tornado.jaist.ac.jp kern.hostid: 0 kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 } kern.posix1version: 200112 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 0 kern.boottime: { sec = 1109798729, usec = 285588 } Wed Mar 2 21:25:29 2005 kern.domainname: kern.osreldate: 503001 kern.bootfile: /boot/kernel/kernel kern.maxfilesperproc: 11095 kern.maxprocperuid: 5547 kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 60 kern.ipc.max_hdr: 76 kern.ipc.max_datalen: 132 kern.ipc.nmbclusters: 25600 kern.ipc.maxpipekva: 16777216 kern.ipc.pipes: 126 kern.ipc.pipekva: 1032192 kern.ipc.pipefragretry: 0 kern.ipc.pipeallocfail: 0 kern.ipc.piperesizefail: 0 kern.ipc.piperesizeallowed: 1 kern.ipc.msgmax: 16384 kern.ipc.msgmni: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgtql: 40 kern.ipc.msgssz: 8 kern.ipc.msgseg: 2048 kern.ipc.semmap: 30 kern.ipc.semmni: 10 kern.ipc.semmns: 60 kern.ipc.semmnu: 30 kern.ipc.semmsl: 60 kern.ipc.semopm: 100 kern.ipc.semume: 10 kern.ipc.semusz: 92 kern.ipc.semvmx: 32767 kern.ipc.semaem: 16384 kern.ipc.shmmax: 33554432 kern.ipc.shmmin: 1 kern.ipc.shmmni: 192 kern.ipc.shmseg: 128 kern.ipc.shmall: 8192 kern.ipc.shm_use_phys: 0 kern.ipc.shm_allow_removed: 0 kern.ipc.numopensockets: 177 kern.ipc.maxsockets: 25600 kern.ipc.nsfbufs: 6656 kern.ipc.nsfbufspeak: 3 kern.ipc.nsfbufsused: 0 kern.dummy: 0 kern.ps_strings: 3217031152 kern.usrstack: 3217031168 kern.logsigexit: 1 kern.iov_max: 1024 kern.cam.scsi_delay: 15000 kern.cam.cd.changer.min_busy_seconds: 5 kern.cam.cd.changer.max_busy_seconds: 15 kern.cam.da.retry_count: 4 kern.cam.da.default_timeout: 60 kern.disks: ad0 kern.geom.debugflags: 0 kern.geom.collectstats: 1 kern.elf32.fallback_brand: -1 kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall kern.acct_suspend: 2 kern.acct_resume: 4 kern.acct_chkfreq: 15 kern.cp_time: 15858 0 1483 286 220038 kern.openfiles: 401 kern.kq_calloutmax: 4096 kern.stackprot: 7 kern.ps_arg_cache_limit: 256 kern.lastpid: 712 kern.randompid: 0 kern.ktrace.genio_size: 4096 kern.ktrace.request_pool: 100 kern.module_path: /boot/kernel;/boot/modules kern.malloc: Type InUse MemUse HighUse Requests Size(s) linux 10 1K 1K 10 32 acpidev 75 3K 3K 75 32 acpisem 22 2K 2K 22 64 acpitask 0 0K 1K 474 16,32 acpica 3731 194K 194K 30224 16,32,64,128,256,512,1024,2048 feeder 50 1K 1K 50 16,64 acpibatt 1 1K 1K 1 16 ac97 2 1K 1K 2 16,256 mixer 1 1K 1K 1 1024 GEOM 67 9K 18K 334 16,32,64,128,256,512,1024,2048,4096 atkbddev 2 1K 1K 2 32 pfs_fileno 1 20K 20K 1 pfs_nodes 20 3K 3K 20 128 nexusdev 3 1K 1K 3 16 memdesc 1 4K 8K 11 32,4096 MSDOSFS mount 1 128K 128K 1 UMAHash 2 2K 2K 5 256,512,1024 VM pgdata 2 65K 65K 2 64 DEVFS 130 20K 20K 234 16,32,128,4096 USBdev 3 1K 5K 12 128,512 USB 46 5K 5K 46 16,32,64,128,256 UFS mount 3 7K 7K 3 256,2048,4096 UFS ihash 1 256K 256K 1 UFS dirhash 117 24K 24K 117 16,32,64,128,256,512 newblk 1 1K 1K 1 256 inodedep 1 256K 256K 1 pagedep 1 32K 32K 1 p1003.1b 1 1K 1K 1 16 agp 2 257K 257K 2 16 NFS daemon 1 1K 1K 1 256 NFS hash 1 256K 256K 1 in6_multi 7 1K 1K 7 64 syncache 1 8K 8K 1 hostcache 1 24K 24K 1 in_multi 2 1K 1K 2 32 routetbl 37 4K 4K 96 16,32,64,128,256 entropy 1024 64K 64K 1024 64 lo 1 1K 1K 1 1024 clone 4 16K 16K 4 4096 ether_multi 30 2K 2K 30 16,32,64 ifaddr 29 9K 9K 30 16,32,64,256,512,2048 BPF 7 9K 9K 7 64,128,256,4096 mount 9 3K 3K 14 16,32,128,1024 vnodes 29 7K 7K 160 16,32,64,128,256 cluster_save buffer 0 0K 1K 18 32,64 vfscache 1 512K 512K 1 BIO buffer 678 1356K 1356K 682 2048 pcb 15 5K 5K 121 16,32,64,2048 soname 90 11K 11K 1247 16,32,64,128 tag 0 0K 1K 7 32 ptys 1 1K 1K 1 128 ttys 1119 147K 147K 2484 128,512 shm 10 21K 22K 28 1024 sem 4 7K 7K 4 512,1024,4096 msg 4 25K 25K 4 512,4096 iov 0 0K 1K 82528 16,64,128,256 ioctlops 0 0K 4K 15 512,1024,4096 turnstiles 131 9K 9K 131 64 taskqueue 6 1K 1K 6 64 ppbusdev 3 1K 1K 3 128 sleep queues 131 5K 5K 131 32 sbuf 0 0K 21K 358 16,32,64,128,256,512,1024,2048,4096 rman 199 13K 13K 1018 16,64 ATA generic 4 2K 2K 5 16,512 kobj 234 468K 468K 282 2048 eventhandler 37 2K 2K 37 32,128 devstat 6 13K 13K 6 16,4096 bus-sc 53 32K 115K 2028 16,32,64,128,256,512,1024,2048,4096 bus 930 39K 140K 4619 16,32,64,128,1024 SWAP 2 33K 33K 2 64 sysctltmp 0 0K 1K 3727 16,32,64,128 sysctloid 2276 68K 68K 2276 16,32,64 sysctl 0 0K 1K 129 16,32,64 uidinfo 4 2K 2K 19 32,1024 plimit 16 4K 5K 251 256 cred 27 4K 4K 29320 128 subproc 143 402K 430K 1753 32,4096 proc 2 8K 8K 2 4096 session 25 4K 4K 40 128 pgrp 29 2K 2K 125 64 mtx_pool 1 8K 8K 1 module 346 22K 22K 346 64,128 ip6ndp 5 1K 1K 6 64,128 temp 91 237K 246K 8679 16,32,64,128,256,512,1024,2048,4096 devbuf 1495 3226K 3226K 3463 16,32,64,128,256,512,2048,4096 lockf 4 1K 1K 33 64 linker 65 119K 124K 119 16,32,64,256,1024,4096 KTRACE 100 13K 13K 100 128 ithread 54 5K 5K 55 64,128 zombie 0 0K 1K 613 128 proc-args 42 3K 4K 760 32,64,128,256 kqueue 0 0K 3K 100 128,1024 kenv 106 6K 6K 107 16,32,64,2048 sigio 1 1K 1K 1 32 file desc 135 39K 44K 874 16,32,256,512,2048 cdev 48 12K 12K 48 256 ACD driver 1 2K 2K 1 2048 AR driver 1 1K 3K 3 64,256,2048 AD driver 1 1K 1K 1 128 ISOFS mount 1 256K 256K 1 isadev 19 2K 2K 19 64 ATA DMA 2 1K 1K 2 128 kern.ident: GENERIC kern.maxusers: 384 kern.fallback_elf_brand: -1 kern.kstack_pages: 2 kern.uarea_pages: 1 kern.sync_on_panic: 0 kern.shutdown.poweroff_delay: 5000 kern.shutdown.kproc_shutdown_wait: 60 kern.sugid_coredump: 0 kern.coredump: 1 kern.nodump_coredump: 0 kern.corefile: %N.core kern.fscale: 2048 kern.timecounter.stepwarnings: 0 kern.timecounter.nbinuptime: 2072412 kern.timecounter.nnanouptime: 0 kern.timecounter.nmicrouptime: 758 kern.timecounter.nbintime: 1125934 kern.timecounter.nnanotime: 706947 kern.timecounter.nmicrotime: 418987 kern.timecounter.ngetbinuptime: 0 kern.timecounter.ngetnanouptime: 397 kern.timecounter.ngetmicrouptime: 372490 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetnanotime: 66 kern.timecounter.ngetmicrotime: 381440 kern.timecounter.nsetclock: 2 kern.timecounter.hardware: ACPI-fast kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.tick: 1 kern.threads.thr_scope_sys: 0 kern.threads.thr_concurrency: 0 kern.threads.debug: 0 kern.threads.max_threads_per_proc: 1500 kern.threads.max_groups_per_proc: 1500 kern.threads.max_threads_hits: 0 kern.threads.virtual_cpu: 1 kern.sched.name: 4BSD kern.sched.quantum: 100000 kern.sched.followon: 0 kern.sched.pfollowons: 0 kern.sched.kgfollowons: 0 kern.ccpu: 1948 kern.devstat.numdevs: 1 kern.devstat.generation: 86 kern.devstat.version: 6 kern.kobj_methodcount: 110 kern.log_wakeups_per_second: 5 kern.log_console_output: 1 kern.always_console_output: 0 kern.msgbuf: kern.msgbuf_clear: 0 kern.smp.maxcpus: 1 kern.smp.active: 0 kern.smp.disabled: 0 kern.smp.cpus: 1 kern.nselcoll: 0 kern.drainwait: 300 kern.tty_nin: 9008 kern.tty_nout: 44400 kern.console: consolectl,/ttyd0,consolectl, kern.consmute: 0 kern.consmsgbuf_size: 8192 kern.constty_wakeups_per_second: 5 kern.rootdev: ad0s2a kern.filedelay: 30 kern.dirdelay: 29 kern.metadelay: 28 kern.minvnodes: 17487 kern.chroot_allow_open_directories: 1 kern.rpc.retries: 0 kern.rpc.request: 0 kern.rpc.timeouts: 0 kern.rpc.unexpected: 0 kern.rpc.invalid: 0 kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0 vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 1 Disk Wait: 1 Page Wait: 0 Sleep: 52) Virtual Memory: (Total: 2097752K, Active 203100K) Real Memory: (Total: 227404K Active 150712K) Shared Virtual Memory: (Total: 47524K Active: 45020K) Shared Real Memory: (Total: 41220K Active: 39064K) Free Memory Pages: 792156K vm.loadavg: { 0.04 0.09 0.08 } vm.v_free_min: 1688 vm.v_free_target: 7166 vm.v_free_reserved: 414 vm.v_inactive_target: 10749 vm.v_cache_min: 7166 vm.v_cache_max: 14332 vm.v_pageout_free_min: 34 vm.pageout_algorithm: 0 vm.swap_enabled: 1 vm.kmem_size: 335544320 vm.kmem_size_max: 335544320 vm.kmem_size_scale: 3 vm.swap_async_max: 4 vm.dmmax: 32 vm.nswapdev: 1 vm.swap_idle_threshold1: 2 vm.swap_idle_threshold2: 10 vm.v_free_severe: 1051 vm.stats.sys.v_swtch: 895046 vm.stats.sys.v_trap: 241992 vm.stats.sys.v_syscall: 1988563 vm.stats.sys.v_intr: 674974 vm.stats.sys.v_soft: 69644 vm.stats.vm.v_vm_faults: 126574 vm.stats.vm.v_cow_faults: 21759 vm.stats.vm.v_cow_optim: 101 vm.stats.vm.v_zfod: 74936 vm.stats.vm.v_ozfod: 74786 vm.stats.vm.v_swapin: 0 vm.stats.vm.v_swapout: 0 vm.stats.vm.v_swappgsin: 0 vm.stats.vm.v_swappgsout: 0 vm.stats.vm.v_vnodein: 1377 vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodepgsin: 10661 vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_intrans: 55 vm.stats.vm.v_reactivated: 846 vm.stats.vm.v_pdwakeups: 0 vm.stats.vm.v_pdpages: 0 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_pfree: 28948 vm.stats.vm.v_tfree: 87116 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_page_count: 255146 vm.stats.vm.v_free_reserved: 414 vm.stats.vm.v_free_target: 7166 vm.stats.vm.v_free_min: 1688 vm.stats.vm.v_free_count: 197841 vm.stats.vm.v_wire_count: 20104 vm.stats.vm.v_active_count: 28027 vm.stats.vm.v_inactive_target: 10749 vm.stats.vm.v_inactive_count: 8877 vm.stats.vm.v_cache_count: 198 vm.stats.vm.v_cache_min: 7166 vm.stats.vm.v_cache_max: 14332 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_forks: 634 vm.stats.vm.v_vforks: 21 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_kthreads: 57 vm.stats.vm.v_forkpages: 65469 vm.stats.vm.v_vforkpages: 1135 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_kthreadpages: 0 vm.stats.misc.zero_page_count: 145472 vm.stats.misc.cnt_prezero: 229363 vm.max_proc_mmap: 49344 vm.msync_flush_flags: 3 vm.old_msync: 0 vm.old_contigmalloc: 0 vm.idlezero_enable: 1 vm.idlezero_maxrun: 16 vm.max_launder: 32 vm.pageout_stats_max: 7166 vm.pageout_full_stats_interval: 20 vm.pageout_stats_interval: 5 vm.swap_idle_enabled: 0 vm.defer_swapspace_pageouts: 0 vm.disable_swapspace_pageouts: 0 vm.pageout_lock_miss: 0 vm.zone: ITEM SIZE LIMIT USED FREE REQUESTS FFS2 dinode: 256, 0, 3052, 38, 3161 FFS1 dinode: 128, 0, 0, 0, 0 FFS inode: 140, 0, 3052, 28, 3161 SWAPMETA: 276, 121576, 0, 0, 0 rtentry: 132, 0, 17, 41, 17 ripcb: 180, 25608, 0, 44, 2 sackhole: 16, 0, 0, 203, 2 tcpreass: 20, 1690, 0, 169, 63 hostcache: 88, 15400, 2, 86, 2 syncache: 108, 15372, 0, 0, 0 tcptw: 56, 5159, 0, 134, 1 tcpcb: 448, 25605, 7, 11, 65 inpcb: 180, 25608, 7, 37, 65 udpcb: 180, 25608, 3, 41, 447 unpcb: 140, 25620, 167, 29, 489 socket: 324, 25608, 177, 15, 1010 KNOTE: 68, 0, 0, 112, 100 PIPE: 384, 0, 63, 27, 330 DIRHASH: 1024, 0, 266, 6, 266 NFSNODE: 452, 0, 0, 0, 0 NFSMOUNT: 432, 0, 0, 0, 0 L VFS Cache: 291, 0, 22, 17, 25 S VFS Cache: 68, 0, 3186, 62, 8378 NAMEI: 1024, 0, 0, 20, 70748 VNODEPOLL: 64, 0, 0, 0, 0 VNODE: 264, 0, 3203, 22, 3203 ata_request: 200, 0, 0, 38, 6512 g_bio: 132, 0, 0, 870, 25195 MbufClust: 2048, 25600, 384, 6, 384 Mbuf: 256, 0, 386, 139, 109330 Packet: 256, 0, 384, 141, 18741 VMSPACE: 300, 0, 43, 22, 653 UPCALL: 44, 0, 8, 148, 8 KSEGRP: 104, 0, 112, 63, 112 TID: 140, 0, 1, 53, 1 THREAD: 388, 0, 124, 6, 58197 PROC: 452, 0, 99, 9, 709 Files: 68, 0, 401, 47, 10726 4096: 4096, 0, 155, 12, 7626 2048: 2048, 0, 932, 2, 1344 1024: 1024, 0, 29, 99, 1929 512: 512, 0, 102, 18, 638 256: 256, 0, 264, 21, 1602 128: 128, 0, 1743, 27, 36682 64: 64, 0, 5167, 84, 91568 32: 32, 0, 2931, 120, 6606 16: 16, 0, 2305, 131, 32241 DP fakepg: 72, 0, 4786, 37, 4787 PV ENTRY: 24, 1494805, 67577, 2603, 525812 MAP ENTRY: 68, 0, 3411, 173, 38226 KMAP ENTRY: 68, 56560, 43, 125, 6257 MAP: 192, 0, 7, 33, 5 VM OBJECT: 132, 0, 4285, 94, 17032 128 Bucket: 524, 0, 63, 0, 0 64 Bucket: 268, 0, 37, 5, 0 32 Bucket: 140, 0, 21, 7, 0 16 Bucket: 76, 0, 33, 17, 0 UMA Hash: 128, 0, 3, 27, 0 UMA RCntSlab: 104, 0, 195, 27, 0 UMA Slabs: 64, 0, 798, 28, 0 UMA Zones: 88, 0, 60, 20, 0 UMA Kegs: 136, 0, 60, 12, 0 vm.kvm_size: 1073737728 vm.kvm_free: 142602240 vfs.nfs4.access_cache_timeout: 60 vfs.nfs4.nfsv3_commit_on_close: 0 vfs.nfs.downdelayinitial: 12 vfs.nfs.downdelayinterval: 30 vfs.nfs.realign_test: 0 vfs.nfs.realign_count: 0 vfs.nfs.bufpackets: 4 vfs.nfs.reconnects: 0 vfs.nfs.iodmaxidle: 120 vfs.nfs.iodmin: 4 vfs.nfs.iodmax: 20 vfs.nfs.defect: 0 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.diskless_valid: 0 vfs.nfs.diskless_rootpath: vfs.nfs.access_cache_timeout: 60 vfs.nfs.nfsv3_commit_on_close: 0 vfs.devfs.noverflow: 32768 vfs.devfs.generation: 98 vfs.devfs.inodes: 98 vfs.devfs.topinode: 101 vfs.ufs.dirhash_minsize: 2560 vfs.ufs.dirhash_maxmem: 2097152 vfs.ufs.dirhash_mem: 288995 vfs.ufs.dirhash_docheck: 0 vfs.pfs.vncache.entries: 0 vfs.pfs.vncache.maxentries: 0 vfs.pfs.vncache.hits: 0 vfs.pfs.vncache.misses: 0 vfs.vmiodirenable: 1 vfs.runningbufspace: 0 vfs.bufspace: 82051072 vfs.maxbufspace: 117293056 vfs.bufmallocspace: 1388544 vfs.maxmallocbufspace: 5831884 vfs.lobufspace: 116572160 vfs.hibufspace: 116637696 vfs.bufreusecnt: 5008 vfs.buffreekvacnt: 0 vfs.bufdefragcnt: 0 vfs.lorunningspace: 524288 vfs.hirunningspace: 1048576 vfs.dirtybufferflushes: 0 vfs.altbufferflushes: 0 vfs.recursiveflushes: 0 vfs.numdirtybuffers: 7 vfs.lodirtybuffers: 904 vfs.hidirtybuffers: 1809 vfs.dirtybufthresh: 1628 vfs.numfreebuffers: 7152 vfs.lofreebuffers: 402 vfs.hifreebuffers: 804 vfs.getnewbufcalls: 5120 vfs.getnewbufrestarts: 0 vfs.flushwithdeps: 0 vfs.cache.numneg: 199 vfs.cache.numcache: 3208 vfs.cache.numcalls: 287370 vfs.cache.dothits: 2817 vfs.cache.dotdothits: 164 vfs.cache.numchecks: 295318 vfs.cache.nummiss: 8485 vfs.cache.nummisszap: 88 vfs.cache.numposzaps: 150 vfs.cache.numposhits: 248322 vfs.cache.numnegzaps: 33 vfs.cache.numneghits: 27311 vfs.cache.nchstats: 248322 27311 183 0 8573 0 228 423 vfs.cache.numcwdcalls: 86 vfs.cache.numcwdfail1: 0 vfs.cache.numcwdfail2: 0 vfs.cache.numcwdfail3: 0 vfs.cache.numcwdfail4: 0 vfs.cache.numcwdfound: 86 vfs.cache.numfullpathcalls: 0 vfs.cache.numfullpathfail1: 0 vfs.cache.numfullpathfail2: 0 vfs.cache.numfullpathfail3: 0 vfs.cache.numfullpathfail4: 0 vfs.cache.numfullpathfound: 0 vfs.write_behind: 1 vfs.read_max: 8 vfs.opv_numops: 64 vfs.usermount: 0 vfs.numvnodes: 3203 vfs.wantfreevnodes: 25 vfs.freevnodes: 848 vfs.reassignbufcalls: 2696 vfs.nameileafonly: 0 vfs.timestamp_precision: 0 vfs.worklist_len: 2 vfs.nfsrv.nfs_privport: 0 vfs.nfsrv.async: 0 vfs.nfsrv.commit_blks: 0 vfs.nfsrv.commit_miss: 0 vfs.nfsrv.realign_test: 0 vfs.nfsrv.realign_count: 0 vfs.nfsrv.gatherdelay: 10000 vfs.nfsrv.gatherdelay_v3: 0 vfs.ffs.doasyncfree: 1 vfs.ffs.doreallocblks: 1 net.local.stream.sendspace: 8192 net.local.stream.recvspace: 8192 net.local.dgram.maxdgram: 2048 net.local.dgram.recvspace: 4096 net.local.inflight: 0 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.randomized: 1 net.inet.ip.forwarding: 0 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.subnets_are_local: 0 net.inet.ip.fastforwarding: 0 net.inet.ip.process_options: 1 net.inet.ip.maxfragpackets: 800 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.sendsourcequench: 0 net.inet.ip.random_id: 0 net.inet.ip.check_interface: 0 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.maskfake: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.log_redirect: 0 net.inet.icmp.icmplim_output: 1 net.inet.icmp.reply_src: net.inet.icmp.bmcastecho: 0 net.inet.tcp.rfc1323: 1 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.count: 2 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.blackhole: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.reass.maxsegments: 1600 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.overflows: 0 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.newreno: 1 net.inet.tcp.minmss: 216 net.inet.tcp.minmssoverload: 0 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.pcbcount: 7 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.stab: 20 net.inet.tcp.sack.enable: 1 net.inet.tcp.syncookies: 1 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncache.cachelimit: 15359 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.msl: 30000 net.inet.tcp.rexmit_min: 30 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.always_keepalive: 1 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.log_in_vain: 0 net.inet.udp.blackhole: 0 net.inet.udp.strict_mcast_mship: 0 net.inet.raw.maxdgram: 8192 net.inet.raw.recvspace: 8192 net.inet.accf.unloadable: 0 net.link.generic.system.ifcount: 3 net.link.ether.inet.prune_intvl: 300 net.link.ether.inet.max_age: 1200 net.link.ether.inet.host_down_time: 20 net.link.ether.inet.maxtries: 5 net.link.ether.inet.useloopback: 1 net.link.ether.inet.proxyall: 0 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.ipfw: 0 net.link.gif.max_nesting: 1 net.link.gif.parallel_tunnels: 0 net.inet6.ip6.forwarding: 0 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 6400 net.inet6.ip6.accept_rtadv: 1 net.inet6.ip6.keepfaith: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 50 net.inet6.ip6.dad_count: 1 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: 20010528/FreeBSD net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.v6only: 1 net.inet6.ip6.rtexpire: 3600 net.inet6.ip6.rtminexpire: 10 net.inet6.ip6.rtmaxcache: 128 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.auto_linklocal: 1 net.inet6.ip6.prefer_tempaddr: 0 net.inet6.ip6.maxfrags: 6400 net.inet6.icmp6.rediraccept: 1 net.inet6.icmp6.redirtimeout: 600 net.inet6.icmp6.nd6_prune: 1 net.inet6.icmp6.nd6_delay: 5 net.inet6.icmp6.nd6_umaxtries: 3 net.inet6.icmp6.nd6_mmaxtries: 3 net.inet6.icmp6.nd6_useloopback: 1 net.inet6.icmp6.nodeinfo: 3 net.inet6.icmp6.errppslimit: 100 net.inet6.icmp6.nd6_maxnudhint: 0 net.inet6.icmp6.nd6_debug: 0 net.isr.enable: 0 net.isr.count: 2436 net.isr.directed: 0 net.isr.deferred: 2436 net.isr.queued: 91 net.isr.drop: 0 net.isr.swi_count: 2463 net.route.netisr_maxqlen: 256 debug.firewire_debug: 0 debug.fwmem_debug: 0 debug.if_fwe_debug: 0 debug.sbp_debug: 0 debug.mddebug: 0 debug.doslowdown: 0 debug.elf32_trace: 0 debug.elf32_legacy_coredump: 0 debug.boothowto: -2147483648 debug.bootverbose: 0 debug.free_devt: 0 debug.sizeof.g_class: 68 debug.sizeof.g_geom: 68 debug.sizeof.g_provider: 88 debug.sizeof.g_consumer: 60 debug.sizeof.g_bioq: 48 debug.sizeof.vnode: 264 debug.sizeof.proc: 452 debug.sizeof.cdev: 232 debug.sizeof.bio: 132 debug.sizeof.buf: 436 debug.sizeof.kinfo_proc: 648 debug.sizeof.devstat: 240 debug.to_avg_depth: 3276 debug.to_avg_gcalls: 487 debug.to_avg_mpcalls: 2763 debug.kdb.available: _TMP debug.kdb.current: debug.kdb.enter: 0 debug.rman_debug: 0 debug.ttydebug: 0 debug.dobkgrdwrite: 1 debug.nchash: 131071 debug.ncnegfactor: 16 debug.numneg: 199 debug.numcache: 3208 debug.numcachehv: 733 debug.vfscache: 1 debug.vnsize: 264 debug.ncsize: 36 debug.hashstat.nchash: 131072 3170 2 241 debug.hashstat.nfsnode: 65536 0 0 0 debug.disablecwd: 0 debug.disablefullpath: 0 debug.rush_requests: 0 debug.vnlru_nowhere: 0 debug.bpf_bufsize: 4096 debug.bpf_maxbufsize: 524288 debug.if_tun_debug: 0 debug.mpsafenet: 1 debug.ieee80211: 0 debug.dopersistence: 0 debug.snapdebug: 0 debug.collectsnapstats: 0 debug.max_softdeps: 279800 debug.tickdelay: 2 debug.maxindirdeps: 50 debug.worklist_push: 0 debug.blk_limit_push: 0 debug.ino_limit_push: 0 debug.blk_limit_hit: 0 debug.ino_limit_hit: 0 debug.sync_limit_hit: 0 debug.indir_blk_ptrs: 0 debug.inode_bitmap: 0 debug.direct_blk_ptrs: 0 debug.dir_entry: 0 debug.bigcgs: 0 debug.dircheck: 0 debug.mpsafevm: 0 debug.nosleepwithlocks: 0 debug.fdc.fifo: 8 debug.fdc.debugflags: 0 debug.fdc.retries: 10 debug.fdc.spec1: 175 debug.fdc.spec2: 16 debug.fdc.settle: 12 debug.PMAP1changed: 2119 debug.PMAP1unchanged: 303230 debug.psmhz: 20 debug.psm_soft_timeout: 500000 debug.psmerrsecs: 2 debug.psmerrusecs: 0 debug.psmsecs: 0 debug.psmusecs: 500000 debug.psmpkterrthresh: 2 debug.psmloglevel: 0 debug.acpi.acpi_ca_version: 0x20040527 debug.acpi.semaphore_debug: 0 hw.machine: i386 hw.model: Intel(R) Pentium(R) M processor 1700MHz hw.ncpu: 1 hw.byteorder: 1234 hw.physmem: 1064140800 hw.usermem: 981778432 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: i386 hw.aac.iosize_max: 65536 hw.an.an_dump: off hw.an.an_cache_mode: dbm hw.an.an_cache_mcastonly: 0 hw.an.an_cache_iponly: 1 hw.ata.ata_dma: 1 hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.cardbus.debug: 0 hw.cardbus.cis_debug: 0 hw.cs.debug: 0 hw.cs.ignore_checksum_failure: 0 hw.cs.recv_delay: 570 hw.firewire.try_bmr: 1 hw.firewire.hold_count: 3 hw.firewire.fwmem.eui64_hi: 0 hw.firewire.fwmem.eui64_lo: 0 hw.firewire.fwmem.speed: 2 hw.firewire.fwe.stream_ch: 1 hw.firewire.fwe.tx_speed: 2 hw.firewire.fwe.rx_queue_len: 128 hw.firewire.sbp.auto_login: 1 hw.firewire.sbp.max_speed: -1 hw.firewire.sbp.exclusive_login: 1 hw.firewire.sbp.login_delay: 1000 hw.firewire.sbp.scan_delay: 500 hw.firewire.sbp.use_doorbell: 0 hw.firewire.sbp.tags: 0 hw.pccard.debug: 0 hw.pccard.cis_debug: 0 hw.cbb.start_memory: 2281701376 hw.cbb.start_16_io: 256 hw.cbb.start_32_io: 4096 hw.cbb.debug: 0 hw.pcic.intr_mask: 57016 hw.pci.enable_io_modes: 1 hw.pci.do_powerstate: 0 hw.pci.host_mem_start: -2147483648 hw.pci.irq_override_mask: 57080 hw.wi.txerate: 0 hw.wi.debug: 0 hw.xe.debug: 0 hw.intr_storm_threshold: 500 hw.availpages: 259800 hw.bus.devctl_disable: 0 hw.dc_quick: 1 hw.ste.rxsyncs: 0 hw.kbd.keymap_restrict_change: 0 hw.syscons.saver.keybonly: 1 hw.syscons.bell: 1 hw.syscons.sc_no_suspend_vtswitch: 0 hw.busdma.free_bpages: 512 hw.busdma.reserved_bpages: 0 hw.busdma.active_bpages: 0 hw.busdma.total_bpages: 512 hw.busdma.total_bounced: 0 hw.busdma.total_deferred: 0 hw.clockrate: 1698 hw.instruction_sse: 1 hw.snd.targetirqrate: 32 hw.snd.report_soft_formats: 1 hw.snd.verbose: 1 hw.snd.unit: 0 hw.snd.maxautovchans: 0 hw.snd.pcm0.buffersize: 16384 hw.snd.pcm0.vchans: 0 hw.snd.pcm0.ac97rate: 48000 hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.reset_video: 1 hw.acpi.cpu.throttle_max: 8 hw.acpi.cpu.throttle_state: 8 hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 hw.acpi.cpu.cx_lowest: C3 hw.acpi.cpu.cx_usage: 0.00% 100.00% 0.00% hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.tz0.temperature: 3312 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3647 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3672 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.battery.life: 100 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.acline: 1 hw.em0.debug_info: -1 hw.em0.stats: -1 hw.em0.rx_int_delay: 0 hw.em0.tx_int_delay: 66 hw.em0.rx_abs_int_delay: 66 hw.em0.tx_abs_int_delay: 66 machdep.adjkerntz: 0 machdep.disable_rtc_set: 0 machdep.wall_cmos_clock: 0 machdep.conrclk: 1843200 machdep.gdbspeed: 9600 machdep.conspeed: 9600 machdep.enable_panic_key: 0 machdep.disable_mtrrs: 0 machdep.cpu_idle_hlt: 1 machdep.guessed_bootdev: 2687500288 machdep.panic_on_nmi: 1 machdep.tsc_freq: 1698564926 machdep.i8254_freq: 1193182 machdep.acpi_timer_freq: 3579545 machdep.acpi_root: 1011184 user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: user.bc_base_max: 99 user.bc_dim_max: 2048 user.bc_scale_max: 99 user.bc_string_max: 1000 user.coll_weights_max: 0 user.expr_nest_max: 32 user.line_max: 2048 user.re_dup_max: 255 user.posix2_version: 199212 user.posix2_c_bind: 0 user.posix2_c_dev: 0 user.posix2_char_term: 0 user.posix2_fort_dev: 0 user.posix2_fort_run: 0 user.posix2_localedef: 0 user.posix2_sw_dev: 0 user.posix2_upe: 0 user.stream_max: 20 user.tzname_max: 255 p1003_1b.asynchronous_io: 0 p1003_1b.mapped_files: 1 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 1 p1003_1b.realtime_signals: 0 p1003_1b.semaphores: 0 p1003_1b.fsync: 0 p1003_1b.shared_memory_objects: 1 p1003_1b.synchronized_io: 0 p1003_1b.timers: 0 p1003_1b.aio_listio_max: -1 p1003_1b.aio_max: -1 p1003_1b.aio_prio_delta_max: -1 p1003_1b.delaytimer_max: 0 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 0 p1003_1b.sem_nsems_max: 0 p1003_1b.sem_value_max: 0 p1003_1b.sigqueue_max: 0 p1003_1b.timer_max: 0 compat.linux.osname: Linux compat.linux.osrelease: 2.4.2 compat.linux.oss_version: 198144 security.jail.set_hostname_allowed: 1 security.jail.socket_unixiproute_only: 1 security.jail.sysvipc_allowed: 0 security.jail.getfsstatroot_only: 1 security.jail.allow_raw_sockets: 0 security.jail.jailed: 0 security.bsd.suser_enabled: 1 security.bsd.see_other_uids: 1 security.bsd.see_other_gids: 1 security.bsd.conservative_signals: 1 security.bsd.unprivileged_proc_debug: 1 security.bsd.unprivileged_read_msgbuf: 1 security.bsd.hardlink_check_uid: 0 security.bsd.hardlink_check_gid: 0 security.bsd.unprivileged_get_quota: 0 dev.nexus.0.%driver: nexus dev.nexus.0.%parent: root0 dev.npx.0.%desc: math processor dev.npx.0.%driver: npx dev.npx.0.%parent: nexus0 dev.acpi.0.%desc: IBM TP-1R dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_ec.0.%desc: Embedded Controller: GPE 0x1c, ECDT dev.acpi_ec.0.%driver: acpi_ec dev.acpi_ec.0.%location: handle=\_SB_.PCI0.LPC_.EC__ dev.acpi_ec.0.%pnpinfo: _HID=PNP0C09 _UID=0 dev.acpi_ec.0.%parent: acpi0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.MEM_ dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C01 _UID=0 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_sysresource.1.%desc: System Resource dev.acpi_sysresource.1.%driver: acpi_sysresource dev.acpi_sysresource.1.%location: handle=\_SB_.PCI0.LPC_.SIO_ dev.acpi_sysresource.1.%pnpinfo: _HID=PNP0C02 _UID=0 dev.acpi_sysresource.1.%parent: acpi0 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.cpu.0.%desc: ACPI CPU (3 Cx states) dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU_ dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.0.%driver: acpi_tz dev.acpi_tz.0.%location: handle=\_TZ_.THM0 dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.0.%parent: acpi0 dev.acpi_lid.0.%desc: Control Method Lid Switch dev.acpi_lid.0.%driver: acpi_lid dev.acpi_lid.0.%location: handle=\_SB_.LID_ dev.acpi_lid.0.%pnpinfo: _HID=PNP0C0D _UID=0 dev.acpi_lid.0.%parent: acpi0 dev.acpi_lid.0.wake: 1 dev.acpi_button.0.%desc: Sleep Button dev.acpi_button.0.%driver: acpi_button dev.acpi_button.0.%location: handle=\_SB_.SLPB dev.acpi_button.0.%pnpinfo: _HID=PNP0C0E _UID=0 dev.acpi_button.0.%parent: acpi0 dev.acpi_button.0.wake: 1 dev.pcib.0.%desc: ACPI Host-PCI bridge dev.pcib.0.%driver: pcib dev.pcib.0.%location: handle=\_SB_.PCI0 dev.pcib.0.%pnpinfo: _HID=PNP0A03 _UID=0 dev.pcib.0.%parent: acpi0 dev.pcib.0.wake: 0 dev.pcib.1.%desc: ACPI PCI-PCI bridge dev.pcib.1.%driver: pcib dev.pcib.1.%location: slot=1 function=0 handle=\_SB_.PCI0.AGP_ dev.pcib.1.%pnpinfo: vendor=0x8086 device=0x3341 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.1.%parent: pci0 dev.pcib.2.%desc: ACPI PCI-PCI bridge dev.pcib.2.%driver: pcib dev.pcib.2.%location: slot=30 function=0 handle=\_SB_.PCI0.PCI1 dev.pcib.2.%pnpinfo: vendor=0x8086 device=0x2448 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.2.%parent: pci0 dev.pcib.2.wake: 0 dev.pci.0.%desc: ACPI PCI bus dev.pci.0.%driver: pci dev.pci.0.%parent: pcib0 dev.pci.0.wake: 0 dev.pci.1.%desc: ACPI PCI bus dev.pci.1.%driver: pci dev.pci.1.%parent: pcib1 dev.pci.2.%desc: ACPI PCI bus dev.pci.2.%driver: pci dev.pci.2.%parent: pcib2 dev.pci.2.wake: 0 dev.agp.0.%desc: Intel 82855 host to AGP bridge dev.agp.0.%driver: agp dev.agp.0.%location: slot=0 function=0 dev.agp.0.%pnpinfo: vendor=0x8086 device=0x3340 subvendor=0x1014 subdevice=0x0529 class=0x060000 dev.agp.0.%parent: pci0 dev.uhci.0.%desc: Intel 82801DB (ICH4) USB controller USB-A dev.uhci.0.%driver: uhci dev.uhci.0.%location: slot=29 function=0 handle=\_SB_.PCI0.USB0 dev.uhci.0.%pnpinfo: vendor=0x8086 device=0x24c2 subvendor=0x1014 subdevice=0x052d class=0x0c0300 dev.uhci.0.%parent: pci0 dev.uhci.0.wake: 0 dev.uhci.1.%desc: Intel 82801DB (ICH4) USB controller USB-B dev.uhci.1.%driver: uhci dev.uhci.1.%location: slot=29 function=1 handle=\_SB_.PCI0.USB1 dev.uhci.1.%pnpinfo: vendor=0x8086 device=0x24c4 subvendor=0x1014 subdevice=0x052d class=0x0c0300 dev.uhci.1.%parent: pci0 dev.uhci.1.wake: 0 dev.uhci.2.%desc: Intel 82801DB (ICH4) USB controller USB-C dev.uhci.2.%driver: uhci dev.uhci.2.%location: slot=29 function=2 handle=\_SB_.PCI0.USB2 dev.uhci.2.%pnpinfo: vendor=0x8086 device=0x24c7 subvendor=0x1014 subdevice=0x052d class=0x0c0300 dev.uhci.2.%parent: pci0 dev.usb.0.%desc: Intel 82801DB (ICH4) USB controller USB-A dev.usb.0.%driver: usb dev.usb.0.%parent: uhci0 dev.usb.1.%desc: Intel 82801DB (ICH4) USB controller USB-B dev.usb.1.%driver: usb dev.usb.1.%parent: uhci1 dev.usb.2.%desc: Intel 82801DB (ICH4) USB controller USB-C dev.usb.2.%driver: usb dev.usb.2.%parent: uhci2 dev.uhub.0.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.0.%driver: uhub dev.uhub.0.%parent: usb0 dev.uhub.1.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.1.%driver: uhub dev.uhub.1.%parent: usb1 dev.uhub.2.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.2.%driver: uhub dev.uhub.2.%parent: usb2 dev.cbb.0.%desc: PCI-CardBus Bridge dev.cbb.0.%driver: cbb dev.cbb.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PCI1.CBS0 dev.cbb.0.%pnpinfo: vendor=0x104c device=0xac46 subvendor=0x1014 subdevice=0x0552 class=0x060700 dev.cbb.0.%parent: pci2 dev.cbb.1.%desc: PCI-CardBus Bridge dev.cbb.1.%driver: cbb dev.cbb.1.%location: slot=0 function=1 handle=\_SB_.PCI0.PCI1.CBS1 dev.cbb.1.%pnpinfo: vendor=0x104c device=0xac46 subvendor=0x1014 subdevice=0x0552 class=0x060700 dev.cbb.1.%parent: pci2 dev.cardbus.%parent: pci dev.cardbus.0.%desc: CardBus bus dev.cardbus.0.%driver: cardbus dev.cardbus.0.%parent: cbb0 dev.cardbus.1.%desc: CardBus bus dev.cardbus.1.%driver: cardbus dev.cardbus.1.%parent: cbb1 dev.pccard.0.%desc: 16-bit PCCard bus dev.pccard.0.%driver: pccard dev.pccard.0.%parent: cbb0 dev.pccard.1.%desc: 16-bit PCCard bus dev.pccard.1.%driver: pccard dev.pccard.1.%parent: cbb1 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection, Version - 1.7.35 dev.em.0.%driver: em dev.em.0.%location: slot=1 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x101e subvendor=0x1014 subdevice=0x0549 class=0x020000 dev.em.0.%parent: pci2 dev.isab.0.%desc: PCI-ISA bridge dev.isab.0.%driver: isab dev.isab.0.%location: slot=31 function=0 handle=\_SB_.PCI0.LPC_ dev.isab.0.%pnpinfo: vendor=0x8086 device=0x24cc subvendor=0x0000 subdevice=0x0000 class=0x060100 dev.isab.0.%parent: pci0 dev.isa.0.%desc: ISA bus dev.isa.0.%driver: isa dev.isa.0.%parent: isab0 dev.atapci.0.%desc: Intel ICH4 UDMA100 controller dev.atapci.0.%driver: atapci dev.atapci.0.%location: slot=31 function=1 handle=\_SB_.PCI0.IDE0 dev.atapci.0.%pnpinfo: vendor=0x8086 device=0x24ca subvendor=0x1014 subdevice=0x052d class=0x01018a dev.atapci.0.%parent: pci0 dev.ata.0.%driver: ata dev.ata.0.%parent: atapci0 dev.ata.1.%driver: ata dev.ata.1.%parent: atapci0 dev.pcm.0.%desc: Intel ICH4 (82801DB) dev.pcm.0.%driver: pcm dev.pcm.0.%location: slot=31 function=5 dev.pcm.0.%pnpinfo: vendor=0x8086 device=0x24c5 subvendor=0x1014 subdevice=0x0554 class=0x040100 dev.pcm.0.%parent: pci0 dev.atpic.0.%desc: AT interrupt controller dev.atpic.0.%driver: atpic dev.atpic.0.%location: handle=\_SB_.PCI0.LPC_.PIC_ dev.atpic.0.%pnpinfo: _HID=PNP0000 _UID=0 dev.atpic.0.%parent: acpi0 dev.attimer.0.%desc: AT timer dev.attimer.0.%driver: attimer dev.attimer.0.%location: handle=\_SB_.PCI0.LPC_.TIMR dev.attimer.0.%pnpinfo: _HID=PNP0100 _UID=0 dev.attimer.0.%parent: acpi0 dev.attimer.1.%desc: AT realtime clock dev.attimer.1.%driver: attimer dev.attimer.1.%location: handle=\_SB_.PCI0.LPC_.RTC_ dev.attimer.1.%pnpinfo: _HID=PNP0B00 _UID=0 dev.attimer.1.%parent: acpi0 dev.atdma.0.%desc: AT DMA controller dev.atdma.0.%driver: atdma dev.atdma.0.%location: handle=\_SB_.PCI0.LPC_.DMAC dev.atdma.0.%pnpinfo: _HID=PNP0200 _UID=0 dev.atdma.0.%parent: acpi0 dev.npxisa.0.%desc: Legacy ISA coprocessor support dev.npxisa.0.%driver: npxisa dev.npxisa.0.%location: handle=\_SB_.PCI0.LPC_.FPU_ dev.npxisa.0.%pnpinfo: _HID=PNP0C04 _UID=0 dev.npxisa.0.%parent: acpi0 dev.atkbdc.0.%desc: Keyboard controller (i8042) dev.atkbdc.0.%driver: atkbdc dev.atkbdc.0.%location: handle=\_SB_.PCI0.LPC_.KBD_ dev.atkbdc.0.%pnpinfo: _HID=PNP0303 _UID=0 dev.atkbdc.0.%parent: acpi0 dev.atkbd.0.%desc: AT Keyboard dev.atkbd.0.%driver: atkbd dev.atkbd.0.%parent: atkbdc0 dev.psmcpnp.0.%desc: PS/2 mouse port dev.psmcpnp.0.%driver: psmcpnp dev.psmcpnp.0.%location: handle=\_SB_.PCI0.LPC_.MOU_ dev.psmcpnp.0.%pnpinfo: _HID=IBM0057 _UID=0 dev.psmcpnp.0.%parent: acpi0 dev.psm.0.%desc: PS/2 Mouse dev.psm.0.%driver: psm dev.psm.0.%parent: atkbdc0 dev.fdc.0.%desc: Enhanced floppy controller dev.fdc.0.%driver: fdc dev.fdc.0.%location: handle=\_SB_.PCI0.LPC_.FDC_ dev.fdc.0.%pnpinfo: _HID=PNP0700 _UID=0 dev.fdc.0.%parent: acpi0 dev.sio.0.%desc: 16550A-compatible COM port dev.sio.0.%driver: sio dev.sio.0.%location: handle=\_SB_.PCI0.LPC_.UART dev.sio.0.%pnpinfo: _HID=PNP0501 _UID=0 dev.sio.0.%parent: acpi0 dev.sio.0.wake: 0 dev.sio.1.%desc: Generic IRDA-compatible device dev.sio.1.%driver: sio dev.sio.1.%location: handle=\_SB_.PCI0.LPC_.FIR_ dev.sio.1.%pnpinfo: _HID=IBM0071 _UID=0 dev.sio.1.%parent: acpi0 dev.ppc.0.%desc: Standard parallel printer port dev.ppc.0.%driver: ppc dev.ppc.0.%location: handle=\_SB_.PCI0.LPC_.LPT_ dev.ppc.0.%pnpinfo: _HID=PNP0400 _UID=0 dev.ppc.0.%parent: acpi0 dev.ppbus.0.%desc: Parallel port bus dev.ppbus.0.%driver: ppbus dev.ppbus.0.%parent: ppc0 dev.plip.0.%desc: PLIP network interface dev.plip.0.%driver: plip dev.plip.0.%parent: ppbus0 dev.lpt.0.%desc: Printer dev.lpt.0.%driver: lpt dev.lpt.0.%parent: ppbus0 dev.ppi.0.%desc: Parallel I/O dev.ppi.0.%driver: ppi dev.ppi.0.%parent: ppbus0 dev.acpi_cmbat.0.%desc: Control Method Battery dev.acpi_cmbat.0.%driver: acpi_cmbat dev.acpi_cmbat.0.%location: handle=\_SB_.PCI0.LPC_.EC__.BAT0 dev.acpi_cmbat.0.%pnpinfo: _HID=PNP0C0A _UID=0 dev.acpi_cmbat.0.%parent: acpi0 dev.acpi_acad.0.%desc: AC Adapter dev.acpi_acad.0.%driver: acpi_acad dev.acpi_acad.0.%location: handle=\_SB_.PCI0.LPC_.EC__.AC__ dev.acpi_acad.0.%pnpinfo: _HID=ACPI0003 _UID=0 dev.acpi_acad.0.%parent: acpi0 dev.orm.0.%desc: ISA Option ROMs dev.orm.0.%driver: orm dev.orm.0.%parent: isa0 dev.pmtimer.0.%driver: pmtimer dev.pmtimer.0.%parent: isa0 dev.sc.0.%desc: System console dev.sc.0.%driver: sc dev.sc.0.%parent: isa0 dev.vga.0.%desc: Generic ISA VGA dev.vga.0.%driver: vga dev.vga.0.%parent: isa0 hptmv.status: RocketRAID 182x SATA Controller driver Version 1.1 --------------000101030302090306090502-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 10:47:11 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6340916A4CE for ; Thu, 3 Mar 2005 10:47:11 +0000 (GMT) Received: from msg-mx0.usc.edu (msg-mx0.usc.edu [128.125.137.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CD0643D2F for ; Thu, 3 Mar 2005 10:47:11 +0000 (GMT) (envelope-from ary834@gmail.com) Received: from [192.168.0.109] ([24.30.100.180]) by msg-mx0.usc.edu (Sun Java System Messaging Server 6.1 HotFix 0.08 (built Dec 8 2004)) with ESMTPA id <0ICR004X5VAM6X30@msg-mx0.usc.edu> for freebsd-hackers@freebsd.org; Thu, 03 Mar 2005 02:47:11 -0800 (PST) Date: Thu, 03 Mar 2005 02:47:10 -0800 From: ARY Sender: amitky@usc.edu To: freebsd-hackers@freebsd.org Message-id: <4226EB2E.7080507@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) Subject: Collecting data in userland from kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 10:47:11 -0000 Hello hackers, I am new to FreeBSD but I am familiar with Unix like systems in general and Linux in particular. I am doing a project where-in I need to manipulate a few things in the mbuf's of network stack (mainly in TCP) and capture per packet statistics. Then the collated data has to be passed on to userspace. I have two queries regarding this. First one is in general abt the method to be followed, I have the following ideas Please provide your suggestion on them also if you consider some other approach would be better then please do suggest. 1. Writing to a virtual device: This looks a very good option for me because it is light weight and should be straight forward to implement 2. A ring buffer in kernel: Something like libpcap does. should be good. 3. Writing to syslogger: not very attractive to me because it is mainly a common place for all modules and I dont have complete control over it. 4. Writing to a file: I dont think this is feasible because it is not appropriate to do costly I/O in kernel mode and also it is a cumbersome task. Your say on the above ??? Any other approach(s) ???? Plzz let me know. Second, as I said I am a newbie for FreeBSD, can somebody please point me to resources/docs for writing a virtual device. I read the chapter 13 in the Handbook, but it would be helpful if a document provide some info about interacting with a device from the kernel. TIA, Best Regards, Amit From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 10:56:51 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5B5316A4CE for ; Thu, 3 Mar 2005 10:56:51 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53ECA43D41 for ; Thu, 3 Mar 2005 10:56:51 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so333741rnf for ; Thu, 03 Mar 2005 02:56:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=s158FbAr5190SbcfPIL5rX5Xib5dkMpk+GueJ8+VvLnawYXTj/bIHlMP5cJatFJxNKefzNoO5Rw75fzb2bw1/BRKzTXiptWZjKUQusL2H8w49tS76waJv/IM4V566ixoToAVJwCizy+cDIOkU3tdQ84cMQ9UiNspRN92KpoLLzg= Received: by 10.38.164.43 with SMTP id m43mr221233rne; Thu, 03 Mar 2005 02:56:13 -0800 (PST) Received: by 10.38.209.22 with HTTP; Thu, 3 Mar 2005 02:56:13 -0800 (PST) Message-ID: <84dead7205030302567a0e7103@mail.gmail.com> Date: Thu, 3 Mar 2005 10:56:13 +0000 From: Joseph Koshy To: ARY In-Reply-To: <4226EB2E.7080507@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4226EB2E.7080507@gmail.com> cc: freebsd-hackers@freebsd.org Subject: Re: Collecting data in userland from kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 10:56:51 -0000 > First one is in general abt the method to be followed, I > have the following ideas ... [snip] Have you looked at netgraph(4) and ng_socket(4)? -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 11:45:57 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5901516A4CE; Thu, 3 Mar 2005 11:45:57 +0000 (GMT) Received: from mxsf22.cluster1.charter.net (mxsf22.cluster1.charter.net [209.225.28.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCDA343D48; Thu, 3 Mar 2005 11:45:56 +0000 (GMT) (envelope-from c0ldbyte@myrealbox.com) Received: from mxip08.cluster1.charter.net (mxip08a.cluster1.charter.net [209.225.28.138])j23Bjtv6009396; Thu, 3 Mar 2005 06:45:55 -0500 Received: from 24.247.253.134.gha.mi.chartermi.net (HELO eleanor.us1.wmi.uvac.net) (24.247.253.134) by mxip08.cluster1.charter.net with ESMTP; 03 Mar 2005 06:45:55 -0500 X-Ironport-AV: i="3.90,132,1107752400"; d="scan'208"; a="652692347:sNHT15291486" Date: Thu, 3 Mar 2005 06:45:52 -0500 (EST) From: c0ldbyte To: Saber Zrelli In-Reply-To: <4226B122.4090607@jaist.ac.jp> Message-ID: <20050303064515.U470@eleanor.us1.wmi.uvac.net> References: <4226B122.4090607@jaist.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-scsi@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: system temperature too high, shutting down soon! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 11:45:57 -0000 On Thu, 3 Mar 2005, Saber Zrelli wrote: > Hi all , > > I'm runnig FreeBSD 5.3-RELEASE #0 on an IBM Thinkpad R50p , > when I run some make install in the ports distribution. > > I got the following message : > tornado root: WARNING: system temperature too high, shutting down soon! > > After 2-3 secs the system shuts down. > > when I looked in /var/log/messages after booting , I found : > Mar 2 21:24:18 tornado kernel: cpu0: Performance states changed > Mar 2 21:24:39 tornado kernel: cpu0: Performance states changed > Mar 2 21:24:39 tornado root: WARNING: system temperature too high, shutting > down soon! > > I was using 5.3 CURRENT ( and previous releases ) a while before , and I did > not have this problem. > > my first thoughts is that it is a ACIP problem. but I dont have knowledge > about ACPI stuff. > > I think that some parameters in hw.acpi.thermal are not correct. > > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.tz0.temperature: 3312 > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: 3647 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 3672 > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > specially hw.acpi.thermal.tz0._ACx , there is no cooling level > temperatures defined. > Also , the hw.acpi.thermal.tz0._CRT: 3672 ,hw.acpi.thermal.tz0._PSV: 3647 are > too close , > the cpu don't have enough time to cool down before reaching the critical > temp. > > I tried debugging the ACPI module , so I compiled it with debuggin options . > but the kernel could not load it and I was running without acpi. > > I attached < sysctl -a > and < cat /var/log/messages > > > I want to keep using ACPI , and I really need to fix this. > > For any suggestions , > > Many thanks > > -- > Saber. > options CPU_ENABLE_TCC ? This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 12:05:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E9FD16A4CE for ; Thu, 3 Mar 2005 12:05:06 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59C2543D48 for ; Thu, 3 Mar 2005 12:05:05 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j23C4tHw089331 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 3 Mar 2005 13:04:57 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j23C4R55017269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2005 13:04:27 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j23C4QJT010696; Thu, 3 Mar 2005 13:04:26 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j23C4Mn0010694; Thu, 3 Mar 2005 13:04:22 +0100 (CET) (envelope-from ticso) Date: Thu, 3 Mar 2005 13:04:22 +0100 From: Bernd Walter To: Poul-Henning Kamp Message-ID: <20050303120421.GW86348@cicely12.cicely.de> References: <20050302162928.0916237012@arioch.imrryr.org> <2759.1109809815@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2759.1109809815@critter.freebsd.dk> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=no version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: tech-security@NetBSD.org cc: Roland Dowdeswell cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 12:05:06 -0000 On Thu, Mar 03, 2005 at 01:30:15AM +0100, Poul-Henning Kamp wrote: > In message <20050302162928.0916237012@arioch.imrryr.org>, Roland Dowdeswell wri > tes: > > >Let's discuss a simple example and see how it works. Let's walk > >through a user login, with /etc/passwd on GBDE and the filesystem > >mounted with mtime. > > These days, on the majority of low cost disks used in enduser > configurations you risk looking an entire track if the disk were > writing when you pulled power. (People complain about this, but > doesn't seem to be willing to pay to avoid it.) No matter what disk you take - writes never have been atomic. The major difference I see is that you get a read error back in the disk failure case, while such a crypto failure produces more or less random data without any error. Mounting unclean filesystems rw for bg_fsck can be considered dangerous with such unexpected data corruption. And how would you know that a restore from backup is required for a damaged file? -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 12:18:48 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2941A16A4CE for ; Thu, 3 Mar 2005 12:18:48 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E64D43D31 for ; Thu, 3 Mar 2005 12:18:47 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23CIjZ8007154; Thu, 3 Mar 2005 13:18:45 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: ticso@cicely.de From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 13:04:22 +0100." <20050303120421.GW86348@cicely12.cicely.de> Date: Thu, 03 Mar 2005 13:18:45 +0100 Message-ID: <7153.1109852325@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@NetBSD.org cc: Roland Dowdeswell cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 12:18:48 -0000 In message <20050303120421.GW86348@cicely12.cicely.de>, Bernd Walter writes: >No matter what disk you take - writes never have been atomic. >The major difference I see is that you get a read error back in >the disk failure case, while such a crypto failure produces more or >less random data without any error. >Mounting unclean filesystems rw for bg_fsck can be considered >dangerous with such unexpected data corruption. >And how would you know that a restore from backup is required for >a damaged file? 100% true. The trouble is that it would cost a lot in performance and a doubling in metadata to protect yourself against this. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 12:21:15 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4323F16A4CE for ; Thu, 3 Mar 2005 12:21:15 +0000 (GMT) Received: from fiona.auriga.ru (nivc-100.auriga.ru [80.240.102.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7128F43D46 for ; Thu, 3 Mar 2005 12:21:09 +0000 (GMT) (envelope-from alexey.neyman@auriga.ru) Received: from vagabond.auriga.ru ([80.240.102.246]) by fiona.auriga.ru with Microsoft SMTPSVC(6.0.3790.0); Thu, 3 Mar 2005 15:25:29 +0300 From: Alexey Neyman Organization: Auriga To: ticso@cicely.de Date: Thu, 3 Mar 2005 15:21:03 +0300 User-Agent: KMail/1.6.2 References: <20050302162928.0916237012@arioch.imrryr.org> <2759.1109809815@critter.freebsd.dk> <20050303120421.GW86348@cicely12.cicely.de> In-Reply-To: <20050303120421.GW86348@cicely12.cicely.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503031521.03380.alex.neyman@auriga.ru> X-OriginalArrivalTime: 03 Mar 2005 12:25:29.0385 (UTC) FILETIME=[161FC190:01C51FEC] cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 12:21:15 -0000 I think the original author expressed the following concern: - without the GBDE, a failure to write meta-data for a file (say, 'atime' for /etc/passwd) will not result in an unusable system. Whether it was written or not does not matter much: either way, the links to actual file blocks remain intact, and the file itself is preserved. - with the GBDE, updating atime on /etc/passwd could result in a mismatch between the key to a certain sector (containing the inode for /etc/passwd) and the sector itself. This way, one won't be able to decrypt the sector and all information in that sector (including the pointers to file blocks) is lost. Regards, Alexey. On Thursday 03 March 2005 15:04, Bernd Walter wrote: > On Thu, Mar 03, 2005 at 01:30:15AM +0100, Poul-Henning Kamp wrote: > > In message <20050302162928.0916237012@arioch.imrryr.org>, Roland Dowdeswell wri > > tes: > > > > >Let's discuss a simple example and see how it works. Let's walk > > >through a user login, with /etc/passwd on GBDE and the filesystem > > >mounted with mtime. > > > > These days, on the majority of low cost disks used in enduser > > configurations you risk looking an entire track if the disk were > > writing when you pulled power. (People complain about this, but > > doesn't seem to be willing to pay to avoid it.) > > No matter what disk you take - writes never have been atomic. > The major difference I see is that you get a read error back in > the disk failure case, while such a crypto failure produces more or > less random data without any error. > Mounting unclean filesystems rw for bg_fsck can be considered > dangerous with such unexpected data corruption. > And how would you know that a restore from backup is required for > a damaged file? > > -- > B.Walter BWCT http://www.bwct.de > bernd@bwct.de info@bwct.de > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- We are intelligent and clever, though you would never call us cunning. -- Spathi, SC2 From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 12:32:01 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D45C116A4CE for ; Thu, 3 Mar 2005 12:32:01 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A28F43D31 for ; Thu, 3 Mar 2005 12:32:01 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j23CVuHw090594 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 3 Mar 2005 13:31:58 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j23CVc55017406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2005 13:31:39 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j23CVcHX010800; Thu, 3 Mar 2005 13:31:38 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j23CVYB8010799; Thu, 3 Mar 2005 13:31:34 +0100 (CET) (envelope-from ticso) Date: Thu, 3 Mar 2005 13:31:34 +0100 From: Bernd Walter To: Poul-Henning Kamp Message-ID: <20050303123133.GX86348@cicely12.cicely.de> References: <20050303120421.GW86348@cicely12.cicely.de> <7153.1109852325@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7153.1109852325@critter.freebsd.dk> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=no version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: tech-security@NetBSD.org cc: Roland Dowdeswell cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 12:32:01 -0000 On Thu, Mar 03, 2005 at 01:18:45PM +0100, Poul-Henning Kamp wrote: > In message <20050303120421.GW86348@cicely12.cicely.de>, Bernd Walter writes: > > >No matter what disk you take - writes never have been atomic. > >The major difference I see is that you get a read error back in > >the disk failure case, while such a crypto failure produces more or > >less random data without any error. > >Mounting unclean filesystems rw for bg_fsck can be considered > >dangerous with such unexpected data corruption. > >And how would you know that a restore from backup is required for > >a damaged file? > > 100% true. > > The trouble is that it would cost a lot in performance and a doubling > in metadata to protect yourself against this. Keeping the old and new key together with an digest from both encrypted contents until we have an acknowledge from backing store would really help. RAID syncronity is the same problem - at least you want to know which blocks are possibly asyncron for a quick boot phase. Todays computers are still missing general purpose NVRAM for those bookkeeping :( Without NVRAM all you can do is using a disk block for it and accept the performance hit or live with the risk. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 15:41:19 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0651716A4CE for ; Wed, 2 Mar 2005 15:41:19 +0000 (GMT) Received: from fw1.caa.army.mil (fw1.caa.army.mil [192.153.92.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6027343D2F for ; Wed, 2 Mar 2005 15:41:18 +0000 (GMT) (envelope-from ed.smithiii@us.army.mil) Received: from CAA-UNCLMAIL.caa.army.mil (caa-unclmail.caa.army.mil [192.153.92.29]) by fw1.caa.army.mil with ESMTP id j22FfPDg021401 for ; Wed, 2 Mar 2005 10:41:25 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 2 Mar 2005 10:39:20 -0500 Message-ID: <0A907D6523E90246822D32FA2344E244015ECF@CAA-UNCLMAIL.caa.army.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sched_4BSD Thread-Index: AcUel57q0hnQVlgBQCOGtXy3dByBrwApdMAQ From: "Smith III, Edward Mr. CAA/ISC" To: , X-Mailman-Approved-At: Thu, 03 Mar 2005 13:07:16 +0000 cc: freebsd-hackers@freebsd.org cc: ashcs@ucla.edu Subject: RE: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 15:41:19 -0000 Yes, but you still incur a lot of context switching overhead between the 1000 threads. Increasing the time quantum should give you better throughput with a penalty to interactivity which isn't really an issue if no one is running a graphical desktop. ??? I think...=20 -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freebsd.org] On Behalf Of Julian Elischer Sent: Tuesday, March 01, 2005 2:50 PM To: Sarath Kamisetty Cc: freebsd-hackers@freebsd.org; Ashwin Chandra Subject: Re: sched_4BSD Sarath Kamisetty wrote: >Hi, > >How does Linux handle this ? Any idea ? > =20 > If you make 1000 threads, you get 1000 slots on the scheduler. (last time I looked.. Let me know if I'm wrong). The guy next to you with 'vi' gets 1 slot.. who gets more cpu? >Thanks, >Sarat > >On Mon, 28 Feb 2005 00:26:10 -0800, Julian Elischer wrote: > =20 > >>Ashwin Chandra wrote: >> =20 >> >>>I wanted to get some clarification about the 4BSD scheduler. I am=20 >>>sort of confused why there are two forms of scheduling, one done=20 >>>between processes and another done between threads in a process. The=20 >>>priority calculations seem to be done only with processes and I=20 >>>assume that the global run queue holds processes, not threads. Also=20 >>>why is there only 1 run queue for 1 CPU. What happens to blocked processes and ready to be runned processes? >>> =20 >>> >>Part of the challenge of adding threads to a system is to make it hard >>for a threaded process to "flood" the system run queues so that other=20 >>processes get no cpu time. >> >>The scheme in the current freeBSD schedulers is a "crude" method, by=20 >>which only a limitted number of threads per process are allowed to be=20 >>added to the system run queue. RUnnable hreads fo r aprocess are kept=20 >>on a run queue for the process and only the highest N prioriy hreads=20 >>are actually put on the system run queue. >> >>This is by no means the best way, but rather the easiest way. I am=20 >>hoping that some PhD candidate somewhere will decide that thread=20 >>scheduling is his topic and will figure out a better way of doing=20 >>this. >> >>both run queues hold threads. This is still a place wjere a lot of=20 >>work can be done. >> >>:-) >> >> >> =20 >> >>>Ash >>>_______________________________________________ >>>freebsd-hackers@freebsd.org mailing list=20 >>>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >>> =20 >>> >>_______________________________________________ >>freebsd-hackers@freebsd.org mailing list=20 >>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> >> =20 >> _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 17:19:51 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40E5116A4CF for ; Wed, 2 Mar 2005 17:19:51 +0000 (GMT) Received: from thumbler.kulnet.kuleuven.ac.be (thumbler.kulnet.kuleuven.ac.be [134.58.240.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id B53EB43D2D for ; Wed, 2 Mar 2005 17:19:50 +0000 (GMT) (envelope-from gwyllion@ulyssis.org) Received: from localhost (localhost [127.0.0.1]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id CD7291378C2; Wed, 2 Mar 2005 18:19:49 +0100 (CET) Received: from octavianus.kulnet.kuleuven.ac.be (octavianus.kulnet.kuleuven.ac.be [134.58.240.71]) by thumbler.kulnet.kuleuven.ac.be (Postfix) with ESMTP id 401AA137873; Wed, 2 Mar 2005 18:19:49 +0100 (CET) Received: from [10.33.137.52] (vernam.esat.kuleuven.ac.be [10.33.137.52]) by octavianus.kulnet.kuleuven.ac.be (Postfix) with ESMTP id CDD12AED7F; Wed, 2 Mar 2005 18:19:38 +0100 (CET) Message-ID: <4225F576.7050604@ulyssis.org> Date: Wed, 02 Mar 2005 18:18:46 +0100 From: Dries Schellekens User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ALeine References: <200503010320.j213KI8U047666@marlena.vvi.at> In-Reply-To: <200503010320.j213KI8U047666@marlena.vvi.at> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by KULeuven Antivirus Cluster X-Mailman-Approved-At: Thu, 03 Mar 2005 13:07:16 +0000 cc: freebsd-hackers@freebsd.org cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 17:19:51 -0000 ALeine wrote: > Algebraic attacks on AES show that AES may indeed be broken sooner than > we would hope, at least according to the information at: > > http://www.cryptosystem.net/aes/ Please stop referring to this website. Sorry, but everybody in the field of cryptology, except Nicolas Courtois, agree that algebraic attacks on AES don't work. To quote Vincent Rijmen: "The XSL attack is not an attack. It is a dream." Please read * http://eprint.iacr.org/2004/112 * http://www.inria.fr/rrrt/rr-5251.html * Claus Diem also has a paper that proofs XL/XSL does not work, but it is not online. Cheers, Dries From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 2 21:13:24 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15C3216A4CE for ; Wed, 2 Mar 2005 21:13:24 +0000 (GMT) Received: from mailtest.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id D082E43D53 for ; Wed, 2 Mar 2005 21:13:23 +0000 (GMT) (envelope-from fcash-ml@sd73.bc.ca) Received: from localhost (localhost [127.0.0.1]) by mailtest.sd73.bc.ca (Postfix) with ESMTP id ECDC4F1839 for ; Wed, 2 Mar 2005 13:13:23 -0800 (PST) Received: from mailtest.sd73.bc.ca ([127.0.0.1]) by localhost (mailtest.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 59450-01-27 for ; Wed, 2 Mar 2005 13:13:23 -0800 (PST) Received: from s9.sbo (s9.sbo [192.168.0.9]) by mailtest.sd73.bc.ca (Postfix) with ESMTP id 50F5BF181C for ; Wed, 2 Mar 2005 13:13:23 -0800 (PST) From: Freddie Cash Organization: School District 73 - Kamloops, BC To: freebsd-hackers@freebsd.org Date: Wed, 2 Mar 2005 13:13:22 -0800 User-Agent: KMail/1.7.2 References: <20050302172559.99964.qmail@web52702.mail.yahoo.com> <42261D95.9020506@elischer.org> In-Reply-To: <42261D95.9020506@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503021313.22606.fcash-ml@sd73.bc.ca> X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca X-Mailman-Approved-At: Thu, 03 Mar 2005 13:07:16 +0000 Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 21:13:24 -0000 On March 2, 2005 12:09 pm, Julian Elischer wrote: > NPTL? > New Pthreads Library from Library? > isn't that GPL'd? Native Posix Threads Library All I know about it is the name. :) -- Freddie Cash, CCNT CCLP Helpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] fcash-ml@sd73.bc.ca From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 01:10:07 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 796A816A4CE for ; Thu, 3 Mar 2005 01:10:07 +0000 (GMT) Received: from cowbert.2y.net (d46h180.public.uconn.edu [137.99.46.180]) by mx1.FreeBSD.org (Postfix) with SMTP id B22A643D46 for ; Thu, 3 Mar 2005 01:10:06 +0000 (GMT) (envelope-from sirmoo@cowbert.2y.net) Received: (qmail 606 invoked by uid 1001); 3 Mar 2005 01:10:05 -0000 Date: Wed, 2 Mar 2005 20:10:05 -0500 From: "Peter C. Lai" To: ALeine Message-ID: <20050303011005.GA446@cowbert.2y.net> References: <200502261702.j1QH2Emp093865@marlena.vvi.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502261702.j1QH2Emp093865@marlena.vvi.at> User-Agent: Mutt/1.5.6i X-Mailman-Approved-At: Thu, 03 Mar 2005 13:07:16 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: sandisk cruzer mini quirks [failure] on RELENG_4 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 01:10:07 -0000 On Sat, Feb 26, 2005 at 09:02:14AM -0800, ALeine wrote: > sirmoo@cowbert.2y.net wrote: > > > I did this as the first hack. It made the problem worse. I'll try > > patching both umass.c and scsi_da.c maybe they will have some sort of > > synergistic effect. > Adding DA_Q_NO_SYNC_CACHE in scsi_da.c in conjunction with IGNORE_RESIDUE in umass.c makes the problem worse; see below. > You said the problem occurs only when you copy files to the device using > cp(1) and not dd(1). The main difference between how cp(1) and dd(1) copy > files (other than cp(1) mmap(2)-ing files which are <= 8 Mb in size) > is that cp(1) copies files in 64kb (MAXBSIZE) chunks while dd(1) copies > files in 512 byte chunks by default. They both use read(2) and write(2), > so I would suggest using dd with bs=64k and then applying the bisection > method to find the largest transfer block size for writing the device > can handle. > > Does this problem occur with cpdup (ports/sysutils/cpdup) as well? > It currently copies files in 32kb chunks, which could easily be changed > since the transfer block size is set in a single place. You may want to > patch cpdup to use the maximum transfer block size the device can handle > as a temporary workaround and then use cpdup for copying files to the > device. > I am unable to keep the device (and system) consistently stable with bs > 512. Any larger blocksizes, and the device will crash at least 25% of the time. With DA_Q_NO_SYNC_CACHE in place, the device is no longer consistently stable even with 512 byte blocksizes. cp(1) works better than without cache syncing, but cp(1) will still take the box down often. Turning on usb debugging just shows that the write fails and umass is unable to clear the stall as the device will subsequently timeout. It is notable that the usb subsystem mallocs and frees 8192 bytes per transaction by default. At the end of the transfer, it steps down to 4096 and 2048 byte allocations during the cleanup. However, when the device stalls on a transfer (dd bs > 512), the stall can occur in the middle of a file, not just at the end of the transfer. > > maybe i should just bite the bullet and upgrade the box to 5.3. > > Let's hope you won't have to. :-) Can you verify that this problem does > not occur on 5.x without upgrading (by using a FreeSBIE LiveCD)? Well, RELENG_5 is now frozen, with lots of commits in the past week. 5.3 is now technically "old", so it probably doesn't matter if I try. I will be getting new hardware to install RELENG_5 on next week, so I can test it on that, and anything needing to be patched will have to go into 5.5. Someone else said that their PNY pendrive no longer crashes their RELENG_5 box after a recent world remake, but I am too unfamiliar with how all the subsystems work together to say if it is a difference in usb or cam or something entirely unrelated; and I am too lazy to compare code side-by-side. (I'm not even a real(tm) C programmer, I just play one on TV!) Something I noted in a recent umass.c commit[1] was code that looks like it tells the scsi subsystem to abort all write attempts to umass if usbd reports the device is disconnected; this might prevent two things: 1. the usb subsystem currently gets stuck in a loop trying to clear the stall. 2. the kernel panic that now happens if you remove the pendrive at this point. [1] http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/umass.c.diff?r1=1.118&r2=1.119 -- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 13:36:54 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57B4416A4CE for ; Thu, 3 Mar 2005 13:36:54 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD88243D46 for ; Thu, 3 Mar 2005 13:36:53 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j23DaFoQ016548; Thu, 3 Mar 2005 08:36:15 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j23DaF76016547; Thu, 3 Mar 2005 08:36:15 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 3 Mar 2005 08:36:15 -0500 From: David Schultz To: Julian Elischer Message-ID: <20050303133615.GA16479@VARK.MIT.EDU> Mail-Followup-To: Julian Elischer , Ashwin Chandra , freebsd-hackers@FreeBSD.ORG References: <001a01c51d6d$d50ce500$abe243a4@ash> <4222D5A2.9010301@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4222D5A2.9010301@elischer.org> cc: freebsd-hackers@FreeBSD.ORG cc: Ashwin Chandra Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 13:36:54 -0000 On Mon, Feb 28, 2005, Julian Elischer wrote: > Ashwin Chandra wrote: > >I wanted to get some clarification about the 4BSD scheduler. I am sort of > >confused why there are two forms of scheduling, one done between processes > >and > >another done between threads in a process. The priority calculations seem > >to be > >done only with processes and I assume that the global run queue holds > >processes, > >not threads. Also why is there only 1 run queue for 1 CPU. What happens to > >blocked processes and ready to be runned processes? > > Part of the challenge of adding threads to a system is to make it hard for > a threaded process to "flood" the system run queues so that other processes > get no cpu time. > > The scheme in the current freeBSD schedulers is a "crude" method, by which > only a limitted number of threads per process are allowed to be added to > the system run queue. RUnnable hreads fo r aprocess are kept on a run queue > for the process and only the highest N prioriy hreads are actually put on > the > system run queue. > > This is by no means the best way, but rather the > easiest way. I am hoping that some PhD candidate somewhere will decide > that thread scheduling is his topic and will figure out a better way > of doing this. I think most of the PhD theses in that area were written over a decade ago. ;-) Carl Waldspurger comes to mind in particular. The UC Berkeley CSUA, which runs a shell box often supporting hundreds of simultaneous users, implemented one of those ideas in FreeBSD 4.X a long time ago. The basic idea, called lottery scheduling, is that each user gets some number of tickets, say 1000. Users use their tickets to ``fund'' their processes, and each process in the system gets a share of the CPU proportional to the number of tickets it has. Their algorithm is randomized, but more sophistocated approaches such as stride scheduling are deterministic. Patches are available at: http://www.csua.berkeley.edu/computing/software/lottery-sched.html One of the nice features of something like this over standard Unix priority scheduling is that problems such as starvation just don't happen. The ticket quota idea is also a nice way to deal with the problem you mention. IIRC, Luigi had a weighted fair queuing scheduler for 4.X as well. This is basically the same idea viewed from a networking person's point of view. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 14:34:35 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C81B16A4CE; Thu, 3 Mar 2005 14:34:35 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2698843D41; Thu, 3 Mar 2005 14:34:35 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j23Eafwm004382; Thu, 3 Mar 2005 07:36:41 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <42271FF6.9040103@samsco.org> Date: Thu, 03 Mar 2005 07:32:22 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alfred Perlstein References: <20050302212102.GK11079@elvis.mu.org> In-Reply-To: <20050302212102.GK11079@elvis.mu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: hackers@freebsd.org Subject: Re: truss bug + PATCH, pls review X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 14:34:35 -0000 Alfred Perlstein wrote: > Can someone review this? I think 'u' is incorrectly > added to instead of assigned to. This causes the initial > calculation to be garage based and screws up displaying > poll information. > > I'd like this to be MFC'd before 5.4 if possible. > > Index: syscalls.c > =================================================================== > RCS file: /home/ncvs/src/usr.bin/truss/syscalls.c,v > retrieving revision 1.45 > diff -u -r1.45 syscalls.c > --- syscalls.c 5 Sep 2004 05:27:30 -0000 1.45 > +++ syscalls.c 2 Mar 2005 21:19:13 -0000 > @@ -414,7 +414,7 @@ > (POLLIN | POLLPRI | POLLOUT | POLLERR | POLLHUP | POLLNVAL | \ > POLLRDNORM |POLLRDBAND | POLLWRBAND | POLLINIGNEOF) > > - u += snprintf(tmp + used, per_fd, > + u = snprintf(tmp + used, per_fd, > "%s%d 0x%hx%s%s%s%s%s%s%s%s%s ", > i > 0 ? " " : "", > pfd[i].fd, > > I agree with your analysis. Scott From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 15:01:34 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB18916A4CE for ; Thu, 3 Mar 2005 15:01:34 +0000 (GMT) Received: from msg-mx0.usc.edu (msg-mx0.usc.edu [128.125.137.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8561943D39 for ; Thu, 3 Mar 2005 15:01:34 +0000 (GMT) (envelope-from ary834@gmail.com) Received: from [192.168.0.109] ([24.30.100.180]) by msg-mx0.usc.edu (Sun Java System Messaging Server 6.1 HotFix 0.08 (built Dec 8 2004)) with ESMTPA id <0ICS0048N29D6N60@msg-mx0.usc.edu> for freebsd-hackers@freebsd.org; Thu, 03 Mar 2005 05:17:43 -0800 (PST) Date: Thu, 03 Mar 2005 05:17:33 -0800 From: ARY In-reply-to: <84dead7205030302567a0e7103@mail.gmail.com> Sender: amitky@usc.edu To: Joseph Koshy Message-id: <42270E6D.8060509@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <4226EB2E.7080507@gmail.com> <84dead7205030302567a0e7103@mail.gmail.com> User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) cc: freebsd-hackers@freebsd.org Subject: Re: Collecting data in userland from kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 15:01:34 -0000 Joseph, > > Have you looked at netgraph(4) and ng_socket(4)? > Thanx for the reply. I looked into them now. But looks like it will be an overkill for me. Let me give a little more context of my problem. I need to evaluate a new congestion control protocol (which has been implemented as an extension to TCP) on a test-bed. So, everytime a packet is sent I just need to log a set a parameters, this applies to hosts and routers. All the logs are then analyzed offline by another application. So, there is primarily no interaction between my entities either in/between hosts or routers. Hence, I need to insert log stubs inline in the kernel. Hope, things are a little clearer now. Please let me know if have any other suggestions. Also, let me know if you still think netgraph can help and I have got it wrong. Thanks, Amit From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 15:05:40 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16ED616A4CE for ; Thu, 3 Mar 2005 15:05:40 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id A544643D2D for ; Thu, 3 Mar 2005 15:05:39 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j22JAQoH081225; Wed, 2 Mar 2005 11:10:28 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j22JAGCH081224; Wed, 2 Mar 2005 11:10:16 -0800 (PST) (envelope-from www) Date: Wed, 2 Mar 2005 11:10:16 -0800 (PST) Message-Id: <200503021910.j22JAGCH081224@marlena.vvi.at> To: phk@phk.freebsd.dk From: "ALeine" cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 15:05:40 -0000 phk@phk.freebsd.dk wrote: > In message <20050303120421.GW86348@cicely12.cicely.de>, Bernd > Walter writes: > > >And how would you know that a restore from backup is required > >for a damaged file? > > 100% true. > > The trouble is that it would cost a lot in performance and a > doubling in metadata to protect yourself against this. Not necessarily, if one were to implement the ideas I proposed I believe the performance could be kept at the same level as now. To summarize my ideas: 1. Introduction of journaling I described this idea in detail here: http://docs.FreeBSD.org/cgi/mid.cgi?200502282202.j1SM21qs042751 The user would decide how many key sectors would be using a single key shadow sector, for example, 1 key shadow sector for every 8 key sectors. That would add only 1/8th (12.5%) in metadata size and 1/264th (0.38%) overall. On a 400 Gb disk this would be 1.5 Gb. 264 = 8 * (32 data sectors + 1 key sector) Then a kernel sysctl variable would control whether journaling is enabled or not (kern.geom.bde.atomic_writes_enabled). Now there are two possibilities: either make journaling a volume initialization option: if you specify it the key shadow sectors are allocated, otherwise not (kern.geom.bde.atomic_writes_enabled is ignored, which might make someone falsely believe that they have journaling on a volume that was not initialized for it) or make it possible to turn journaling on later by allocating key shadow sectors by default (so they are used according to kern.geom.bde.atomic_writes_enabled). One could even implement a totally automatic fsck(8) recovery of incomplete writes by storing the HMAC of the last written data sector inside the shadow key sector, there is plenty of room for it there. This way one would get data integrity and automatically recoverable volumes without having to store the HMAC for every data sector, in the example I stated above there would be one HMAC (shadow key sector) place holder protecting 256 data sectors. 2. Introduction of per-key sector grouping This would be set at volume initialization, the user would set the number of sectors that are to be encrypted with the same key. Based on this one could also increase the key size as long as all the keys for a zone fit inside one sector (for example, by having two sectors encrypted with the same key one could already use AES256). 3. Introduction of control over key regeneration cycle There would be a sysctl variable to control after how many writes the key is regenerated (kern.geom.bde.key_regeneration_on_write_cycle). This would speed things up quite a bit and users would be allowed to decide what is more important to them in terms of speed and assumed security. If all this were implemented I believe the performance on volumes initialized to take advantage of the possible speedups would not be worse than with the current implementation of GBDE. Comments? ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 16:31:44 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F169516A4CE for ; Thu, 3 Mar 2005 16:31:44 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20A3143D2F for ; Thu, 3 Mar 2005 16:31:44 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23GVYrg008707; Thu, 3 Mar 2005 17:31:34 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "ALeine" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 02 Mar 2005 11:10:16 PST." <200503021910.j22JAGCH081224@marlena.vvi.at> Date: Thu, 03 Mar 2005 17:31:34 +0100 Message-ID: <8706.1109867494@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 16:31:45 -0000 In message <200503021910.j22JAGCH081224@marlena.vvi.at>, "ALeine" writes: >Not necessarily, if one were to implement the ideas I proposed >I believe the performance could be kept at the same level as now. I gave up on journalling myself because IMO it complicates things a lot and the problem it solves is very very small. The impact in disk seeks is non-trivial to predict, but it is very hard to argue that it will not lead to an increase in disk seeks. (This is really a variant of the age old argument between jounaling filesystems and "traditional" filesystems) I can only recommend that you try :-) We need more ideas and more people trying out ideas. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 16:39:35 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46C8A16A4CE for ; Thu, 3 Mar 2005 16:39:35 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E17A43D31 for ; Thu, 3 Mar 2005 16:39:33 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j23GaKdF010558; Thu, 3 Mar 2005 09:36:20 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 03 Mar 2005 09:36:42 -0700 (MST) Message-Id: <20050303.093642.115935187.imp@bsdimp.com> To: joseph.koshy@gmail.com From: "M. Warner Losh" In-Reply-To: <84dead7205030302567a0e7103@mail.gmail.com> References: <4226EB2E.7080507@gmail.com> <84dead7205030302567a0e7103@mail.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: ary834@gmail.com cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Collecting data in userland from kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 16:39:35 -0000 In message: <84dead7205030302567a0e7103@mail.gmail.com> Joseph Koshy writes: : > First one is in general abt the method to be followed, I : > have the following ideas ... [snip] : : Have you looked at netgraph(4) and ng_socket(4)? Or bpf(4)? Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 16:47:49 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A483316A4CE for ; Thu, 3 Mar 2005 16:47:49 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id D42CC43D48 for ; Thu, 3 Mar 2005 16:47:46 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23GljcX008838; Thu, 3 Mar 2005 17:47:45 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: tls@rek.tjls.com From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 10:48:47 EST." <20050303154847.GA3454@panix.com> Date: Thu, 03 Mar 2005 17:47:45 +0100 Message-ID: <8837.1109868465@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 16:47:49 -0000 In message <20050303154847.GA3454@panix.com>, Thor Lancelot Simon writes: >No, it would not. What it _would_ take would be an abandonment of the >adamant position that your home-grown cryptosystem is superior to >simply encrypting the disk with 256-bit AES. Where I come from "home-grown" is not derogative. All cryptosystems are by necessity home-grown for somebody somewhere. If you are _convinced_ that there will be no attacks which can exploit the ample data CGD offers for two-way leverage on the crypto algorithm during the relevant lifetime of your data, then stick with CGD and be happy. If like me that makes you quite uneasy, look for something which mitigates that issue, like for instance GBDE. If neither suits you, design your own. >Generally, complexity is not considered a desirable property in >cryptosystems. GBDE violates this rule in spades. There are _reasons_ >why complexity is not good: to begin with, a very complex cryptographic >construct will require detailed analysis (which it does not appear >GBDE has had by anyone but its author until Roland started looking at >it) in order that we may know that it is even as secure as the underlying >algorithmic building blocks it uses. Both Lucky Green and David Wagner has nodded vertical on GBDE. >[crypto sermon] I fully agree with you about the philosophical points, but not on the implications. I can not convince myself that encrypting a 40 GB disk sector by sector using the same key, even if it is 256 bits, is a safe design. You seem to belive otherwise. And that's where it ends. Have a good life. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 16:49:39 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0CF416A4CE for ; Thu, 3 Mar 2005 16:49:39 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0517443D31 for ; Thu, 3 Mar 2005 16:49:39 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23GncZ8009010; Thu, 3 Mar 2005 17:49:38 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: tls@rek.tjls.com From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 11:37:31 EST." <20050303163731.GA8001@panix.com> Date: Thu, 03 Mar 2005 17:49:38 +0100 Message-ID: <9009.1109868578@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@netbsd.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 16:49:40 -0000 In message <20050303163731.GA8001@panix.com>, Thor Lancelot Simon writes: >I could not disagree more. When it comes to nonstandard homebrewed >cryptosystems foisted off on unsuspecting users with a bundle of >claims of algorithm strength that they're not competent to evaluate >for themselves, we do not need more ideas, nor more people trying >out ideas; we need less. > >Standard, widely analyzed cryptographic algorithms are good. s/ are good/, when applied with caution and wisdom, are good/ :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 16:59:38 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5356B16A4CE for ; Thu, 3 Mar 2005 16:59:38 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E8B943D3F for ; Thu, 3 Mar 2005 16:59:37 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id 26C633700F; Thu, 3 Mar 2005 11:59:18 -0500 (EST) To: "Poul-Henning Kamp" In-reply-to: Your message of "Thu, 03 Mar 2005 01:30:15 +0100." <2759.1109809815@critter.freebsd.dk> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Thu, 03 Mar 2005 11:59:18 -0500 From: Roland Dowdeswell Message-Id: <20050303165918.26C633700F@arioch.imrryr.org> cc: tech-security@NetBSD.org cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 16:59:38 -0000 On 1109809815 seconds since the Beginning of the UNIX epoch "Poul-Henning Kamp" wrote: > >In message <20050302162928.0916237012@arioch.imrryr.org>, Roland Dowdeswell wr >i >tes: > >>Let's discuss a simple example and see how it works. Let's walk >>through a user login, with /etc/passwd on GBDE and the filesystem >>mounted with mtime. > >These days, on the majority of low cost disks used in enduser >configurations you risk looking an entire track if the disk were >writing when you pulled power. (People complain about this, but >doesn't seem to be willing to pay to avoid it.) > >So the cummulative increase of risk from using GBDE doesn't really >register on the radar for people. > >And therein lies a very important lesson for you: It may not be a >100% theoretical ironclad guarantee, because few people are prepared >to pay for that in the first place. What if I am running GBDE over raid? I would then have some expectation of reliability which would be counter-intuitively absent. With GBDE, even if I am willing to pay for reliability I will not find it. But, I will not know that it is absent because this behaviour is undocumented. I think that at the very least a note should be added to the GBDE man page that indicates that it reduces the reliability of the file system on it so that people designing production systems will not use it. In FreeBSD and NetBSD, a lot of effort has been put into making the system as reliable as possible, e.g. soft-updates. The results are quite impressive. Both operating systems are quite reliable. A lot of very good work has been done, and some quite difficult problems have been tackled. I cannot understand this completely dismissive attitude about reliability on this one topic. Why do we bother with soft-updates if we are willing to break the underlying systems? >The difference between CGD and GBDE in this area is that for CGD >it is not convincibly shown that it is the only feasible attack >(because you use the same key for all sectors thus exposing the >ciphers possible weaknesses big time), for GBDE everybody so far >agrees that the key is the only feasible attack. Not everybody. I have spoken with a number of people who are unconvinced. GBDE invents what is basically a cryptographic algorithm comprised of SHA2/512, AES256, MD5, Yarrow and AES128 which has not been analysed extensively. So, I do not see how you can assert that anything has been convincingly shown about it. I have seen quite a bit of hand--waving, but I have not seen a proof. Or evidence of enough analysis to make this claim. >>E.g. given the bit-blender >>approach of GBDE [from 7.4 of your paper], if you know the salt >>then you can use a divide-and-conquer strategy to tease the master >>key out in a ``reasonably short'' time. Less than 2^128 steps >>certainly, if I look at things correctly. > >I don't think you do. I do not think that you understood what I was saying. I will write it up in LaTeX to try to make it more clear. This will take me a few days. >By the way: you keep comparing your AES256 version of CGD to >my AES128 version of GBDE, but at the same time you want me >to conceede that your 256 bit key is almost 1024 bits when >seen in the right light. I have never claimed that CGD has ``almost 1024 bits''. >Lets us be fair and use a level ground: Let us compare two 128 bit >version or two 256 bit versions. > >Now, which algorithm is stronger ? I chose CGD with AES256 for two reasons. First I wanted to compare systems with comparable performance. CGD does not have a mode which is as slow as GBDE so I chose the slowest mode. Also, GBDE has 2176 bits of key material. Again, CGD does not have a mode which can use 2176 bits of key material so I chose the closest one. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 17:11:16 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E773C16A4CE for ; Thu, 3 Mar 2005 17:11:16 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6D2843D1D for ; Thu, 3 Mar 2005 17:11:16 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j22LFwoH083927; Wed, 2 Mar 2005 13:16:01 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j22LFnWk083926; Wed, 2 Mar 2005 13:15:49 -0800 (PST) (envelope-from www) Date: Wed, 2 Mar 2005 13:15:49 -0800 (PST) Message-Id: <200503022115.j22LFnWk083926@marlena.vvi.at> To: phk@phk.freebsd.dk From: "ALeine" cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 17:11:17 -0000 phk@phk.freebsd.dk wrote: > I gave up on journalling myself because IMO it complicates > things a lot and the problem it solves is very very small. If only hardware manufacturers were to equip hard drives with a mechanism to ensure atomic writes. A capacitor large enough to hold enough energy to flush the cache upon detecting the power supply was cut would be sufficient. They could even use a battery the status of which could be monitored via S.M.A.R.T., I don't see how implementing something like that could possibly make the cost noticably higher. Recent IBM Thinkpad and Apple PowerBook G4 laptops have sudden motion sensors which park the disk heads when a sudden motion is detected in order to prevent damage from a fall and similar, so this atomic write guarantee mechanism should be trivial for them to implement and it would save us a lot of work. > The impact in disk seeks is non-trivial to predict, but it is > very hard to argue that it will not lead to an increase in > disk seeks. (This is really a variant of the age old argument > between jounaling filesystems and "traditional" filesystems) > > I can only recommend that you try :-) Journaling would definitely cause more seeks, but the question is how well that can be compensated for by the reduction of writes gained from using the other speedup mechanisms I proposed. I might try implementing this in GBDE first to see what the benchmarks say. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 17:15:43 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29A6616A4CE for ; Thu, 3 Mar 2005 17:15:43 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5488743D5A for ; Thu, 3 Mar 2005 17:15:42 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23HFf3s009269; Thu, 3 Mar 2005 18:15:41 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Roland Dowdeswell From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 11:59:18 EST." <20050303165918.26C633700F@arioch.imrryr.org> Date: Thu, 03 Mar 2005 18:15:41 +0100 Message-ID: <9268.1109870141@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@NetBSD.org cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 17:15:43 -0000 In message <20050303165918.26C633700F@arioch.imrryr.org>, Roland Dowdeswell writes: >I chose CGD with AES256 for two reasons. First I wanted to compare >systems with comparable performance. "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." -- W.A.Wulf GBDE has two major designgoals: Security and Usability/Deployability. Performance is somewhere down the list after those two. I'm looking forward to seeing something from you which amounts to more than name-calling and hand-waving. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 17:31:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B10F016A4CE for ; Thu, 3 Mar 2005 17:31:10 +0000 (GMT) Received: from saturn.criticalmagic.com (saturn.criticalmagic.com [64.74.124.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58BEB43D31 for ; Thu, 3 Mar 2005 17:31:10 +0000 (GMT) (envelope-from rcoleman@criticalmagic.com) Received: from [10.40.30.110] (delta.ciphertrust.com [216.235.158.34]) by saturn.criticalmagic.com (Postfix) with ESMTP id 9CE393BD10; Thu, 3 Mar 2005 12:31:09 -0500 (EST) Message-ID: <42274A0C.5010403@criticalmagic.com> Date: Thu, 03 Mar 2005 12:31:56 -0500 From: Richard Coleman Organization: Critical Magic User-Agent: Mozilla Thunderbird 1.0 (X11/20041230) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <8837.1109868465@critter.freebsd.dk> In-Reply-To: <8837.1109868465@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: tls@rek.tjls.com cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 17:31:10 -0000 Poul-Henning Kamp wrote: > I fully agree with you about the philosophical points, but not on > the implications. > > I can not convince myself that encrypting a 40 GB disk sector by > sector using the same key, even if it is 256 bits, is a safe design. > > You seem to belive otherwise. > > And that's where it ends. > > Have a good life. I don't want to get in the middle of the GBDE/CGD debate, but my understanding is that the amount of material you can encrypt with a single key is dependent on the block size and (possibily the) cipher mode, not the key size. For instance, the NIST specification for AES and CCM mode (NIST Special Publication 800-38C) specifically states that you must limit the number of invocations of the block cipher (specifically AES) to 2^61. Now, I realize that is an upper bound. But even after removing several orders of magnitude, that leaves a huge amount of material you can encrypt with a single key. Just throwing out a data point. Richard Coleman rcoleman@criticalmagic.com From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 17:47:35 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBCD216A4CE for ; Thu, 3 Mar 2005 17:47:35 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43DE043D2D for ; Thu, 3 Mar 2005 17:47:35 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j22LqToH084489; Wed, 2 Mar 2005 13:52:31 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j22LqJTw084488; Wed, 2 Mar 2005 13:52:19 -0800 (PST) (envelope-from www) Date: Wed, 2 Mar 2005 13:52:19 -0800 (PST) Message-Id: <200503022152.j22LqJTw084488@marlena.vvi.at> To: phk@phk.freebsd.dk From: "ALeine" cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: tls@rek.tjls.com cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 17:47:35 -0000 phk@phk.freebsd.dk wrote: > In message <20050303154847.GA3454@panix.com>, Thor Lancelot Simon > writes: > > Where I come from "home-grown" is not derogative. All > cryptosystems are by necessity home-grown for somebody somewhere. I second that, standards do not come into existence out of thin air and we might get to see the day when GBDE becomes a standard. Now I'm waiting for someone to say that's only how we Europeans think eventhough we have no common identity as Europeans. > >Generally, complexity is not considered a desirable property in > >cryptosystems. GBDE violates this rule in spades. There are > >_reasons_ why complexity is not good: to begin with, a very complex > >cryptographic construct will require detailed analysis (which it > >does not appear GBDE has had by anyone but its author until Roland > >started looking at it) in order that we may know that it is even as > >secure as the underlying algorithmic building blocks it uses. > > Both Lucky Green and David Wagner has nodded vertical on GBDE. I trust the professional opinions of both Lucky Green and David Wagner at least an order of magnitute more than that of Roland Dowdeswell, especially after this discussion. Just what exactly is it about GBDE that is complex? You could explain the concepts behind GBDE to a 12 year old and they would understand them. The complexity lies not in analyzing GBDE but in breaking it. You can analyze it to see how you could break it, but breaking it is something that goes way beyond brute forcing individual sectors. CGD, on the other hand, is the perfect victim for such brute forcing. > I can not convince myself that encrypting a 40 GB disk sector by > sector using the same key, even if it is 256 bits, is a safe > design. Neither can I, which is why I will base my work on GBDE. ALeine P.S.: All you people cross-posting out there please cross-post properly (CC me). :-> ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 17:49:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81A0E16A4CE for ; Thu, 3 Mar 2005 17:49:22 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id C257943D39 for ; Thu, 3 Mar 2005 17:49:21 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23HmpJ4009419; Thu, 3 Mar 2005 18:48:51 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Steven M. Bellovin" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 11:57:30 EST." <20050303165730.8931C3BFDBA@berkshire.machshav.com> Date: Thu, 03 Mar 2005 18:48:51 +0100 Message-ID: <9418.1109872131@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@NetBSD.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com cc: tls@rek.tjls.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 17:49:22 -0000 In message <20050303165730.8931C3BFDBA@berkshire.machshav.com>, "Steven M. Bellovin" writes: >And Knuth was talking about a situation without an adversary. If the component (well respected etc etc) algorithms I have used in GBDE contains flaws so that they become individually less intrinsicly safe because their input is the output of another such algorithm, then the crypto-world has problems they need to work on. If I have made a blatantly stupid programming error, then the source code is out there for all of you to study and review. Despite my best efforts to get people interested in reviewing GBDE, it doesn't seem to have succeeded in getting any attention until now, and I am very much looking forward to the competent review and input this will generate. >I don't claim that there's a flaw. I do assert that that I haven't seen a >threat model that would justify extra complexity. I have, more places than I expected. Before writing GBDE I spent a lot of time talking to people who are responsible for data which needs to be kept private. In fact I talked with all the people I could find who had in their job description to take care of that function in their organization. I didn't talk with very many crypto specialists at that stage, because I was aiming squarely at deployability: Crypto is no good if it never leaves the lab. It transpires that there are actually many places where information has to be kept secret for a surprising number of years. Medical experients for instance: There are double-blind experiments which run for over 20 years before the blind is lifted. Governmental records. Census numbers. When encryption is done a the disk level, many techniques which are available at the stream level are not available: You can not let individual sectors depend on each other (well, you can but it has prohibitive performance cost). You cannot compress the plaintext to increase entropy and so on. You face a reality of millions of sectors with very low entropy, and high predictability which you need to encrypt as is, no tricks allowed. Considering the protection periods people asked for, I could convince neither myself nor any of the, (often very clued) people I talked to, that just taking a current standard algorithm and applying it using the same keymaterial to each sector of the media would be safe for a sufficient amount of time. Having low entropy data and low entropy keys and millions of data points just sounds too much like "gefundenes fressen" for any attacker. Therefore GBDE was designed so that none of the component algorithms would be subject to any kind of two-way leverage or statistical attack. This resulted in the PRNG/1time sector-keys, and it was the simplest way I could find to negate the massive sector numbers. This obviously adds complexity compared to the textbook scheme applied in CGD and similar. It is all sounds and true advice about simplicity, but only if we don't simplify so much that people do not trust the result. As Einstein said: "As simple as possible, but no simpler". Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 17:51:19 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E31616A4CE for ; Thu, 3 Mar 2005 17:51:19 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 956CF43D46 for ; Thu, 3 Mar 2005 17:51:18 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23Hp8YK009679; Thu, 3 Mar 2005 18:51:08 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "ALeine" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 02 Mar 2005 13:15:49 PST." <200503022115.j22LFnWk083926@marlena.vvi.at> Date: Thu, 03 Mar 2005 18:51:08 +0100 Message-ID: <9678.1109872268@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 17:51:19 -0000 In message <200503022115.j22LFnWk083926@marlena.vvi.at>, "ALeine" writes: >phk@phk.freebsd.dk wrote: > >> I gave up on journalling myself because IMO it complicates >> things a lot and the problem it solves is very very small. > >If only hardware manufacturers were to equip hard drives with >a mechanism to ensure atomic writes. I would prefer "If only some bloddy laywer would stop suing any person who tries to market a NVRAM PCI card" :-( >Journaling would definitely cause more seeks, but the question >is how well that can be compensated for by the reduction of >writes gained from using the other speedup mechanisms I proposed. >I might try implementing this in GBDE first to see what the >benchmarks say. I can not encourage you enough to try it. Don't let peole like Thor scare you away, progress happens when people try to follow their ideas, even if told that they are fools by people who (think they) know better. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 17:55:24 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4440016A4CE for ; Thu, 3 Mar 2005 17:55:24 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95D9443D46 for ; Thu, 3 Mar 2005 17:55:23 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23HtG3Q009724; Thu, 3 Mar 2005 18:55:17 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Richard Coleman From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 12:31:56 EST." <42274A0C.5010403@criticalmagic.com> Date: Thu, 03 Mar 2005 18:55:16 +0100 Message-ID: <9723.1109872516@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: tls@rek.tjls.com cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 17:55:24 -0000 In message <42274A0C.5010403@criticalmagic.com>, Richard Coleman writes: >For instance, the NIST specification for AES and CCM mode (NIST Special >Publication 800-38C) specifically states that you must limit the number >of invocations of the block cipher (specifically AES) to 2^61. Now, I >realize that is an upper bound. But even after removing several orders >of magnitude, that leaves a huge amount of material you can encrypt with >a single key. > >Just throwing out a data point. This would be much more interesting if you qouted the number they will say ten and twenty years from now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 17:57:34 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A59DD16A4CE for ; Thu, 3 Mar 2005 17:57:34 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BB9F43D48 for ; Thu, 3 Mar 2005 17:57:34 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j23HsgKE011674; Thu, 3 Mar 2005 10:54:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 03 Mar 2005 10:54:42 -0700 (MST) Message-Id: <20050303.105442.74738904.imp@bsdimp.com> To: rcoleman@criticalmagic.com From: Warner Losh In-Reply-To: <42274A0C.5010403@criticalmagic.com> References: <8837.1109868465@critter.freebsd.dk> <42274A0C.5010403@criticalmagic.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: elric@imrryr.org cc: tls@rek.tjls.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 17:57:34 -0000 > For instance, the NIST specification for AES and CCM mode (NIST Special > Publication 800-38C) specifically states that you must limit the number > of invocations of the block cipher (specifically AES) to 2^61. Now, I > realize that is an upper bound. But even after removing several orders > of magnitude, that leaves a huge amount of material you can encrypt with > a single key. phk's point is that encrypting ~2^10 bytes of data with the same key is better than encrypting ~2^40 bytes. While there may be theoretical reasons to believe that you can get away with much more than 2^9, the whole history of crypto is filled with examples of coding systems, once believed to be secure, that were broken because the same key was used for a lot of traffic. phk's fundamental point isn't that you can't get away with encrypting large amounts of data, in theory, but rather that it is more conservative to do less. Both from the point of view of this history and also from the point of view of amount of data that's disclosed should one key be recovered. Others have a differing point of view. History is also littered with strongly held views that turned out to be wrong. Time will tell if either or both of these views is good or not. Warner From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 18:07:14 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DDE716A4CE for ; Thu, 3 Mar 2005 18:07:14 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9047E43D5F for ; Thu, 3 Mar 2005 18:07:13 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j23I6xHw001471 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 3 Mar 2005 19:07:01 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j23I6f55019509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2005 19:06:41 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j23I6eaF012636; Thu, 3 Mar 2005 19:06:40 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j23I6cdV012635; Thu, 3 Mar 2005 19:06:38 +0100 (CET) (envelope-from ticso) Date: Thu, 3 Mar 2005 19:06:38 +0100 From: Bernd Walter To: Poul-Henning Kamp Message-ID: <20050303180637.GA86348@cicely12.cicely.de> References: <200503022115.j22LFnWk083926@marlena.vvi.at> <9678.1109872268@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9678.1109872268@critter.freebsd.dk> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=no version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 18:07:14 -0000 On Thu, Mar 03, 2005 at 06:51:08PM +0100, Poul-Henning Kamp wrote: > In message <200503022115.j22LFnWk083926@marlena.vvi.at>, "ALeine" writes: > >phk@phk.freebsd.dk wrote: > > > >> I gave up on journalling myself because IMO it complicates > >> things a lot and the problem it solves is very very small. > > > >If only hardware manufacturers were to equip hard drives with > >a mechanism to ensure atomic writes. > > I would prefer "If only some bloddy laywer would stop suing > any person who tries to market a NVRAM PCI card" :-( Damn - there is a patent or leagal restriction on something like that? Well - I think that many gbde users are running notebooks so it is required to be available in other form factors as well. I could imagine doing a USB full/high speed umass device. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 18:31:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C9E316A4CE for ; Thu, 3 Mar 2005 18:31:22 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B9E143D2D for ; Thu, 3 Mar 2005 18:31:21 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23IVKaC009977; Thu, 3 Mar 2005 19:31:20 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: tls@rek.tjls.com From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 13:10:44 EST." <20050303181044.GA6732@panix.com> Date: Thu, 03 Mar 2005 19:31:20 +0100 Message-ID: <9976.1109874680@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@netbsd.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 18:31:22 -0000 In message <20050303181044.GA6732@panix.com>, Thor Lancelot Simon writes: >It also uses MD5 in a way that I would characterize as not exactly >ordinary The only role MD5 has is as a bit-blender. Any strength it may add is just a bonus. >Indeed, the large number of algorithms >used in the keying and encryption process for any block in GBDE >does not necessarily increase its security: in fact, certain >kinds of flaws in any one of those algorithms could in fact make >the decryption of any particular block _more_ likely -- and Roland >has pointed out how the design of GBDE allows such failures to >cascade through the entire set of encrypted data. I'm very much looking forward to Rolands analysis as compared to his hand-waving. >The very complexity of your system makes it very, very >difficult to evaluate just how secure it is, and you seem to think >that that is a benefit: comparing the incommensurables "I don't >believe" and "I don't know, but I suspect", you land on the side of >"I suspect". I invite you to analyse GBDE, and once you have determined which kinds of vulnerabilities in the compontent ciphers it would require before "the house of cards come tumbling down". Then, before you fly off the handle like Roland did, take a moment to consider what else those flaws would doom. Then report your findings in a professional way. The argument I hear right now is "I have not bothered to actually analyse GBDE at all but I heard there were a neck-tie party going on so I thought'd I'd lend them a hand since it is nobody I know". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 18:36:25 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6FD316A4CE for ; Thu, 3 Mar 2005 18:36:25 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CDE143D2D for ; Thu, 3 Mar 2005 18:36:25 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j22MfCoH085408; Wed, 2 Mar 2005 14:41:14 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j22Mf6Vt085406; Wed, 2 Mar 2005 14:41:06 -0800 (PST) (envelope-from www) Date: Wed, 2 Mar 2005 14:41:06 -0800 (PST) Message-Id: <200503022241.j22Mf6Vt085406@marlena.vvi.at> To: phk@phk.freebsd.dk From: "ALeine" cc: tech-security@NetBSD.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com cc: tls@rek.tjls.com cc: smb@cs.columbia.edu Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 18:36:25 -0000 Again I was left out of the loop by a certain someone who is not subscribed to hackers@freebsd.org, so I apologize for replying indirectly. phk@phk.freebsd.dk wrote: > In message <20050303165730.8931C3BFDBA@berkshire.machshav.com>, > "Steven M. Bellovin" writes: > > >I don't claim that there's a flaw. I do assert that that I > >haven't seen a threat model that would justify extra complexity. What about the threat model I described in my reply to you: http://docs.FreeBSD.org/cgi/mid.cgi?200503010320.j213KI8U047666 Do not let the 666 at the end scare you. :-) > It is all sounds and true advice about simplicity, but only if we > don't simplify so much that people do not trust the result. > > As Einstein said: "As simple as possible, but no simpler". Exactly, and people should stop trying to apply Occam's razor (the principle of parsimony) in an attempt to justify the simpler approach when the basic premise for it does not even exist. Occam's razor favours the simpler of the numerous explanations/solutions for an observed phenomenon. Here you have two distinct mechanisms that are not the same phenomenon, eventhough data is being encrypted in both cases. Here's an analogy: GBDE is like a jacket with many pockets both on the inside and the outside, with some secret pockets with keys for other locked pockets within pockets. If someone steals you jacket they might be able to pick some pockets, but picking one pocket will not give you the contents of all the other pockets, nor will it give you their location. CGD, on the other hand, is like a large bag, if you manage to get hold of it and open it (the same assumption as in being able to look inside a regular jacket pocket), everything inside it is yours. I prefer jackets, they also keep you warm. Besides, wearing a bag would be silly, but some people might decide it's their style. :-> ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 18:38:05 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B69E516A4CE for ; Thu, 3 Mar 2005 18:38:05 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35A8F43D39 for ; Thu, 3 Mar 2005 18:38:05 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id DAD403700F; Thu, 3 Mar 2005 13:37:46 -0500 (EST) To: "ALeine" In-reply-to: Your message of "Wed, 02 Mar 2005 13:52:19 PST." <200503022152.j22LqJTw084488@marlena.vvi.at> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Thu, 03 Mar 2005 13:37:46 -0500 From: Roland Dowdeswell Message-Id: <20050303183746.DAD403700F@arioch.imrryr.org> cc: tech-security@NetBSD.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tls@rek.tjls.com cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 18:38:05 -0000 On 1109800339 seconds since the Beginning of the UNIX epoch "ALeine" wrote: > >> Both Lucky Green and David Wagner has nodded vertical on GBDE. > >I trust the professional opinions of both Lucky Green and David Wagner >at least an order of magnitute more than that of Roland Dowdeswell, >especially after this discussion. Most of this started when I disputed some of the wild claims that PHK has made about the security of GBDE. Let me restate: In: http://www.bsdcan.org/2004/papers/gbde.pdf The claim is made that there is at least O(2^256) work to crack a disk and O(2^384) to crack the disk if the lock sectors are destroyed. I do not believe that I need any credibility whatsoever to call shenanigans on these outrageous claims. It is _plainly_obvious_ that if you encrypt 2^30 sectors each with a different 128 bit key then there are at most 2^158 different ways to decrypt the entire disk. Period. PHK then says that it might be difficult to detect whether you got a hit on any individual sector. Well, if we are to believe the O(2^384) claim, then we must assume that the amount of work to verify one of the 2^158 different possibilities is 2^{384 - 158} = 2^226 So, verifying that you have correctly decrypted the disk is now suddenly almost as hard as cracking 256 bit AES? I can't quite bring myself to believe that. This has made me rather suspicious of many other claims that have been floating around w.r.t. GBDE. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 18:46:51 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6FA716A4CE for ; Thu, 3 Mar 2005 18:46:51 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6301B43D55 for ; Thu, 3 Mar 2005 18:46:51 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j22MpcoH085575; Wed, 2 Mar 2005 14:51:40 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j22MpWSg085574; Wed, 2 Mar 2005 14:51:32 -0800 (PST) (envelope-from www) Date: Wed, 2 Mar 2005 14:51:32 -0800 (PST) Message-Id: <200503022251.j22MpWSg085574@marlena.vvi.at> To: phk@phk.freebsd.dk From: "ALeine" cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 18:46:51 -0000 phk@phk.freebsd.dk wrote: > I can not encourage you enough to try it. > > Don't let peole like Thor scare you away, progress happens when > people try to follow their ideas, even if told that they are fools by > people who (think they) know better. Thor? Who is Thor? :-> Seriously, this discussion is only making me more eager to implement my ideas, I know exactly what I want to implement, it just might take me more time than you seasoned kernel programmers who live the code. :-) ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 19:08:02 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B927F16A4CE for ; Thu, 3 Mar 2005 19:08:02 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0926A43D48 for ; Thu, 3 Mar 2005 19:08:02 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23J7u2l010274; Thu, 3 Mar 2005 20:07:56 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Roland Dowdeswell From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 13:37:46 EST." <20050303183746.DAD403700F@arioch.imrryr.org> Date: Thu, 03 Mar 2005 20:07:56 +0100 Message-ID: <10273.1109876876@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: tech-security@NetBSD.org cc: hackers@freebsd.org cc: tls@rek.tjls.com cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 19:08:02 -0000 In message <20050303183746.DAD403700F@arioch.imrryr.org>, Roland Dowdeswell writes: >The claim is made that there is at least O(2^256) work to crack a >disk and O(2^384) to crack the disk if the lock sectors are destroyed. Roland, in particular when you get into big numbers you have to pay attention to small details. The O(2^384) number takes the current estimate for the number of atoms in the universe into account. In the absense of a way to store more than one bit on every single hydrogen atom in the universe, you cannot possibly correlate a matrix which is 2^128 on boths sides without repeatedly recalculating the results for one side as you iterate through the results of the other. The fact that you are not even guaranteed to be able to eliminate a single candidate solution until you brute force at least 17 sectors than two does not improve the situation any. Poul-Henning PS: I get a lot of bounces from various lists I'm not on. I put my faith in somebody forwarding my replies faithfully onto those lists ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 19:25:24 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E898E16A4CE for ; Thu, 3 Mar 2005 19:25:24 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED52743D4C for ; Thu, 3 Mar 2005 19:25:23 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23JPI70010480; Thu, 3 Mar 2005 20:25:18 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Perry E. Metzger" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 13:50:49 EST." <87is48k1h2.fsf@snark.piermont.com> Date: Thu, 03 Mar 2005 20:25:18 +0100 Message-ID: <10479.1109877918@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 19:25:25 -0000 In message <87is48k1h2.fsf@snark.piermont.com>, "Perry E. Metzger" writes: >There is a profession called "cryptographer" out there. They are the >folks who try out these new ideas, and they fill lots of conference >proceedings with their new ideas, including things like crypto modes >designed specifically for disk encryption. There is a world out here that's called the IT industry. When they badly needed a new password scrambler nobody from that cryptographic discipline could be bothered with a problem already long since solved in their academic journals and the task fell to a more or less random programmer in the end. Today that algorithm, with all its flaws, seems to protect a very good sized chunk of the passwords on the internet: All cisco routers, all FreeBSD systems, the majority of Linux systems etc etc etc. At the time where I wrote GBDE, the best that was offered was CGD (and similar) and users (not cryptographers!) didn't trust it and history have so far repeated. I am not claiming that things couldn't be done smarter than GBDE, but I do notice an distinct lack of attempts to do so from the cryptographic establishment. I can add another property of the elite society of cryptographers: if you are not a card carrying member of their society, the majority of their members can not even be bothered to reply to an email from an outsider. This does hamper communiation a bit. Maybe the problem is that cryptographers, like true computer scientists, write in nothing less portable than pencil number two ? If some card-carrying member of the cryptographic establishment were to offer the Open Source operating systems an implementation which were approved by all (or some qualified quorum of) the high priests of their brother hood, then I am sure that it would be received with praise and thanks of no end. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 19:43:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03D7A16A4CE for ; Thu, 3 Mar 2005 19:43:22 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F16543D55 for ; Thu, 3 Mar 2005 19:43:21 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j22NmAoH086260; Wed, 2 Mar 2005 15:48:12 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j22Nm48I086259; Wed, 2 Mar 2005 15:48:04 -0800 (PST) (envelope-from www) Date: Wed, 2 Mar 2005 15:48:04 -0800 (PST) Message-Id: <200503022348.j22Nm48I086259@marlena.vvi.at> To: perry@piermont.com From: "ALeine" cc: tech-security@NetBSD.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: elric@imrryr.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 19:43:22 -0000 perry@piermont.com wrote: > "Poul-Henning Kamp" writes: > > We need more ideas and more people trying out ideas. > > There is a profession called "cryptographer" out there. They are > the folks who try out these new ideas, and they fill lots of > conference proceedings with their new ideas, including things like crypto > modes designed specifically for disk encryption. You are mistaking people who design cryptographic algorithms and those who design cryptographic systems which integrate those algorithms into functional systems. PHK does not need to invent the replacement for SHA in order to be a competent and well respected cryptographic system designer. Besides, there are too many well respected academics who do nothing but attend conferences, PHK has actually implemented something that works and that has so far been publically recognized as solid by two very well respected cryptographers. > People who are members of this profession spend many years > learning what is and is not likely to work when it comes to various > cryptographic schemes, and they often learn the hard way that > most new ideas in cryptography fail under scrutiny. Even the best of them > are very leery of recommending the use of their own new schemes in > the real world before they have been heavily reviewed. Even if you > are Ron Rivest or Don Coppersmith, you make mistakes, and sometimes bad > ones. Would you care to explain what qualifies Roland as a more competent cyrptographic system designer than PHK? > Were you a cryptographer, and were you proposing, in a > theoretical way, a new cryptographic mode for doing disk encryption, > and were you presenting it in a paper at Crypto or some such, well, > that would be perfectly fine. People could then review it, tear it > apart (or fail to) etc, and no one would be harmed. The papers are there, the code is there, review it, analyze it, talk about it on TV. Just because it was not done in the way academics like to do it does not mean it has any less merit. Heck, I would love to see Erez Zadok's NCryptFS, but the academic process seems to be so slow that we'll be lucky to see anything before 2006. If PHK took that road we'd be looking forward to GBDE in FreeBSD 7. > Instead, however, what is happening is that you are implementing > your ideas, which do not appear to be very well founded in the > experience the crypto community has gained at great price, and > they're being tested first on actual users before any peer review > of your design. There is a reason everything happens so slowly in the academic circles. Everyone is trying to cover their asses and trying so hard not to be wrong that they analyze everything ad nauseum. The bolder approach PHK took is well thought-out and some compromises were made with full awareness of the consequences because GBDE is designed to be usable and improved, it's not a final solution. Using it will expose any weaknesses it might have and if/when they are discovered you can be sure they will be fixed. Along with the analyses done on it, it's the best way to make sure you have something usable and cryptographically solid both today and in the future. > WEP was a particularly amusing case, because, like you, its > designers thought that it was safe to use an existing encryption > algorithm in ways that they never even realized were new and potentially > damaging. They didn't understand what they were doing, and so the > results were very bad. WEP relies on RC4 and has a 24-bit IV which means the key stream will definitely get reused after 5 hours of heavy traffic. You are not only comparing apples and oranges, but apples and straw now. Read PHK's papers on GBDE - all of them. You are clutching at straws. > Let me also mention that everyone who does crypto work hears, at > intervals, what horrid insular people cryptographers are and how > little respect they have for "outsiders". Actually, nothing could > be further from the truth. The crypto community is very open -- but > it is a meritocracy, and merit is not demonstrated by throwing lots > of stuff to the wall and seeing what sticks. Everyone who has the proper education from one of the elite universities, knows the right people, has not dared publish anything seriously relevant to outdo their mentor before he retires and everyone who dismisses everyone else who does not have the same pedigree of a proper cryptographer is welcome to join the crypto community, of course. IMHO, the academic community looks at the IT industry with scorn when someone dares insult them with a solution that might prove to be better than something they have been working on with an entire team of international academics for years. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 20:02:21 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB2D816A4CE for ; Thu, 3 Mar 2005 20:02:21 +0000 (GMT) Received: from smtp.ucla.edu (smtp.ucla.edu [169.232.47.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61BB243D58 for ; Thu, 3 Mar 2005 20:02:21 +0000 (GMT) (envelope-from ashcs@ucla.edu) Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.135]) by smtp.ucla.edu (8.13.1/8.13.1) with ESMTP id j23K2KZp028706 for ; Thu, 3 Mar 2005 12:02:21 -0800 Received: from ash (s226-171.resnet.ucla.edu [164.67.226.171]) (authenticated bits=0) by mail.ucla.edu (8.13.3/8.13.3) with ESMTP id j23K2JOS000539 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 3 Mar 2005 12:02:20 -0800 Message-ID: <000c01c5202b$fada24d0$abe243a4@ash> From: "Ashwin Chandra" To: Date: Thu, 3 Mar 2005 12:02:50 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Probable-Spam: no X-Spam-Hits: 0.152 X-Scanned-By: smtp.ucla.edu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Libc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:02:21 -0000 Hey guys, if we broke libc, and we cannot do anything at the prompt=20 /libexec/ld-elf.so.1: Shared object "libc.so.5" not found.. what is the quick fix for this? also what is the correct way of adding names to system calls in libc so = instead of doing a syscall(445), we can actually call it by name = like,sys_ash(); Ash From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 20:18:56 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3074516A4CE for ; Thu, 3 Mar 2005 20:18:56 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EADAD43D53 for ; Thu, 3 Mar 2005 20:18:55 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 84F187A403; Thu, 3 Mar 2005 12:18:55 -0800 (PST) Message-ID: <4227712F.5060906@elischer.org> Date: Thu, 03 Mar 2005 12:18:55 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: kamalp@acm.org References: <20050303041042.3198.qmail@web52709.mail.yahoo.com> In-Reply-To: <20050303041042.3198.qmail@web52709.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: Lucas Holt Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:18:56 -0000 Kamal R. Prasad wrote: >--- Julian Elischer wrote: > > > >>Kamal R. Prasad wrote: >> >> >> >>>--- Lucas Holt wrote: >>> >>> >>> >>> >>> >>>>Wouldn't a multi threaded program potentially need >>>>more cpu time than >>>>vi? >>>> >>>> >>>> >>>> >>>No. That is not a given. >>> >>> >>> >>> >>> >>>>Multithreaded apps are created to do a lot of >>>>computation or >>>>because they have a lot of concurrent activity >>>> >>>> >>that >> >> >>>>might block right? >>>> >>>> >>>> >>>> >>>> >>>Threads are meant to take advantage of concurrency. >>> >>> >>>Maybe the freebsd implementation should implement >>> >>> >>NPTL >> >> >>>in entirety. >>> >>> >>> >>> >>NPTL? >>New Pthreads Library from Library? >> >> >Yes. > > >>isn't that GPL'd? >> >> >> >No -it is a standard. The linux implementation of nptl >is gpl'ed. >regards >-kamal > > so how does that differ from what we have ... a native pthreads library? > > >===== >------------------------------------------------------------ >Kamal R. Prasad >UNIX systems consultant >kamalp@acm.org > >In theory, there is no difference between theory and practice. In practice, there is:-). >------------------------------------------------------------ > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 20:20:27 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29A8F16A4CE for ; Thu, 3 Mar 2005 20:20:27 +0000 (GMT) Received: from lakermmtao03.cox.net (lakermmtao03.cox.net [68.230.240.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85FA143D41 for ; Thu, 3 Mar 2005 20:20:26 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by lakermmtao03.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050303202025.OOEK16861.lakermmtao03.cox.net@mezz.mezzweb.com>; Thu, 3 Mar 2005 15:20:25 -0500 To: "Ashwin Chandra" References: <000c01c5202b$fada24d0$abe243a4@ash> Message-ID: Date: Thu, 03 Mar 2005 14:21:40 -0600 From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <000c01c5202b$fada24d0$abe243a4@ash> User-Agent: Opera M2/7.54 (Linux, build 955) cc: freebsd-hackers@freebsd.org Subject: Re: Libc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:20:27 -0000 On Thu, 3 Mar 2005 12:02:50 -0800, Ashwin Chandra wrote: > Hey guys, > if we broke libc, and we cannot do anything at the prompt > /libexec/ld-elf.so.1: Shared object "libc.so.5" not found.. > > what is the quick fix for this? libmap.conf(5), but a real solution is to recompile that file. Cheers, Mezz > also what is the correct way of adding names to system calls in libc so > instead of doing a syscall(445), we can actually call it by name > like,sys_ash(); > > > Ash -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 20:28:26 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD84716A4CE for ; Thu, 3 Mar 2005 20:28:26 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53B3C43D55 for ; Thu, 3 Mar 2005 20:28:26 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j230XMoH086980; Wed, 2 Mar 2005 16:33:24 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j230XG4G086979; Wed, 2 Mar 2005 16:33:16 -0800 (PST) (envelope-from www) Date: Wed, 2 Mar 2005 16:33:16 -0800 (PST) Message-Id: <200503030033.j230XG4G086979@marlena.vvi.at> To: elric@imrryr.org From: "ALeine" cc: tech-security@NetBSD.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tls@rek.tjls.com cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:28:26 -0000 I must have missed this one before. elric@imrryr.org wrote: > Most of this started when I disputed some of the wild claims that > PHK has made about the security of GBDE. You have not disputed them, you have only confirmed the strengths of GBDE and exposed the issue of atomic writes. > Let me restate: > > In: > > http://www.bsdcan.org/2004/papers/gbde.pdf > > The claim is made that there is at least O(2^256) work to crack a > disk and O(2^384) to crack the disk if the lock sectors are > destroyed. Have you read PHK's paper located at: http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf > I do not believe that I need any credibility whatsoever to call > shenanigans on these outrageous claims. > > It is _plainly_obvious_ that if you encrypt 2^30 sectors each > with a different 128 bit key then there are at most 2^158 different > ways to decrypt the entire disk. Period. You need 2^128 steps to break the encryption of a single sector. But you have no idea which of the 2^128 sectors is the right one, so you store all of the 2^128 * 512 = 2^137 bytes. Right, which movie is this from? Imagine that you could do the same with the next sector... And you do this for 2^30 sectors and then figure out which of the 2^128^(2^30) sector variations is the right one? This is the worst case scenario for an attacker and it obviously is beyond anyone's dreams. You have to resort to attacking GBDE using knowledge about how it does encryption if you want to have any kind of realistic chance of breaking it. In the paper I mentioned PHK analyzed the attack vectors and what kind of threat each one of them represents. You act as if you could just brute force GBDE automatically. It cannot happen. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 20:41:56 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BAA216A4CE for ; Thu, 3 Mar 2005 20:41:56 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9C9343D2D for ; Thu, 3 Mar 2005 20:41:55 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23KfrDT010849; Thu, 3 Mar 2005 21:41:53 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: tls@rek.tjls.com From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 15:00:05 EST." <20050303200005.GA21499@panix.com> Date: Thu, 03 Mar 2005 21:41:53 +0100 Message-ID: <10848.1109882513@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@netbsd.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:41:56 -0000 In message <20050303200005.GA21499@panix.com>, Thor Lancelot Simon writes: >On Thu, Mar 03, 2005 at 08:25:18PM +0100, Poul-Henning Kamp wrote: >To quote David Hume, "Never an ought from an is." I'm Danish by birth so english is only my second language, so I apologize for mangling it. >That "users" (who >are they? how many of them? What criterion or criteria of trust >do they apply?) _did_ not trust X says precisely nothing about whether >users _should_ not trust X. If there is one word I have come to detest, then "should" is at the top of the list. Voters _should_ vote based on intelligently informed opinions. Researchers _should_ report their findings uncolored by personal bias. Kids _should_ listen to their parents. Somebody _should_ fix this bug. I increasingly associate "will not happen" when I read "should". Let me twist it around: How would the users know if they should or should not trust something ? They form their opinion based on the information they have under the constraints they have. And then, more often than not, the remaining 30% is gut feeling. When it comes to crypto gut feeling has about 70% of quorum. The crypto establishment has a big problem communicating to the rest of the world what their findings are in a way that makes this information usable for people. (IMO). >You seem to deny that there is a particular domain of expertise that is >cryptography, or perhaps more rightly two domains, one being largely >a subset of the other: how to design good cryptographic algorithms and >how to use good cryptographic algorithms safely. No I certainly don't. I have personally the deepest respect and admiration for the craft. I spent a lot of time before going into GBDE reading theory. Interestingly again, the best book from a practitioners point of view is written by an outsider in the crypto-clerigy. I also spent a lot of time studying what was already available. But in difference from everybody else (it seems) I also asked users and administrators what they needed and wanted from a cryptographic disk facility. Interestingly I found that the users focus were very different from the points which the crypto community emphasized. And then I designed and wrote GBDE from that angle. Despite what some people in this dicussion seems to belive, I did not write GBDE using 1 iteration random-seed genetic programming. A lot of thought and consideration went into it. I may not be a world renowned cryptographer, nor even claiming to be one at all, but I am not totally without ability either. I am fully aware of the arguments against complexity and I tried very hard to simplify GBDE to the simplest possible algorithm while maintaining the design goals fulfillment. That is why there is no journaling, no MAC, only a very simple level of positional hiding and no heavy duty support for "plausible denial". And then I tried very hard to engage somebody with the right union-card to do a review for me, and despite the fact that funding were available under the DARPA contract nobody would bite. Lucky Green, on his own initiative contacted me because he heard the rumour that I was working on something, and he convinced David Wager to take a peek as well. I am more grateful to them both than my words can express. They gave me a lot of sound advice and I tried my best to implement according to it, but any blame for mistakes is entirely mine. Now, if you could stop defending the cryptographers-local-64 union and accept that non-union people might try to make the world a better place by applying some of the craft in actual code, instead of banning the code because an infidel wrote it, then you could really help by giving said code a professional review. It would be much appreciated if you did. If you sit down and study GBDE, you will find that I have used all the cryptographic algorithms in a conservative way and likely as not, you will end up saying "overkill". The users will call the same "safety margin". The truth is somewhere between, because the real world is shades between dark white and light black. >You call Roland's criticisms of GBDE "handwaving". I have yet to see anything solid from him where he didn't overlook something in his haste to prove his own product superior. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 20:43:12 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6924B16A4CE for ; Thu, 3 Mar 2005 20:43:12 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAA4C43D49 for ; Thu, 3 Mar 2005 20:43:11 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23KhA08010984; Thu, 3 Mar 2005 21:43:10 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Todd Vierling From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 14:37:24 EST." Date: Thu, 03 Mar 2005 21:43:10 +0100 Message-ID: <10983.1109882590@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: elric@imrryr.org cc: "Perry E. Metzger" cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:43:12 -0000 In message , Todd Vierling writes: >On Thu, 3 Mar 2005, Poul-Henning Kamp wrote: > >> At the time where I wrote GBDE, the best that was offered was CGD (and >> similar) and users (not cryptographers!) didn't trust it > >Could you back up this claim, insofar that "users" did not trust cgd? I >haven't seen any distrust of cgd -- in fact, I've seen quite a bit of >welcome acceptace of cgd by both users *and* cryptographers. Some of the people I talked to were very unhappy about the same key being used for all sectors on the disk. Even a small weakness in the cipher becomes a big hole because of the amount of data this offers for analysis. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 20:44:08 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 652C816A4CE for ; Thu, 3 Mar 2005 20:44:08 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8826C43D5C for ; Thu, 3 Mar 2005 20:44:07 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.1) id j23Ki3xt009510; Thu, 3 Mar 2005 14:44:03 -0600 (CST) (envelope-from dan) Date: Thu, 3 Mar 2005 14:44:03 -0600 From: Dan Nelson To: Ashwin Chandra Message-ID: <20050303204402.GC72017@dan.emsphone.com> References: <000c01c5202b$fada24d0$abe243a4@ash> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01c5202b$fada24d0$abe243a4@ash> X-OS: FreeBSD 5.3-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: freebsd-hackers@freebsd.org Subject: Re: Libc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:44:08 -0000 In the last episode (Mar 03), Ashwin Chandra said: > if we broke libc, and we cannot do anything at the prompt > /libexec/ld-elf.so.1: Shared object "libc.so.5" not found.. > > what is the quick fix for this? Use the statically-linked binaries in /rescue/* to mount a remote filesystem (or floppy or usb drive) and copy libc.so.5 from there. I always copy libc.so.5 to libc.so.5.bak before installing a new version, so I can immediately back it out if it causes problems. > also what is the correct way of adding names to system calls in libc > so instead of doing a syscall(445), we can actually call it by name > like,sys_ash(); cd into /sys/kern, edit syscalls.master, then run "make init_sysent.c". That will regnerate a bunch of files, some of which are used to generate the syscall stubs in libc. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:08:58 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0108D16A4CE for ; Thu, 3 Mar 2005 21:08:58 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36D2D43D2F for ; Thu, 3 Mar 2005 21:08:57 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23L8kHs011202; Thu, 3 Mar 2005 22:08:47 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Perry E. Metzger" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 15:12:23 EST." <87ekewjxp4.fsf@snark.piermont.com> Date: Thu, 03 Mar 2005 22:08:46 +0100 Message-ID: <11201.1109884126@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 21:08:58 -0000 In message <87ekewjxp4.fsf@snark.piermont.com>, "Perry E. Metzger" writes: >> There is a world out here that's called the IT industry. > >Yes, there is. They routinely deploy bad security because they don't >get people who know what they are doing involved. See WEP, for >example, or a thousand other things. Yes, it would really be desirable for the cryptographers to come down from their mount olympus more often. Too bad they never answer invitations :-( >I have no idea what you're talking about, Thanks for confirming what I wrote just a second ago above. >If you're talking about MD5 which is used in many modern Unixes, it >was done by Ron Rivest, and even though he's really good, it has >recently been (quite badly) broken. Again. >> At the time where I wrote GBDE, the best that was offered was CGD (and >> similar) and users (not cryptographers!) didn't trust it and history >> have so far repeated. > >I have no idea what you are talking about here. And again. >> I can add another property of the elite society of cryptographers: >> if you are not a card carrying member of their society, the majority >> of their members can not even be bothered to reply to an email from >> an outsider. This does hamper communiation a bit. > >Actually, you can show up at any crypto conference you like, I have a better idea: Why don't we get the cryptographers to show up at computer science conferences ? That would get the gospel out to a far wider crowd without spoiling the highly specialized conferences for the cryptographers. >> Maybe the problem is that cryptographers, like true computer >> scientists, write in nothing less portable than pencil number two ? > >It is rare to see a new algorithm show up from someone like Ron Rivest >without some C code also appearing. That's pretty common in the crypto >world. When the Chinese team that cracked a bunch of hash algorithms >last summer presented their work, they had worked examples of their >stuff. You seem to misunderstand something: Computer users don't call MD5 directly. They use software which makes the calls for them. Sometimes this software has a goal which is different from calling crypto algorithms, in fact some of them even have the impropiety of regarding the crypt algorithms as mere tools. >I think you don't quite get it the point. There are many points not being got here. >1) No one claims that you need to be a cryptographer to write > something like GBDE. What is being claimed is that you should not > have invented your own cryptographic modes, and that you might have > wanted to ask some professionals about your approach. You have not actually studied GBDE yet, right ? You don't actually know if I invented my own "cryptographic modes" or not, do you ? >2) CGD *has* been looked at by a bunch of people, and was written to > carefully use standard algorithms in a standard way. If you don't > like using NetBSD code because NetBSD people have cooties, fine -- > I don't care, write your own. However, you should at least pay the > same attention to conservative use of cryptographic algorithms and > having people review your work is a good idea, too. Even if I were alone in the world with the sentiment, I would never call CGDs use of the same key for all sectors "conservative". >3) You've made some very bizarre claims about the security of your > system. Some of these claims have already been shown on their face > to be incorrect, such as your claimed work factor for breaking your > new "improved" crypto modes. Sorry, they have only been disproved in a significantly larger universe than the one my users inhabit. That doesn't count to me. > Instead, he admitted his mistakes and wrote a version 2. Any qualified, factually correct critique of GBDE will be taken very serious by me. I am very much looking forward to it. What Roland has provided is not it. > Are your users better served by you digging in your heels and > saying "GDBE is perfect as it is", Now, there is one thing I have never said and would never say. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:09:04 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 567B116A4F1 for ; Thu, 3 Mar 2005 21:09:04 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 944AA43D41 for ; Thu, 3 Mar 2005 21:09:03 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23L8wVT011213; Thu, 3 Mar 2005 22:08:58 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Perry E. Metzger" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 15:14:58 EST." <87acpkjxkt.fsf@snark.piermont.com> Date: Thu, 03 Mar 2005 22:08:58 +0100 Message-ID: <11212.1109884138@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 21:09:04 -0000 In message <87acpkjxkt.fsf@snark.piermont.com>, "Perry E. Metzger" writes: > >"Poul-Henning Kamp" writes: >> Don't let peole like Thor scare you away, progress happens when people >> try to follow their ideas, even if told that they are fools by people >> who (think they) know better. > >They laughed at Fulton. > >They also laughed at Bozo the Clown. You're in good company then :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:15:56 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6C5116A4CE for ; Thu, 3 Mar 2005 21:15:56 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDBAD43D54 for ; Thu, 3 Mar 2005 21:15:55 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23LFtaG011286; Thu, 3 Mar 2005 22:15:55 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Perry E. Metzger" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 15:52:48 EST." <87y8d4ih9b.fsf@snark.piermont.com> Date: Thu, 03 Mar 2005 22:15:55 +0100 Message-ID: <11285.1109884555@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: elric@imrryr.org cc: Todd Vierling cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 21:15:57 -0000 In message <87y8d4ih9b.fsf@snark.piermont.com>, "Perry E. Metzger" writes: > >"Poul-Henning Kamp" writes: >> In message , Todd Vierling writes: >>>On Thu, 3 Mar 2005, Poul-Henning Kamp wrote: >>> >>>> At the time where I wrote GBDE, the best that was offered was CGD (and >>>> similar) and users (not cryptographers!) didn't trust it >>> >>>Could you back up this claim, insofar that "users" did not trust cgd? I >>>haven't seen any distrust of cgd -- in fact, I've seen quite a bit of >>>welcome acceptace of cgd by both users *and* cryptographers. >> >> Some of the people I talked to were very unhappy about the same key >> being used for all sectors on the disk. > >Now, was that in the first day after cgd was committed or the second? >As I recall, you committed GBDE 48 hours after CGD was committed in >NetBSD. I'd be curious to hear about how much you changed your design >in that period in response to feedback on cgd. (Please correct me if >I'm wrong about the time gap.) I am being a bit unfair here because I am lumping CGD in with the equally defficient code in Linux (Loop-AES etc). It was mostly the linux code I talked to people about, but CGD makes the same exact mistake. >> Some of the people I talked to were very unhappy about the same key >> being used for all sectors on the disk. Even a small weakness in >> the cipher becomes a big hole because of the amount of data this >> offers for analysis. > >I think we've already established that this fear, though >understandable, is not a reasonable one under the circumstances. See >several postings already made. You are better off just using AES with >a longer key than the GBDE mechanism. I'm sorry, I reached the exact opposite conclusion. The work that was referred to earlier of defactorizing AES into a very large number of equations would be exactly the kind of attack I would worry about if I have 80 million sectors with the same key. If that attack comes through, but relies on some partiular bit combination being present on the plaintext or ciphertext of the algoritm, I see no reason why I would want to improve the attackers odds by a factor of 80 million. And if CGD is _so_ officially approved as you say, then I can not for the life of me understand how it can use the same key to generate the IV and perform the encryption. At the very least two different keys should have been used at the "expense" of making the masterkey 512 bits instead of 256. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:29:57 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A853316A4CE for ; Thu, 3 Mar 2005 21:29:57 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB2F743D54 for ; Thu, 3 Mar 2005 21:29:56 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23LToZY011400; Thu, 3 Mar 2005 22:29:50 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "ALeine" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 02 Mar 2005 14:51:32 PST." <200503022251.j22MpWSg085574@marlena.vvi.at> Date: Thu, 03 Mar 2005 22:29:50 +0100 Message-ID: <11399.1109885390@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 21:29:57 -0000 In message <200503022251.j22MpWSg085574@marlena.vvi.at>, "ALeine" writes: >phk@phk.freebsd.dk wrote: > >> I can not encourage you enough to try it. >> >> Don't let peole like Thor scare you away, progress happens when >> people try to follow their ideas, even if told that they are fools by >> people who (think they) know better. > >Thor? Who is Thor? :-> Seriously, this discussion is only making me >more eager to implement my ideas, I know exactly what I want to >implement, it just might take me more time than you seasoned kernel >programmers who live the code. :-) Start out doing it in userland, it's much easier to work with. In FreeBSD we have something called "geom-gate" which allows you to implement disks in userland. I'm sure something similar exists or can be trivially created in your favourite OS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:45:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BAEE16A4CE for ; Thu, 3 Mar 2005 21:45:36 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8332143D1F for ; Thu, 3 Mar 2005 21:45:35 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23LjYsk011488; Thu, 3 Mar 2005 22:45:34 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Todd Vierling From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 16:34:24 EST." Date: Thu, 03 Mar 2005 22:45:34 +0100 Message-ID: <11487.1109886334@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: elric@imrryr.org cc: "Perry E. Metzger" cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 21:45:36 -0000 In message , Todd Vierling writes: >On Thu, 3 Mar 2005, Poul-Henning Kamp wrote: > >> And if CGD is _so_ officially approved as you say, then I can not >> for the life of me understand how it can use the same key to generate >> the IV and perform the encryption. At the very least two different >> keys should have been used at the "expense" of making the masterkey >> 512 bits instead of 256. > >Technically, two different keys are used. The IV is generated from the >block number (although it's pluggable for other IV generation methods, >should one be desired; take a look!). As I read it, he encrypts the block number using the key to get the IV which he then uses with the key to encrypt the data. Since the attacker know the block number the IV generation doesn't add strength. In fact expose any weakness in the algorithm even more because it offers two-way leverage on the algorithm. It also adds a very efficient hit-detector for a brute force attack. It would have been much better to use a different key to generate the IV. And did he salt the block number at all ? I don't think so... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:51:05 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C35516A4CE for ; Thu, 3 Mar 2005 21:51:05 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0593043D2F for ; Thu, 3 Mar 2005 21:51:05 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j231tvoH088686; Wed, 2 Mar 2005 17:55:59 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j231to9f088685; Wed, 2 Mar 2005 17:55:50 -0800 (PST) (envelope-from www) Date: Wed, 2 Mar 2005 17:55:50 -0800 (PST) Message-Id: <200503030155.j231to9f088685@marlena.vvi.at> To: perry@piermont.com From: "ALeine" cc: tech-security@NetBSD.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: elric@imrryr.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 21:51:05 -0000 perry@piermont.com wrote: > > You are mistaking people who design cryptographic algorithms > > and those who design cryptographic systems which integrate those > > algorithms into functional systems. > > No, I am not. PHK invented new cryptographic modes for his work. > The fact that he does not understand this is part of the problem. He designed GBDE to always be harder than and never easier to break than the cryptographic algorithms it relies on. Not only that, but it does not rely exclusively on any single cryptographic algorithm and it does not reuse keys, both of which CGD is guilty of. > > Would you care to explain what qualifies Roland as a more > > competent cyrptographic system designer than PHK? > > Roland didn't try to do anything that wasn't already heavily > understood in the literature. He invented no cryptographic modes. > He used only algorithms that have been pre-vetted. He also asked a > bunch of people who know better than he does to check his work. > > Thus, you don't have to trust Roland at all. He didn't invent any > new way of using any of the algorithms. You have to trust only the > designers of the block cipher you choose to use (I'd suggest AES) > and the password algorithm you choose to use (though the PKCS stuff > is very good already). In order to permit even greater defense > against key cracking, he put in a very standard and straightforward > mechanism to permit N factor authentication. MD5 was believed to be heavily understood in literature. It was well established. Look at what happened to it. The fact that Roland did not invent any new ways of using algorithms does not mean that CGD is more secure. In fact, IMHO it is less secure because it uses the same key for the entire disk and because it reuses the same key for IV generation and encryption. You have to trust Roland to integrate the well known and understood algorithms in a correct way, trusting the algorithms alone is not enough. In that regard, I would rather trust PHK's proven and very well established track record as a programmer than Roland's. To be honest, the first time I heard of Roland was when I found out about CGD, I have not seen his name mentioned in any other reference before. On the other hand, I have known about PHK being an excellent programmer for at least a decade now. > > There is a reason everything happens so slowly in the academic > > circles. Everyone is trying to cover their asses and trying so > > hard not to be wrong that they analyze everything ad nauseum. > > No. You Do Not Understand. I am speaking from personal experience and I know very well what the academic circles are like, at least in Europe. > Are you as good a cryptographer as Ron Rivest? I certainly am > not. Somehow, however, MD5 has been crushed anyway. This is not > unusual. Cryptographic algorithms are not like sorting algorithms > or graph traversal algorithms. When you're doing 3DES, it is not > obvious that doing the CBC on the outside instead of between the > rounds is critical to good security -- indeed it wasn't obvious > even to trained cryptographers. I am not designing cryptographic algorithms, what PHK did with GBDE cannot be compared to inventing MD5, snap out of it, you are starting to sound like a broken record. > If you aren't as good as Ron Rivest, then why are you expecting > to design a new cryptographic mode on your first try without any > issues arising? It is your unfounded assumption that one has to get it perfectly right in the first try, not mine or PHK's, AFAIK. Again, we are not discussing the invention of the successor to SHA. > WEP is even weaker than its design. That is because its designers > did not know what they were doing. I assure you PHK knows very well what he is doing and I think you should not mention his name in the same breath along with the names of the designers of WEP. > Inventing new cryptographic modes is dangerous. Living is dangerous, today you are here, tomorrow you might get hit by a bus. But that does not mean you will stay inside your house where you are safe (at least from buses) forever, does it? > Anyone can get a paper published at Crypto or Eurocrypt. You need > no PhD or other credentials. All you have to do is have something > interesting to say. People who are "outsiders" get stuff > published. Your claim is baseless. Getting a paper published does not mean much. Do you know how many papers get published at various conferences in Europe and nobody ever even reads them, let alone implements any of the ideas in a production environment? > In general, geeks are meritocratic. Crypto people are not unlike > other geeks. If you find that crypto people laugh at you, it is > probably not because you don't know the right people, but because > you put your foot in your mouth and swallowed hard. In general, all generalizations are wrong, including this one. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:57:47 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7437F16A4CE for ; Thu, 3 Mar 2005 21:57:47 +0000 (GMT) Received: from wjv.com (fl-65-40-24-38.sta.sprint-hsd.net [65.40.24.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABF2443D1F for ; Thu, 3 Mar 2005 21:57:46 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.12.11/8.13.1) with ESMTP id j23LvVqO023841 for ; Thu, 3 Mar 2005 16:57:36 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.12.11/8.13.1/Submit) id j23LvVQZ023840 for freebsd-hackers@freebsd.org; Thu, 3 Mar 2005 16:57:31 -0500 (EST) (envelope-from bv) Date: Thu, 3 Mar 2005 16:57:31 -0500 From: Bill Vermillion To: freebsd-hackers@freebsd.org Message-ID: <20050303215731.GC23632@wjv.com> References: <20050303194333.18C6016A4D9@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050303194333.18C6016A4D9@hub.freebsd.org> Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com User-Agent: Mutt/1.5.6i X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on bilver.wjv.com Subject: Flushing HD cache - was Re: FUD about CGD and GDBE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bv@wjv.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 21:57:47 -0000 > ------------------------------ > Message: 18 > Date: Wed, 2 Mar 2005 13:15:49 -0800 (PST) > From: "ALeine" > Subject: Re: FUD about CGD and GBDE > phk@phk.freebsd.dk wrote: > > I gave up on journalling myself because IMO it complicates > > things a lot and the problem it solves is very very small. > If only hardware manufacturers were to equip hard drives with > a mechanism to ensure atomic writes. A capacitor large enough > to hold enough energy to flush the cache upon detecting the > power supply was cut would be sufficient. They could even use > a battery the status of which could be monitored via S.M.A.R.T., > I don't see how implementing something like that could possibly > make the cost noticably higher. Actually at least some used to do something similar. In some IBM SCSI drives of a few years ago, if there was a power failure, the energy in the rotational momentum of the platters was used as the motor was changed over to a miniature generator that provided enough current to flush the contents of the on-board cache to the platters. A capacitor large enough might be too large considering how small everyone is trying to make thier drives. And the main goal seems to be to make drives cheaper - so until enough people want this feature and are willing to pay for - I don't think we'll see this return. > Recent IBM Thinkpad and Apple PowerBook G4 laptops have sudden > motion sensors which park the disk heads when a sudden motion > is detected in order to prevent damage from a fall and similar, > so this atomic write guarantee mechanism should be trivial for > them to implement and it would save us a lot of work. The first hard drive I ever saw - a genuine Shugart ST-506 - had to be shipped in two boxes with the internal box being suspended by springs from the larger box - as it would only take about .5G before it had problems. At the time it was the only 5.25" hard drive being made. Now drives routinely have 100G shock survivability static and at least 20G when turning. And a human body will not normaly survive a 20G shock. Bill -- Bill Vermillion - bv @ wjv . com From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 22:12:22 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA3B416A4CE for ; Thu, 3 Mar 2005 22:12:22 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8210543D31 for ; Thu, 3 Mar 2005 22:12:22 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j232HGoH088988; Wed, 2 Mar 2005 18:17:19 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j232HAGG088987; Wed, 2 Mar 2005 18:17:10 -0800 (PST) (envelope-from www) Date: Wed, 2 Mar 2005 18:17:10 -0800 (PST) Message-Id: <200503030217.j232HAGG088987@marlena.vvi.at> To: briggs@netbsd.org From: "ALeine" cc: elric@imrryr.org cc: perry@piermont.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 22:12:22 -0000 briggs@netbsd.org wrote: > On Wed, Mar 02, 2005 at 04:33:16PM -0800, ALeine wrote: > > elric@imrryr.org wrote: > > > It is _plainly_obvious_ that if you encrypt 2^30 sectors each > > > with a different 128 bit key then there are at most 2^158 > > > different > > > ways to decrypt the entire disk. Period. > > > > out which of the 2^128^(2^30) sector variations is the right > one? > > Which, I think, is 2^(128 + 30) == 2^158, which is what Roland > said. No, you are wrong. 2^128*2^30 = 2^158 We are actually dealing with: (2^128)^(2^30) = 2^(128*2^30) = 2^(2^37) = 2^137438953472 ^--- notice the minor difference ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 22:19:13 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEC9C16A4CE for ; Thu, 3 Mar 2005 22:19:13 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAEE943D49 for ; Thu, 3 Mar 2005 22:19:12 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23MJBa4011650; Thu, 3 Mar 2005 23:19:11 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: tls@rek.tjls.com From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 16:41:50 EST." <20050303214150.GA28836@panix.com> Date: Thu, 03 Mar 2005 23:19:11 +0100 Message-ID: <11649.1109888351@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@netbsd.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 22:19:13 -0000 In message <20050303214150.GA28836@panix.com>, Thor Lancelot Simon writes: >On Thu, Mar 03, 2005 at 10:15:55PM +0100, Poul-Henning Kamp wrote: >> >> And if CGD is _so_ officially approved as you say, then I can not >> for the life of me understand how it can use the same key to generate >> the IV and perform the encryption. At the very least two different >> keys should have been used at the "expense" of making the masterkey >> 512 bits instead of 256. > >Why "should" two different keys have been used? It is possible that I >misunderstand the underlying theory, but so far as I do understand it >the only real requirement for IVs is that the Hamming distance between >any two used with the same encryption key be large. I have studied the AES papers and in particular the attacks and critisisms of it very carefully, and they have proven a whole lot of things to be impossible, but they have not proven that there are not more that needs to be proven impossible. When DES was designed, nobody knew that differential attacks existed. Shortly after AES was gold-plated the earlier mentioned attack method where it is decomposed into a massive number of equations was presented. Since we cannot possibly know how AES can be attacked in the future, we have to think about how we provide the least help to _any_ potential attack. So my approach is to regard the algorithms as black boxes, and study the information flow and degrees of freedom involved. Try to zoom out a bit, and think of this as a black box with wires going into it. I belive CGD looks like this: Block no---------------------> AES >----- ^ | | | | | KEY(256b) ----------------------+ | | | | | v | DATA -----------------------> AES <------ | | v to disk By constraining the two AES instances to use the same key, we give the attacker a lot less degrees of freedom to figure out. Even worse, we may be helping him because worst case, the two uses of the key could cancel something out in some way when two instances of AES are hooked up this exact way. Since the master keysize could have been 512 bits at no expense to anybody, it only takes a minute modification to improve the diagram above: KEY1(256b) --------------------- | | v Block no---------------------> AES >----- | | | KEY2(256b) ---------------------- | | | | | v | DATA -----------------------> AES <------ | | v to disk Now, if there are any weakness in hooking two AES instances together, we at least are not giving the attacker any help exploiting it, this is what I call lack of "two-way leverage". But there is (I belive) still a trivial mistake: The IV generation has totally predictable input. Lets add another handful of bits to the masterkey and fix that also: KEY1(256b) --------------------- | | v Block no---------------------> AES >----- + SALT (256b) | | | | KEY2(256b) ---------------------- | | | | | v | DATA -----------------------> AES <------ | | v to disk There. I'm not a card-carrying cryptographer, but I belive I just improved CGD in a fairly obvious way. I would be very surprised if anybody can show me to have done any harm with these two modifications because all I did was to improve how the components were hooked together and add more bits to the input side of the whoe thing, and that can never be a bad thing, provided those bits are generated by a competent (P)RNG of course. I am still uncomfortable with the KEY2 being constant over all sectors and that is why GBDE doesn't look like this. (We can not just derive KEY2 from the block number like we do the IV because then we would again have given a two-way leverage to an attacker since the block number would appear in both the key and the IV of the lower AES.) You will notice no doubt, that the above considerations and changes are not in any way tied to AES. They are valid for any encryption algorithm you employ, also if they are two different algorithms. It appears to me, that the people who designed CGD and the Linux Loop-AES and similar focused very hard on the box that said "AES" without giving much consideration to where the arrows between the boxes went. But again, I know nothing... Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 22:38:54 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F67116A4CE for ; Thu, 3 Mar 2005 22:38:54 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id E05CF43D2D for ; Thu, 3 Mar 2005 22:38:53 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j232hkoH089626; Wed, 2 Mar 2005 18:43:48 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j232hegV089625; Wed, 2 Mar 2005 18:43:40 -0800 (PST) (envelope-from www) Date: Wed, 2 Mar 2005 18:43:40 -0800 (PST) Message-Id: <200503030243.j232hegV089625@marlena.vvi.at> To: tls@rek.tjls.com From: "ALeine" cc: tech-security@netbsd.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: elric@imrryr.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 22:38:54 -0000 tls@rek.tjls.com wrote: > Unfortunately, all these well-intentioned and very intelligent > people were wrong. The novel cryptographic modes they designed > to always be harder to break were in fact sometimes -- in fact, > in the case of PCBC, pretty much always -- easier to break than > the boring, ordinary, pedestrian constructions they were meant > to replace. > > And after all those well meaning and clever people got burned > over the years, the consensus of the community of experts (as > I percieve it, anyway) gradually became that novel cryptographic > constructions should not be used in implementations until they > had been extensively studied over a period of many years by > experts. At any time half of all the people are wrong about something, it's only a matter of time when your time will come to be in the wrong half or rather the right half to be wrong. That stops neither half from going forward and doing what they feel is right. Just because there is a tendency for new cryptographic systems to be broken does not mean this applies to GBDE, otherwise anything new would be considered wrong and we might as well stop even trying to innovate. Give GBDE a chance. GBDE is not replacing anything because there was nothing like it to replace in the first place. Also, there is a catch 22 situation with studying things without using them. The longer you study something without using it the less likely it is to make it into production, the world is not waiting for anyone. GBDE is here, you can analyze the design and the code, when you do a formal analysis let us know, shouting "It's new, it must be bad!" is not an argument. > Those who do not know the mistakes of the past are doomed to > repeat them. Those who are afraid of making mistakes are sentenced to regretting that mistake and living in the past. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 22:59:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB7D116A4CE for ; Thu, 3 Mar 2005 22:59:10 +0000 (GMT) Received: from arioch.imrryr.org (arioch.imrryr.org [216.254.67.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71C2E43D1D for ; Thu, 3 Mar 2005 22:59:10 +0000 (GMT) (envelope-from elric@imrryr.org) Received: from imrryr.org (localhost [127.0.0.1]) by arioch.imrryr.org (Postfix) with ESMTP id 0E7143700F; Thu, 3 Mar 2005 17:58:49 -0500 (EST) To: "ALeine" In-reply-to: Your message of "Wed, 02 Mar 2005 18:17:10 PST." <200503030217.j232HAGG088987@marlena.vvi.at> Organization: The Fall of Imrryr User-Agent: nmh-1.0.4 (NetBSD/alpha) X-Copyright: Copyright 2004, R. C. Dowdeswell. All Rights Reserved. X-Window-System: Release 6.3 Date: Thu, 03 Mar 2005 17:58:49 -0500 From: Roland Dowdeswell Message-Id: <20050303225849.0E7143700F@arioch.imrryr.org> cc: briggs@netbsd.org cc: perry@piermont.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 22:59:11 -0000 On 1109816230 seconds since the Beginning of the UNIX epoch "ALeine" wrote: > >No, you are wrong. > > 2^128*2^30 = 2^158 > >We are actually dealing with: > > (2^128)^(2^30) = 2^(128*2^30) = 2^(2^37) = 2^137438953472 > ^--- notice the minor difference It is a serial attack that is: for (i=0; i < n; i++) { crack the i'th key--key block; } So it is actually where $n$ is the number of key--key sectors: n ------- \ \ 128 128 > 2 = n 2 / / -------- i = 0 (sorry about the bad ascii art, there, but I thought that would be the best way to draw it.) So, for a disk with 2^30 key--key sectors it would be 2^30 * 2^128 = 2^158 I realise that PHK has been claiming that you might get false positives, and that you somehow have to maintain a matrix of past this and that. It is a lot simpler than this really. For each key--key sector you are brute forcing, there are 2^128 different keys to try. Now, the key--key sector protects 32 disk sectors which contain 32 * 512 * 8 = 131072 bits. That means that there are 2^131072 possibilities for what can be in those 32 sectors. So, I think that we can see where I am going here? There will not be very many false positives when you are brute forcing. It is quite unlikely that there even exists an AES128 key which would produce one. Depending on how many bits of the 32 sectors are being used, the probability could be as low as 1 -------- 2^130944 Which is a very small number indeed. Now, granted not the entirety of the 32 sectors will be recognisable, or necessarily even used---but a fair percentage will. Enough to come up with numbers that may not be so astronomically small, are still staggeringly small---a staggeringly small possibility that such a false positive generating key actually exists at all. Disklabels for example have a checksum. The checksum might not be terribly strong, but the chance that two different valid disklabels could even be decrypted with different keys is small, I would imagine. The checksum takes off 2^32 seemingly valid disklabels and what about the rest of the fields? There's lots of redundant information in there that could be cross referenced. The examples abound. Disks are very well structured and so are the files on them. So, I think that considering that you are cracking 16KB at a time there will not be terribly many false positives to find. You will not have to write a lot of machinery to detect them. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 23:18:51 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 555B916A4CE for ; Thu, 3 Mar 2005 23:18:51 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B2D043D4C for ; Thu, 3 Mar 2005 23:18:50 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23NIeKK012183; Fri, 4 Mar 2005 00:18:40 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Roland Dowdeswell From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 17:58:49 EST." <20050303225849.0E7143700F@arioch.imrryr.org> Date: Fri, 04 Mar 2005 00:18:40 +0100 Message-ID: <12182.1109891920@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: briggs@netbsd.org cc: perry@piermont.com cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 23:18:51 -0000 In message <20050303225849.0E7143700F@arioch.imrryr.org>, Roland Dowdeswell writes: >Now, the key--key sector protects 32 disk >sectors which contain 32 * 512 * 8 = 131072 bits. The key-key protect only a single sector-key, however, the actual sectorsize may be bigger than 512 and I recommend that people use the FFS fragment size (typically 2k) if possible. I have not taken the time to figure out how many of the 2^2048 possible sector contents are actually valid superblocks but it would actually be an interesting number to know in this dicussion, just like the fraction of valid inode blocks and directory blocks would be interesting to know. My guess is that the super block probability is about 1E-9, inode block around 1E-8 and directory around 1E-9, but these are pure guesses and likely off by a many orders of magnitude. The bsd disklabel is not relevant in normal usage, people tend to encrypt each filesystem individually as far as I have heard. But Roland, These continued false starts because you didn't take the time to really understand what goes on in GBDE are a waste of both your and my time and doesn't add to your reputation in any way. I am old enough to actually appreciate a competently done review because that is one of the best ways for me to improve my skills, so even if your review ends up tearing GBDE apart at the seams, you can trust me to appreciate that you did it. And I am convinced you can give me a competent review if you give it a fair shot, but right now you seem hell-bent on acing me rather than doing your homework properly. Please sit down and take the time it must take and then come back with a professionally done review. If there are things you are unclear about, send me email and I'll do my best to explain them. Thanks in advance, Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 23:42:44 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A71B16A4CE for ; Thu, 3 Mar 2005 23:42:44 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF61743D2F for ; Thu, 3 Mar 2005 23:42:43 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23NgXVe012312; Fri, 4 Mar 2005 00:42:34 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Perry E. Metzger" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 18:18:18 EST." <87ll94iait.fsf@snark.piermont.com> Date: Fri, 04 Mar 2005 00:42:33 +0100 Message-ID: <12311.1109893353@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 23:42:44 -0000 In message <87ll94iait.fsf@snark.piermont.com>, "Perry E. Metzger" writes: >I remember a certain talk at BSDCon where someone criticized the >design of the kernel RNG during the talk on it. He mentioned that the >person giving the presentation had stated a few inaccurate things, >such as claiming that there was a proof of security for Schneier's >Yarrow algorithm and a few other howlers. As I recall, he was >thoroughly criticized for mentioning these things. As I also recall, >when said person brought the topic up with a certain person named PHK, >he said "I don't want to hear about it." No, that is not what I said. I said something about Yarrow being so many times better than what we had before that it didn't really affect the picture at this time and that if you had a beef with Marks presentation you should take it up with Mark because I had not myself read the Yarrow paper at the time. >> You don't actually know if I invented my own "cryptographic modes" >> or not, do you ? > >You did. I did ? Cool, I should patent them! :-) Seriously, I don't think I did, but this may be a matter of semantics which I am not aware of on account of not being a full time cryptographer. If by "cryptographic modes" you mean "use algorithms in ways we have not seen before", then yes, I may have. That is not the same as I havn't thought a lot about the implications. For instance, the role of MD5 is not to add strength but merely to give a better statistical distribution of bits. But either way, I'm very interested in getting a competent review, but saying only "you did something new" is not that. >> Sorry, they have only been disproved in a significantly larger universe >> than the one my users inhabit. That doesn't count to me. > >Being stubborn on this isn't going to help your users. The math is >pretty obvious here. Sure a brute force isn't practical -- but neither >is a brute force of AES-256. No, not right now. But do we know that a brute force attack is unfeasible on AES-256 tens years from now ? And are we sure that the reuse of key material which happens in CGD will not materially aid any attacks that may be developed in the next decade ? If we do, please forward the paper. The fact that you just need to break one single sector in CGD before you get the entire disk contents gives a disadvantage to CGD of 2^26 before we even consider the nature of the attack. That is not conservative when it could have been trivially avoided. >someone points out an obvious flaw in your logic and shows the work >factor is lower than that for AES-256, the gentlemanly thing to do is >say "you are correct, I was mistaken." And you can trust me to do so. But the "flaw" must be possible to exploit in the current universe. The goal for GBDE is to give credible denial of access for up to 25 years, and if nothing else that limits the storage capactity available for an attacker to within an order of magnitude of number of particles within a 12.5 lightyear radius of Earth. If you do not consider such limitations, you are just producing silly math along the lines of the old joke: "First, we assume a hexagonal sheep". >> Any qualified, factually correct critique of GBDE will be taken very >> serious by me. I am very much looking forward to it. What Roland >> has provided is not it. > >Roland's criticism is reasonable. As you saw from the email preceeding this one, Roland still hasn't found out how GBDE actually works. >Rather than getting angry, why don't >you consider it? What I got angry about was the fact that Roland was spreading fud about GBDE in all sorts of mailinglists without having enough honour to give me a Cc: so I could have a chance to participate in the discussion. As I said in my reply just a second ago, I would very much appreciate if Roland would take the time to give me a competent review of GBDE, but he cannot do that as long as he is blinded by the desire to ace me instantly instead of thinking his arguments properly through and test his hypothesis. Unfortunately I can no longer offer him financial compensation for the effort, the DARPA contract is long since closed. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 23:47:04 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C945116A4CE for ; Thu, 3 Mar 2005 23:47:04 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2554B43D49 for ; Thu, 3 Mar 2005 23:47:04 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j23Nkxv4012468; Fri, 4 Mar 2005 00:46:59 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Perry E. Metzger" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 18:40:30 EST." <87d5ugi9ht.fsf@snark.piermont.com> Date: Fri, 04 Mar 2005 00:46:59 +0100 Message-ID: <12467.1109893619@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 23:47:04 -0000 In message <87d5ugi9ht.fsf@snark.piermont.com>, "Perry E. Metzger" writes: >> MD5 was believed to be heavily understood in literature. It was >> well established. Look at what happened to it. > >Yup. And Roland made the algorithm you use for encrypting your disk >*pluggable*. That way, if AES is broken, you can replace it with the >next big thing and move on with your life. > >Now, if AES is indeed broken, GBDE is in serious trouble, but CGD is >not. Specific users of CGD have to change their drives, but the >framework continues to work as advertised. Gee Perry, now you're spreading FUD. You know perfectly well that it would take less than one hour to substitute another algorithm in the GBDE source code. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 01:36:26 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6233716A4CF for ; Fri, 4 Mar 2005 01:36:26 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9A9D43D41 for ; Fri, 4 Mar 2005 01:36:24 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id DA23685666; Fri, 4 Mar 2005 12:06:22 +1030 (CST) Date: Fri, 4 Mar 2005 12:06:22 +1030 From: Greg 'groggy' Lehey To: FreeBSD Hackers Message-ID: <20050304013622.GS73981@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kG2acDqmwoBDcCHP" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Subject: Setting maximum data size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 01:36:26 -0000 --kG2acDqmwoBDcCHP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've spent the last hour trying to raise the maximum process data size (ulimit -d). /etc/login.conf says "unlimited", /boot/loader.conf has nothing, and I can't find a sysctl that looks like it's doing something nasty. I've RTFMd and found nothing. What am I missing? Greg -- See complete headers for address and phone numbers. --kG2acDqmwoBDcCHP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCJ7uWIubykFB6QiMRAmiBAKCpDVJVaQQJho23NhDZwNO5tW4lkgCgso1H sz9Bq5yhDPmnup4IjbSg79g= =ndhV -----END PGP SIGNATURE----- --kG2acDqmwoBDcCHP-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 01:40:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53DAA16A4CE; Fri, 4 Mar 2005 01:40:36 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06CFA43D48; Fri, 4 Mar 2005 01:40:36 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j241eZN7031941; Thu, 3 Mar 2005 17:40:35 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j241eZYp031940; Thu, 3 Mar 2005 17:40:35 -0800 Date: Thu, 3 Mar 2005 17:40:35 -0800 From: Brooks Davis To: "Greg 'groggy' Lehey" Message-ID: <20050304014035.GA20301@odin.ac.hmc.edu> References: <20050304013622.GS73981@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <20050304013622.GS73981@wantadilla.lemis.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: FreeBSD Hackers Subject: Re: Setting maximum data size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 01:40:36 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 04, 2005 at 12:06:22PM +1030, Greg 'groggy' Lehey wrote: > I've spent the last hour trying to raise the maximum process data size > (ulimit -d). /etc/login.conf says "unlimited", /boot/loader.conf has > nothing, and I can't find a sysctl that looks like it's doing > something nasty. I've RTFMd and found nothing. What am I missing? The FM seems faily unhelpful, but the answer is the tunable kern.maxdsiz. I found it by finding MAXDSIZ in NOTES and the searching for it on Robert's FreeBSD Cross Refrence and finding the one .c file that used it: http://fxr.watson.org/fxr/ident?i=3DMAXDSIZ -- Brooks --=20 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 --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCJ7yTXY6L6fI4GtQRAq3QAJ0Yjda5bk9/Be89IJlZs9l9HYT7lgCbBXNk j8+hZfV5fMjyijFP5f0jPE0= =lcQu -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 02:03:46 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D32C16A4CE for ; Fri, 4 Mar 2005 02:03:46 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EDD443D58 for ; Fri, 4 Mar 2005 02:03:44 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 5E08A8568F; Fri, 4 Mar 2005 12:33:40 +1030 (CST) Date: Fri, 4 Mar 2005 12:33:40 +1030 From: Greg 'groggy' Lehey To: Brooks Davis Message-ID: <20050304020340.GU73981@wantadilla.lemis.com> References: <20050304013622.GS73981@wantadilla.lemis.com> <20050304014035.GA20301@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A47bNRIYjYQgpFVi" Content-Disposition: inline In-Reply-To: <20050304014035.GA20301@odin.ac.hmc.edu> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: FreeBSD Hackers Subject: Re: Setting maximum data size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 02:03:46 -0000 --A47bNRIYjYQgpFVi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 3 March 2005 at 17:40:35 -0800, Brooks Davis wrote: > On Fri, Mar 04, 2005 at 12:06:22PM +1030, Greg 'groggy' Lehey wrote: >> I've spent the last hour trying to raise the maximum process data size >> (ulimit -d). /etc/login.conf says "unlimited", /boot/loader.conf has >> nothing, and I can't find a sysctl that looks like it's doing >> something nasty. I've RTFMd and found nothing. What am I missing? > > The FM seems faily unhelpful, but the answer is the tunable > kern.maxdsiz. I found it by finding MAXDSIZ in NOTES and the searching > for it on Robert's FreeBSD Cross Refrence and finding the one .c file > that used it: > > http://fxr.watson.org/fxr/ident?i=MAXDSIZ Heh. Yes, I recall doing something like that too. In fact, I had guessed at it based on the entries in /boot/defaults/loader.conf, but it still took me 3 attempts to get it right. Some values can be specified like this: hw.physmem="1G" # Limit physical memory. See loader(8) That doesn't seem to work for MAXDSIZ. I ended up setting it like this: kern.maxdsiz="2147483648" # Set the max data size It would be nice to get somebody to update the FM. Thanks for the reply. Greg -- See complete headers for address and phone numbers. --A47bNRIYjYQgpFVi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCJ8H8IubykFB6QiMRAqD5AJ4ratUkv5yzXlax0YcdvJ4HcS2V6gCeKePv N0AfQmcTPr1nrHkD6VyQiUk= =z4S8 -----END PGP SIGNATURE----- --A47bNRIYjYQgpFVi-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 03:20:04 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B710016A4CE for ; Fri, 4 Mar 2005 03:20:04 +0000 (GMT) Received: from web52702.mail.yahoo.com (web52702.mail.yahoo.com [206.190.39.153]) by mx1.FreeBSD.org (Postfix) with SMTP id 29F8143D48 for ; Fri, 4 Mar 2005 03:20:04 +0000 (GMT) (envelope-from kamalpr@yahoo.com) Received: (qmail 89307 invoked by uid 60001); 4 Mar 2005 03:20:03 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=PYUaVsQMwDymy/CNgVprp+bel6lOZeCE47AWXjUJoKrKJNh+53scGT56HUQSdrw1kp4uMAEobVxZhyGD28ulahIhnQD/c39Z1mqNuERPgENIYoTfjUFgoR2p2TGrl5AbybZYrnlVH+iDlQN6Lo9r+M4UOaYzr9HfNRVCBRr1iLc= ; Message-ID: <20050304032003.89305.qmail@web52702.mail.yahoo.com> Received: from [202.91.78.244] by web52702.mail.yahoo.com via HTTP; Thu, 03 Mar 2005 19:20:03 PST Date: Thu, 3 Mar 2005 19:20:03 -0800 (PST) From: "Kamal R. Prasad" To: Julian Elischer In-Reply-To: <4227712F.5060906@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-hackers@freebsd.org Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kamalp@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 03:20:04 -0000 --- Julian Elischer wrote: > > > Kamal R. Prasad wrote: > > >--- Julian Elischer wrote: > > > > > > > >>Kamal R. Prasad wrote: > >> > >> > >> > >>>--- Lucas Holt wrote: > >>> > >>> > >>> > >>> > >>> > >>>>Wouldn't a multi threaded program potentially > need > >>>>more cpu time than > >>>>vi? > >>>> > >>>> > >>>> > >>>> > >>>No. That is not a given. > >>> > >>> > >>> > >>> > >>> > >>>>Multithreaded apps are created to do a lot of > >>>>computation or > >>>>because they have a lot of concurrent activity > >>>> > >>>> > >>that > >> > >> > >>>>might block right? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>Threads are meant to take advantage of > concurrency. > >>> > >>> > >>>Maybe the freebsd implementation should implement > >>> > >>> > >>NPTL > >> > >> > >>>in entirety. > >>> > >>> > >>> > >>> > >>NPTL? > >>New Pthreads Library from Library? > >> > >> > >Yes. > > > > > >>isn't that GPL'd? > >> > >> > >> > >No -it is a standard. The linux implementation of > nptl > >is gpl'ed. > >regards > >-kamal > > > > > > so how does that differ from what we have ... a > native pthreads library? > I just said if it was conformant with NPTL, thread and process scheduling would co-exist. regards -kamal > > > > > >===== > >------------------------------------------------------------ > >Kamal R. Prasad > >UNIX systems consultant > >kamalp@acm.org > > > >In theory, there is no difference between theory > and practice. In practice, there is:-). > >------------------------------------------------------------ > > > >__________________________________________________ > >Do You Yahoo!? > >Tired of spam? Yahoo! Mail has the best spam > protection around > >http://mail.yahoo.com > > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > ===== ------------------------------------------------------------ Kamal R. Prasad UNIX systems consultant kamalp@acm.org In theory, there is no difference between theory and practice. In practice, there is:-). ------------------------------------------------------------ __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 06:17:39 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC4EB16A4CF for ; Fri, 4 Mar 2005 06:17:39 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFD2C43D49 for ; Fri, 4 Mar 2005 06:17:38 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j246HSv4014393; Fri, 4 Mar 2005 07:17:29 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Perry E. Metzger" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 19:49:03 EST." <877jkogrr4.fsf@snark.piermont.com> Date: Fri, 04 Mar 2005 07:17:28 +0100 Message-ID: <14392.1109917048@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 06:17:39 -0000 In message <877jkogrr4.fsf@snark.piermont.com>, "Perry E. Metzger" writes: >I also very strongly suggest that the biggest real threat you face >isn't someone cracking AES but key management issues. CGD is in some >sense largely a framework for letting you do all sorts of neat things >with key management in a disk encryption context. You may want to add >similar features -- the most practical attack against your system as >it stands is a dictionary attack. This is where it would have been nice that you didn't jump into the middle of a discussion without reading the basic material. See my paper please. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 06:21:16 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5C6216A4CE for ; Fri, 4 Mar 2005 06:21:16 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2EE343D48 for ; Fri, 4 Mar 2005 06:21:15 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j246L2Cm014433; Fri, 4 Mar 2005 07:21:02 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Steven M. Bellovin" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 21:13:58 EST." <20050304021358.206813BFE3B@berkshire.machshav.com> Date: Fri, 04 Mar 2005 07:21:02 +0100 Message-ID: <14432.1109917262@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: tech-security@NetBSD.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com cc: tls@rek.tjls.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 06:21:16 -0000 In message <20050304021358.206813BFE3B@berkshire.machshav.com>, "Steven M. Bellovin" writes: >You can subscribe to that list by sending to cryptography@metzdowd.com. Feel free to post the link to my paper there. For reasons of mental bandwidth I must decline to subscribe to more mailing lists than I'm currently infected with, but that doesn't mean I am not interested in a discussion on the subject: just put me on the Cc:. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 06:22:26 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2B8716A4CE for ; Fri, 4 Mar 2005 06:22:26 +0000 (GMT) Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43F4343D1D for ; Fri, 4 Mar 2005 06:22:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.103] (adsl-68-123-125-47.dsl.snfc21.pacbell.net [68.123.125.47])j246MI5K169874; Fri, 4 Mar 2005 01:22:24 -0500 Message-ID: <4227FE95.3040209@elischer.org> Date: Thu, 03 Mar 2005 22:22:13 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050214 X-Accept-Language: en, hu MIME-Version: 1.0 To: "M. Warner Losh" References: <4226EB2E.7080507@gmail.com> <84dead7205030302567a0e7103@mail.gmail.com> <20050303.093642.115935187.imp@bsdimp.com> In-Reply-To: <20050303.093642.115935187.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: ary834@gmail.com cc: freebsd-hackers@freebsd.org Subject: Re: Collecting data in userland from kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 06:22:26 -0000 M. Warner Losh wrote: > In message: <84dead7205030302567a0e7103@mail.gmail.com> > Joseph Koshy writes: > : > First one is in general abt the method to be followed, I > : > have the following ideas ... [snip] > : > : Have you looked at netgraph(4) and ng_socket(4)? > > Or bpf(4)? or KTR? > > Warner > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 07:17:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99B3D16A4CE for ; Fri, 4 Mar 2005 07:17:10 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4829F43D54 for ; Fri, 4 Mar 2005 07:17:10 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.103] (adsl-68-123-125-47.dsl.snfc21.pacbell.net [68.123.125.47])j247H5Vl014832; Fri, 4 Mar 2005 02:17:06 -0500 Message-ID: <42280B6E.9010401@elischer.org> Date: Thu, 03 Mar 2005 23:17:02 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050214 X-Accept-Language: en, hu MIME-Version: 1.0 To: kamalp@acm.org References: <20050304032003.89305.qmail@web52702.mail.yahoo.com> In-Reply-To: <20050304032003.89305.qmail@web52702.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 07:17:10 -0000 Kamal R. Prasad wrote: > --- Julian Elischer wrote: > > > >>> >> >>so how does that differ from what we have ... a >>native pthreads library? >> > > I just said if it was conformant with NPTL, thread and > process scheduling would co-exist. in theory it does in FreeBSD's pthreads library. (though it needs work) > > regards > -kamal > From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 07:39:48 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70E2016A4CE for ; Fri, 4 Mar 2005 07:39:48 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FFE043D39 for ; Fri, 4 Mar 2005 07:39:47 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j247dVcL014891; Fri, 4 Mar 2005 08:39:32 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Perry E. Metzger" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 19:45:53 EST." <87bra0grwe.fsf@snark.piermont.com> Date: Fri, 04 Mar 2005 08:39:31 +0100 Message-ID: <14890.1109921971@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 07:39:48 -0000 In message <87bra0grwe.fsf@snark.piermont.com>, "Perry E. Metzger" writes: >My strong suggestion for you is that you adopt a similar approach -- >build a good framework that, given good algorithms, will provide >security, and make it easy for users to change over if an algorithm >falls. If you actually look at GBDE, you will see that any and all of the algorithms can be changed. They are used only in their most basic capability. This was part of the design from the start: not to rely on any single-source algorithm. >Well, so is stock AES 256. I don't see why I should assume your >construction is any better. What do you know that the NIST/NSA review >of AES did not know? That neither the authors of Rinjdael, its reviewers, nor NIST are willing to offer a 25 year warranty on it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 08:25:38 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9408016A4CE for ; Fri, 4 Mar 2005 08:25:38 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32DE343D1F for ; Fri, 4 Mar 2005 08:25:38 +0000 (GMT) (envelope-from wbierman@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so545929rnf for ; Fri, 04 Mar 2005 00:25:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=ZccgUMISTX5i97voYXyI7jNkiSCuTSdT1HPMJgg2lu7xCbajPeu2Ff87o57M7gpR8Tl+MK9L8SQyZCRnwftvKThmPANgHsfYh2HEfQYXWVXtacIAxDohdRZbM9eiCJwEouT1Mfj34iG++hUZuaIIUbc9wEm7pkEU3s2gGVER4Mg= Received: by 10.38.78.56 with SMTP id a56mr36404rnb; Fri, 04 Mar 2005 00:25:37 -0800 (PST) Received: by 10.38.88.21 with HTTP; Fri, 4 Mar 2005 00:25:37 -0800 (PST) Message-ID: Date: Thu, 3 Mar 2005 22:25:37 -1000 From: William Bierman To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: init troubles with custom install X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: William Bierman List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 08:25:38 -0000 Hello. I have been endeavoring to create my own livecd which will mount a remote share from which to run scripts installing a ghost image onto a local hard drive. I realize this may be more trouble than it's worth, but I am doing it to easily assimilate new machines into a Beowulf cluster... so I think it is. I have done everything I can think of to do this properly: 1) I used the process defined in the bsdlabel man page for setting up the slices/partitions/labels/etc. (search for dd in the man page) 2) I extracted the ghost images, in the form of tarballs, to the /, /usr, and /var slices. There is a partition for /tmp, but empty. I also setup a 1Gb swap slice. These slices are setup to mirror how they would be if I were to use the standard fbsd install cd. Now, here's the problem.. the kernel loads, and I start getting a list of the devices it detects, and it reaches the point of 'Mounting root from "ufs:ad0s1a"', then locks up. Either init is not being called, or is stalling somewhere. I have disabled pnp in my BIOS settings, and I have a single 16G IDE hard disk to which these operations are being performed. I have tried the various options in the boot menu (single user, safe mode, verbose logging, etc.) and the only useful information I get is when in verbose logging mode, it reaches the halt point, and additionally says: start_init: trying /sbin/init then halts. Could anyone shed some light on this for me? I can provide whatever additional information may be necessary. Thanks! William From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 09:16:17 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C15316A4D0; Fri, 4 Mar 2005 09:16:17 +0000 (GMT) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBCB943D1F; Fri, 4 Mar 2005 09:16:15 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from ppp2D01.dyn.pacific.net.au (ppp2D01.dyn.pacific.net.au [61.8.45.1])j249GAnW005063; Fri, 4 Mar 2005 20:16:12 +1100 From: Sam Lawrance To: Scott Long In-Reply-To: <42271FF6.9040103@samsco.org> References: <20050302212102.GK11079@elvis.mu.org> <42271FF6.9040103@samsco.org> Content-Type: text/plain Date: Fri, 04 Mar 2005 20:17:25 +1100 Message-Id: <1109927845.3361.5.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: Alfred Perlstein Subject: Re: truss bug + PATCH, pls review X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 09:16:17 -0000 On Thu, 2005-03-03 at 07:32 -0700, Scott Long wrote: > Alfred Perlstein wrote: > > Can someone review this? I think 'u' is incorrectly > > added to instead of assigned to. This causes the initial > > calculation to be garage based and screws up displaying > > poll information. > > > > I'd like this to be MFC'd before 5.4 if possible. > > > > Index: syscalls.c > > =================================================================== > > RCS file: /home/ncvs/src/usr.bin/truss/syscalls.c,v > > retrieving revision 1.45 > > diff -u -r1.45 syscalls.c > > --- syscalls.c 5 Sep 2004 05:27:30 -0000 1.45 > > +++ syscalls.c 2 Mar 2005 21:19:13 -0000 > > @@ -414,7 +414,7 @@ > > (POLLIN | POLLPRI | POLLOUT | POLLERR | POLLHUP | POLLNVAL | \ > > POLLRDNORM |POLLRDBAND | POLLWRBAND | POLLINIGNEOF) > > > > - u += snprintf(tmp + used, per_fd, > > + u = snprintf(tmp + used, per_fd, > > "%s%d 0x%hx%s%s%s%s%s%s%s%s%s ", > > i > 0 ? " " : "", > > pfd[i].fd, > > While you're on the subject of Trussburger, perhaps someone can comment on this Problem Report Meal. A McPatch is included. http://www.freebsd.org/cgi/query-pr.cgi?pr=71749 PS. It really is a McPatch. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 12:15:17 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F389D16A4CE for ; Fri, 4 Mar 2005 12:15:16 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id E050643D55 for ; Fri, 4 Mar 2005 12:15:15 +0000 (GMT) (envelope-from tomonage2@gmx.de) Received: (qmail invoked by alias); 04 Mar 2005 12:15:14 -0000 Received: from p54BF56F8.dip.t-dialin.net (EHLO [192.168.0.200]) (84.191.86.248) by mail.gmx.net (mp011) with SMTP; 04 Mar 2005 13:15:14 +0100 X-Authenticated: #7843803 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 04 Mar 2005 13:15:09 +0100 From: Jonathan Weiss To: FreeBSD-Hackers Message-ID: In-Reply-To: <200503041051.j24Apgd9022285@cvs.openbsd.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Y-GMX-Trusted: 0 Subject: FW:FreeBSD hiding security stuff X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 12:15:17 -0000 Whats the intention behind the FreeBSD developers policy? ------ Weitergeleitete Nachricht Von: Theo de Raadt Datum: Fri, 04 Mar 2005 03:51:42 -0700 An: Betreff: FreeBSD hiding security stuff A few FreeBSD developers apparently have found some security issue of some sort affecting i386 operating systems in some cases. They have refused to give us real details. A promise is now being made. If a bug is found in OpenSSH, which we believe to have security consequences, we wil inform FreeBSD last. Fair is fair. I really wish it was not this way, but after a week of trying to get the policy to be fixed, we are changing our policy as well. Without immediate action from them to repair their polcy, and a public apology for this, that policy will stand. ------ Ende der weitergeleiteten Nachricht From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 12:42:51 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E67016A4CF; Fri, 4 Mar 2005 12:42:51 +0000 (GMT) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0057143D62; Fri, 4 Mar 2005 12:42:51 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd5mr5so.prod.shaw.ca (pd5mr5so-qfe3.prod.shaw.ca [10.0.141.181]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICT003WRVBDER30@l-daemon>; Fri, 04 Mar 2005 05:42:49 -0700 (MST) Received: from pn2ml10so.prod.shaw.ca ([10.0.121.80]) by pd5mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICT006XSVBD0NK0@pd5mr5so.prod.shaw.ca>; Fri, 04 Mar 2005 05:42:49 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICT00E1ZVBCNM@l-daemon>; Fri, 04 Mar 2005 05:42:49 -0700 (MST) Date: Fri, 04 Mar 2005 04:42:48 -0800 From: Colin Percival In-reply-to: To: Jonathan Weiss Message-id: <422857C8.6050600@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: User-Agent: Mozilla Thunderbird 1.0 (X11/20050302) cc: freebsd-security@freebsd.org cc: FreeBSD-Hackers Subject: Re: FW:FreeBSD hiding security stuff X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 12:42:51 -0000 [I'm adding a CC: to freebsd-security, since I'm sure this thread will get reposted there if I don't. For those not subscribed to -hackers: Jonathan forwarded the an email Theo wrote to openbsd-misc: http://marc.theaimsgroup.com/?l=openbsd-misc&m=110993373705509&w=2 ] Jonathan Weiss wrote: > Whats the intention behind the FreeBSD developers policy? Quoting from secteam's TODO list for advisories: 1. Check if security officers need to be contacted at OpenBSD, NetBSD, OS X, or DragonFlyBSD. Yes, that's item #1 on our list. :-) In this case, I wasn't sure if OpenBSD was affected, so I emailed Theo asking for certain details which would allow me to make this determination. Theo wrote: > A few FreeBSD developers apparently have found some security issue > of some sort affecting i386 operating systems in some cases. s/A few FreeBSD developers/One FreeBSD developer/ I discovered this issue in December; until a few days ago I was working on it to determine whether it could be exploited. > They have refused to give us real details. Theo, in one of several replies, indicated that I should provide the details to Ted Unangst (tedu@). I contacted Ted and provided him with the details; he agreed with me about how and when it should be handled by OpenBSD. > A promise is now being made. > > If a bug is found in OpenSSH, which we believe to have security > consequences, we wil inform FreeBSD last. > > Fair is fair. > > I really wish it was not this way, but after a week of trying to get the > policy to be fixed, we are changing our policy as well. > > Without immediate action from them to repair their polcy, and a public > apology for this, that policy will stand. The policy of the FreeBSD security team is to notify other vendors and work with them to co-ordinate a disclosure schedule. It is also the policy of the FreeBSD security team to avoid disclosing security issues to anyone who does not need to know about them (i.e., anyone other than other affected vendors, admins@, and in some cases re@). I will make no apology for either of these, and I doubt anyone else (either from the security team, or the security officer himself) will do so either. Colin Percival From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 14:52:43 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB08416A4CE for ; Fri, 4 Mar 2005 14:52:43 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F27C43D46 for ; Fri, 4 Mar 2005 14:52:43 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j24EqW9t017361; Fri, 4 Mar 2005 15:52:32 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Perry E. Metzger" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 04 Mar 2005 09:02:55 EST." <877jknik4w.fsf@snark.piermont.com> Date: Fri, 04 Mar 2005 15:52:32 +0100 Message-ID: <17360.1109947952@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 14:52:44 -0000 In message <877jknik4w.fsf@snark.piermont.com>, "Perry E. Metzger" writes: >The best I can say, however, is that the US >government has approved the use of AES with 256 bit keys for very >highly secure communications, and they have a very demanding user >community. (There is a big difference in what crypto you need for communications, storage, and archiving.) My philosophy in this, (as implemented in GBDE), is to trust the algorithms to do their job, but to not offer an attacker any more leverage against them than I absolutely have to. It has been said by various people that "there are [currently] no cause to think that using the same key for many millions of sectors is a problem". I belive that is a fair and balanced summary, and I trust the people to know what they talk about and I belive them. Nontheless, I do not consider it good engineering to expose the algorithm to unnecessary stress, even if we currently belive we have a 220 bits margin of safety, if by trivial means, I can avoid that stress on the algorithm and maintain 256 bits of margin. Exactly where the line is between overkill and conservative engineering is always subject to individual preference and taste. I don't seriously think that either of CGD or GBDE will be broken through any other path than guessing or otherwise obtaining the passphrase. But in the case something unforeseen happens, I know that GBDE will yield its secrets only one sector at a time and CGD will spill all the eggs at once because it has only one basket. (Hans Christian Andersen wrote quite amuzingly about this 150 years ago in the story "The woman with the eggs".) As for making user selectable ciphers and keysizes I decided against it for two reasons. The first reason is that it adds complexity. The second is that it offers complexity. Adding complexity in the implementation is wrong for all the reasons we all agree on. To justify that complexity, a benefit must be proven. In all my interviews and talks with people, I found nobody who wanted that level of flexibility. Everybody, almost in unison sang from the "AES is the annointed king and 128 bit is the his key size." hymn. That surprised me initially. It transpired that people had a very simple and prosaic reasoning: "Anything else will give us footnotes during audits". Different ciphers will make the auditor write "the standard AES should have been used" even if the cipher used is agreed by everybody to be stronger. A longer keylength will result in a note about "unneccessary overkill and waste of resources". The other complexity is for the user. The more questions the user has to determine the correct answer to, the less likely he is to get it all right if he is not a subject matter specialist. My favourite question from a UNIX installer was something like: "Do you want this system configured according the the regulations set forth in [45 character of legal reference] ? [yes/no] _" And as you can guess, it didn't even offer a default to hint what one should choose. (As it later transpired, the option would disable the support for a locally connected printer.) Offering options in a situation where users will generally not dare using anything but the default is not only quite pointless, it is down right detrimal to user experience, and, probably, security. It used to be that I, as a UNIX wizard of some renown, knew what happened when a user logged into a FreeBSD box. But today, between ssh, opie, PAM, access.conf and what else gets in the way, I have to say that unless all settings are the default, it will take me considerable time to determine that no holes have been opened. I fully agree that we have gained fantastic flexibility through all these features, but I am not always convinced that they are a net improvement of security when measured over the set of all FreeBSD machines in the world. So I made the choice to structure the source code and the crypto path so that other algorithms could be slotted in by any minimally competent programmer, and stuck to the choice of algorithm which seems to be the king of the hill these days. If the wind or the king changes, the source code will adapt in less than a day. Finally, on keying schemes: I didn't put a keying scheme on GBDE because I belive in the "tools not policies" dogma. The gbde(8) userland program should be (but isn't quite) flexible enough to support any keying scheme people decide to use. And I also belive in the "many hands make light work", so I sort of hoped that people who knew more about public key crypto than me would produce scripts or frontends which implement sound keying schemes for GBDE based on these technologies. Poul-Henning PS: Will you be at BSDcan ? It would be a good chance to corner a whiteboard and some beer. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 14:55:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 358AF16A4CE for ; Fri, 4 Mar 2005 14:55:10 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7378743D3F for ; Fri, 4 Mar 2005 14:55:09 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j24Eshsb017469; Fri, 4 Mar 2005 15:54:43 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Jari Ruusu From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 04 Mar 2005 16:51:28 +0200." <422875F0.49877364@users.sourceforge.net> Date: Fri, 04 Mar 2005 15:54:43 +0100 Message-ID: <17468.1109948083@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: ALeine cc: elric@imrryr.org cc: Todd Vierling cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: "Perry E. Metzger" cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 14:55:10 -0000 In message <422875F0.49877364@users.sourceforge.net>, Jari Ruusu writes: >Early versions of loop-AES were FUBARed, true. But why do you insist on >ranting about fuckups that were fixed long time ago? I don't :-) The topic at hand was why I made certain choices for GBDE the way I did, what loop-AES did subsequent to that time is not really relevant. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 15:22:39 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA20A16A4CE for ; Fri, 4 Mar 2005 15:22:39 +0000 (GMT) Received: from britannica.bec.de (wlan034067.uni-rostock.de [139.30.34.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 711D843D46 for ; Fri, 4 Mar 2005 15:22:39 +0000 (GMT) (envelope-from joerg@britannica.bec.de) Received: by britannica.bec.de (Postfix, from userid 1001) id E8767A2; Fri, 4 Mar 2005 16:20:56 +0100 (CET) Date: Fri, 4 Mar 2005 16:20:56 +0100 From: Joerg Sonnenberger To: hackers@freebsd.org Message-ID: <20050304152056.GB1539@britannica.bec.de> Mail-Followup-To: hackers@freebsd.org References: <200503030217.j232HAGG088987@marlena.vvi.at> <20050303225849.0E7143700F@arioch.imrryr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050303225849.0E7143700F@arioch.imrryr.org> User-Agent: Mutt/1.5.8i Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 15:22:39 -0000 On Thu, Mar 03, 2005 at 05:58:49PM -0500, Roland Dowdeswell wrote: > Disklabels for example have a checksum. The checksum might not be > terribly strong, but the chance that two different valid disklabels > could even be decrypted with different keys is small, I would > imagine. The checksum takes off 2^32 seemingly valid disklabels > and what about the rest of the fields? There's lots of redundant > information in there that could be cross referenced. Actually this is the argument from PHK which I consider bogus and which makes the claims about the secure of GBDE bogus as well. I do believe that GBDE is stronger than CGD when both use the same algorithms, simple because there is more work to extract the interesting data from GBDE (more keys to crack). The whole argument of PHK why GBDE is so much stronger is based on the estimated number of collisions in the detection of likely good plain texts. As you mentioned, certain key structures of the disc indeed have a very high structure. As far as I know, tests for the distribution of the inverse encryption [ AES^{-1}{key} data ] are not very common, with the exception of known or choosen plaintext where input and output are known. IMO it would be a potential attack verctor as well, if you have a large number of such collisions, since that would mean the structure of the input is reflected in the structure of the output. Just to start with the claim of 2^384 (as random number) for a brute force attack and an average number of 17 sectors to decode until getting to the interesting data, we get sqrt^{17}{2^256} ~= 34131 collisions. Without a backing theory, I don't trust that number at all. I have no reason to believe that any but the correct key passes the test for a super block or whatever data structure there is. Not for a key length of 128 bit (or 256 bit for that matter). Situation changes with higher key length of course. Joerg From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 15:36:16 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59F5816A4CE for ; Fri, 4 Mar 2005 15:36:16 +0000 (GMT) Received: from priv-edtnes56.telusplanet.net (outbound01.telus.net [199.185.220.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAF5543D2D for ; Fri, 4 Mar 2005 15:36:15 +0000 (GMT) (envelope-from pfak@telus.net) Received: from [192.168.1.253] (really [64.180.103.26]) by priv-edtnes56.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP <20050304153615.EJTJ19778.priv-edtnes56.telusplanet.net@[192.168.1.253]>; Fri, 4 Mar 2005 08:36:15 -0700 Message-ID: <42288070.8030507@telus.net> Date: Fri, 04 Mar 2005 07:36:16 -0800 From: Peter Kieser User-Agent: Mozilla Thunderbird 0.6+ (Windows/20050216) MIME-Version: 1.0 To: Jonathan Weiss References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD-Hackers Subject: Re: FW:FreeBSD hiding security stuff X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 15:36:16 -0000 It's Theo, he's a drama queen. Probably best not to feed the troll. --Peter Jonathan Weiss wrote: >Whats the intention behind the FreeBSD developers policy? > > >------ Weitergeleitete Nachricht >Von: Theo de Raadt >Datum: Fri, 04 Mar 2005 03:51:42 -0700 >An: >Betreff: FreeBSD hiding security stuff > >A few FreeBSD developers apparently have found some security issue >of some sort affecting i386 operating systems in some cases. > >They have refused to give us real details. > >A promise is now being made. > >If a bug is found in OpenSSH, which we believe to have security >consequences, we wil inform FreeBSD last. > >Fair is fair. > >I really wish it was not this way, but after a week of trying to get the >policy to be fixed, we are changing our policy as well. > >Without immediate action from them to repair their polcy, and a public >apology for this, that policy will stand. > > >------ Ende der weitergeleiteten Nachricht > > From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 16:11:00 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A3D016A4CE for ; Fri, 4 Mar 2005 16:11:00 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FB8E43D4C for ; Fri, 4 Mar 2005 16:11:00 +0000 (GMT) (envelope-from opensource.enthousiat@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so740054wri for ; Fri, 04 Mar 2005 08:10:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=C6rMcPdkAV7PmOy2phs0ezQqqHMxpcxTgUuv/HT7xw7AKGTyZOnW8WVrA+gO02FuI+9cQHZKBo03k8KSHhLJk2lmUj78fivnI+hjcFvJck/aA8GYtcEHVegunRaoa+7F+BUdzxjJWrA4XOXOEWTf/uewaMC2AY1preVttXCNRaY= Received: by 10.54.34.52 with SMTP id h52mr15086wrh; Fri, 04 Mar 2005 08:08:34 -0800 (PST) Received: by 10.54.49.28 with HTTP; Fri, 4 Mar 2005 08:07:34 -0800 (PST) Message-ID: <37e13166050304080715525d7e@mail.gmail.com> Date: Fri, 4 Mar 2005 11:07:34 -0500 From: Aziz KEZZOU To: freebsd-net@freebsd.org, hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: generic network protocols parser ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Aziz KEZZOU List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 16:11:00 -0000 Hi all, I am wondering if any one knows about a generic parser which takes a packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates some data structre representing the packet ? I've been searching for a while and found that ethereal and tcpdump for example use specific data structres and functions to dissect each protocol packets. Is this the only approach possible ? My supervisor suggested using a TLV (Type/Length/Value) approach instead. Any opinions about that? If no such a parser exists is there any practical reason why ? Thanks, Aziz From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 16:19:31 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DEA516A4CE for ; Fri, 4 Mar 2005 16:19:31 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DEBC43D41 for ; Fri, 4 Mar 2005 16:19:31 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id 5EE123551D for ; Fri, 4 Mar 2005 18:19:28 +0200 (EET) Message-ID: <000c01c520d5$f1042230$090210ac@BORJA> From: "Andriy Tkachuk" To: Date: Fri, 4 Mar 2005 21:49:25 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: sched_ule, runqueues, priority, and O(1) sheduling question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 16:19:31 -0000 Hi folks. I wander how O(1) sheduling works in ULE. In ule.pdf Jeff wrote: Threads are picked from the current queue in priority order until the current queue is empty. As far as I understand the algorithm is O(n) where n - number of READY TO RUN processes, not all processes isn't it? thanks, Andriy. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 15:48:50 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA7CD16A4CE for ; Thu, 3 Mar 2005 15:48:49 +0000 (GMT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE42B43D2D for ; Thu, 3 Mar 2005 15:48:48 +0000 (GMT) (envelope-from tls@rek.tjls.com) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id F3A87595E6; Thu, 3 Mar 2005 10:48:47 -0500 (EST) Received: (from tls@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j23Fmln29519; Thu, 3 Mar 2005 10:48:47 -0500 (EST) Date: Thu, 3 Mar 2005 10:48:47 -0500 From: Thor Lancelot Simon To: Poul-Henning Kamp Message-ID: <20050303154847.GA3454@panix.com> References: <20050303120421.GW86348@cicely12.cicely.de> <7153.1109852325@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7153.1109852325@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tls@rek.tjls.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 15:48:50 -0000 On Thu, Mar 03, 2005 at 01:18:45PM +0100, Poul-Henning Kamp wrote: > In message <20050303120421.GW86348@cicely12.cicely.de>, Bernd Walter writes: > > >No matter what disk you take - writes never have been atomic. > >The major difference I see is that you get a read error back in > >the disk failure case, while such a crypto failure produces more or > >less random data without any error. > >Mounting unclean filesystems rw for bg_fsck can be considered > >dangerous with such unexpected data corruption. > >And how would you know that a restore from backup is required for > >a damaged file? > > 100% true. > > The trouble is that it would cost a lot in performance and a doubling > in metadata to protect yourself against this. No, it would not. What it _would_ take would be an abandonment of the adamant position that your home-grown cryptosystem is superior to simply encrypting the disk with 256-bit AES. After all, cgd doesn't diminish the atomicity of writes; it's only your key-key blocks that create this problem. Generally, complexity is not considered a desirable property in cryptosystems. GBDE violates this rule in spades. There are _reasons_ why complexity is not good: to begin with, a very complex cryptographic construct will require detailed analysis (which it does not appear GBDE has had by anyone but its author until Roland started looking at it) in order that we may know that it is even as secure as the underlying algorithmic building blocks it uses. Furthermore, with a very complex cryptographic construct it is easy to persuade oneself that the complexity actually has security benefits which it does not, and thus go forth into the dangerous world unprotected from _other_ attacks that one overconfidently ignores. I'd say that is certainly going on here as well (e.g. the continual minimization of how GBDE's implementation makes dictionary attacks easier). I have often observed the phenomenon that engineers who build extremely complicated software systems insist vigorously that, due to their very complexity (or perhaps due to the amount of time they've spent building them) they _must_ be better than simpler systems that are easier to implement and maintain. One might characterize this as the love of one's own big ideas. The best antidote to this is to ask not "do I believe that all this complexity could plausibly have some benefit" but rather "is there some shortcoming in the simple system that could plausibly justify all this complexity"; in other words, to begin from the assumption that complexity is bad. In the case of CGD and GBDE I think the answer is plainly "no, there is not". To believe that I wanted something better, I'd essentially have to believe that AES256 were vulnerable to, at best, a chosen- plaintext attack. The key derivation is solid (and standard); the encryption is solid (and standard); and it is a strong point in the system's favor that it does not _try_ to give me more than I want from it. Compare to GBDE, where a massively complicated construct using double-encryption -- and MD5! -- is used to splat keys all over the disk but no attention is paid to key derivation at all. That this conversation has degenerated to the point that GBDE's proponents are claiming that it _would be_ more secure _if_ only someone knew how to break 256-bit AES is to me a pretty good indicator of why GBDE is not encryption software that I want to use. -- Thor Lancelot Simon tls@rek.tjls.com "The inconsistency is startling, though admittedly, if consistency is to be abandoned or transcended, there is no problem." - Noam Chomsky From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 16:37:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E5FE16A4CE for ; Thu, 3 Mar 2005 16:37:33 +0000 (GMT) Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id AACA343D55 for ; Thu, 3 Mar 2005 16:37:32 +0000 (GMT) (envelope-from tls@rek.tjls.com) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id D829E981BE; Thu, 3 Mar 2005 11:37:31 -0500 (EST) Received: (from tls@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j23GbVH13212; Thu, 3 Mar 2005 11:37:31 -0500 (EST) Date: Thu, 3 Mar 2005 11:37:31 -0500 From: Thor Lancelot Simon To: Poul-Henning Kamp Message-ID: <20050303163731.GA8001@panix.com> References: <200503021910.j22JAGCH081224@marlena.vvi.at> <8706.1109867494@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8706.1109867494@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@netbsd.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tls@rek.tjls.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 16:37:33 -0000 On Thu, Mar 03, 2005 at 05:31:34PM +0100, Poul-Henning Kamp wrote: > In message <200503021910.j22JAGCH081224@marlena.vvi.at>, "ALeine" writes: > > >Not necessarily, if one were to implement the ideas I proposed > >I believe the performance could be kept at the same level as now. > > I gave up on journalling myself because IMO it complicates > things a lot and the problem it solves is very very small. > > The impact in disk seeks is non-trivial to predict, but it is > very hard to argue that it will not lead to an increase in > disk seeks. (This is really a variant of the age old argument > between jounaling filesystems and "traditional" filesystems) > > I can only recommend that you try :-) > > We need more ideas and more people trying out ideas. I could not disagree more. When it comes to nonstandard homebrewed cryptosystems foisted off on unsuspecting users with a bundle of claims of algorithm strength that they're not competent to evaluate for themselves, we do not need more ideas, nor more people trying out ideas; we need less. Standard, widely analyzed cryptographic algorithms are good. -- Thor Lancelot Simon tls@rek.tjls.com "The inconsistency is startling, though admittedly, if consistency is to be abandoned or transcended, there is no problem." - Noam Chomsky From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 16:57:34 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A3E116A4CE for ; Thu, 3 Mar 2005 16:57:34 +0000 (GMT) Received: from machshav.com (machshav.com [147.28.0.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07B0943D3F for ; Thu, 3 Mar 2005 16:57:34 +0000 (GMT) (envelope-from smb@cs.columbia.edu) Received: by machshav.com (Postfix, from userid 512) id A3C8EFB28F; Thu, 3 Mar 2005 11:57:33 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 91410FB285; Thu, 3 Mar 2005 11:57:32 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 8931C3BFDBA; Thu, 3 Mar 2005 11:57:30 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: netbsd From: "Steven M. Bellovin" To: tls@rek.tjls.com In-Reply-To: Your message of "Thu, 03 Mar 2005 11:37:31 EST." <20050303163731.GA8001@panix.com> Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 03 Mar 2005 11:57:30 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050303165730.8931C3BFDBA@berkshire.machshav.com> X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@NetBSD.org cc: Poul-Henning Kamp cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 16:57:34 -0000 In message <20050303163731.GA8001@panix.com>, Thor Lancelot Simon writes: >On Thu, Mar 03, 2005 at 05:31:34PM +0100, Poul-Henning Kamp wrote: >> In message <200503021910.j22JAGCH081224@marlena.vvi.at>, "ALeine" writes: >> >> >Not necessarily, if one were to implement the ideas I proposed >> >I believe the performance could be kept at the same level as now. >> >> I gave up on journalling myself because IMO it complicates >> things a lot and the problem it solves is very very small. >> >> The impact in disk seeks is non-trivial to predict, but it is >> very hard to argue that it will not lead to an increase in >> disk seeks. (This is really a variant of the age old argument >> between jounaling filesystems and "traditional" filesystems) >> >> I can only recommend that you try :-) >> >> We need more ideas and more people trying out ideas. > >I could not disagree more. When it comes to nonstandard homebrewed >cryptosystems foisted off on unsuspecting users with a bundle of >claims of algorithm strength that they're not competent to evaluate >for themselves, we do not need more ideas, nor more people trying >out ideas; we need less. > >Standard, widely analyzed cryptographic algorithms are good. > What Thor said. It's instructive to quote from Vol. 2 of Knuth: With all the precautions taken in Algorithm K, doesn't it seem plausible that it would produce at least an infinite supply of unbelievably random numbers? No! In fact, when this algorithm was first put onto a computer, it almost immediately converged to the 10-digit value 6065038420, which---by extraordinary coincidence---is transformed into itself by the algorithm (see Table 1). With another starting number, the sequence began to repeat after 7401 values, in a cyclic period of length 3178. The moral to this story is that *random numbers should not be generated with a method chosen at random*. Some theory should be used. And Knuth was talking about a situation without an adversary. I don't claim that there's a flaw. I do assert that that I haven't seen a threat model that would justify extra complexity. Let me go one step further. The cryptographic literature is full of examples of broken protocols. My favorite is the flaw in the original Needham-Schroeder protocol, from 1978, that went unnoticed until 1996, when an automated tool found it. I should add that once pointed out, the flaw is blindingly obvious -- but it went unnoticed for 18 years, in the oldest protocol in the open literature. Btw, in modern terms this protocol is 3 lines long. One more quote, this time a remarkably prescient one from that Needham and Schroeder: Finally, protocols such as those developed here are prone to extremely subtle errors that are unlikely to be detected in normal operation. The need for techniques to verify the correctness of such protocols is great, and we encourage those interested in such problems to consider this area. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 18:10:45 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D31F716A4CE for ; Thu, 3 Mar 2005 18:10:45 +0000 (GMT) Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47D1143D46 for ; Thu, 3 Mar 2005 18:10:45 +0000 (GMT) (envelope-from tls@rek.tjls.com) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id CD94A98190; Thu, 3 Mar 2005 13:10:44 -0500 (EST) Received: (from tls@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j23IAiq23595; Thu, 3 Mar 2005 13:10:44 -0500 (EST) Date: Thu, 3 Mar 2005 13:10:44 -0500 From: Thor Lancelot Simon To: Poul-Henning Kamp Message-ID: <20050303181044.GA6732@panix.com> References: <20050303165730.8931C3BFDBA@berkshire.machshav.com> <9418.1109872131@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9418.1109872131@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@netbsd.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tls@rek.tjls.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 18:10:46 -0000 On Thu, Mar 03, 2005 at 06:48:51PM +0100, Poul-Henning Kamp wrote: > In message <20050303165730.8931C3BFDBA@berkshire.machshav.com>, "Steven M. Bellovin" writes: > > >And Knuth was talking about a situation without an adversary. > > If the component (well respected etc etc) algorithms I have used > in GBDE contains flaws so that they become individually less > intrinsicly safe because their input is the output of another such > algorithm, then the crypto-world has problems they need to work on. The algorithms in question are evaluated _for a particular purpose_. It is absurd to claim that because those algorithms are generally considered suitable for one (or more) particular purposes, it is reasonable to consider them suitable for all purposes. It is plainly possible to use even well-understood algorithms that are indeed acceptably secure for their design purposes in ways that in fact do not provide the security one naively claims. Steve's Needham-Schroeder example is a good case: should we claim that the flaw in question cannot exist unless there is some fundamental flaw in DES? I note that GBDE uses a number of algorithms in ways that are not consistent with their design purposes. For instance, it truncates a non-keyed hash (SHA512); the fact that this is not necessarily a good idea is one of the major motivators for the design of HMAC. It also uses MD5 in a way that I would characterize as not exactly ordinary -- leaving aside that using MD5 at all is a questionable proposition these days. Indeed, the large number of algorithms used in the keying and encryption process for any block in GBDE does not necessarily increase its security: in fact, certain kinds of flaws in any one of those algorithms could in fact make the decryption of any particular block _more_ likely -- and Roland has pointed out how the design of GBDE allows such failures to cascade through the entire set of encrypted data. In other words, unless you are very, very careful about design (the TLS PRF is one example of this) using more algorithms may well make you less secure, not more secure: you may inherit vulnerability to flaws in _any_ of the algorithms you use. > Considering the protection periods people asked for, I could convince > neither myself nor any of the, (often very clued) people I talked > to, that just taking a current standard algorithm and applying > it using the same keymaterial to each sector of the media would be > safe for a sufficient amount of time. Fine. You don't believe that AES256 will be sufficiently resistant to known- (or perhaps chosen-) plaintext attacks for the next several decades. The question is, what rational warrant do you have for believing that your cryptosystem will be more secure than AES256 would be. The very complexity of your system makes it very, very difficult to evaluate just how secure it is, and you seem to think that that is a benefit: comparing the incommensurables "I don't believe" and "I don't know, but I suspect", you land on the side of "I suspect". Somehow I do not find that terribly persusasive. Thor From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 18:50:52 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81B3116A4D0 for ; Thu, 3 Mar 2005 18:50:52 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B1A143D64 for ; Thu, 3 Mar 2005 18:50:51 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id C513ED989A; Thu, 3 Mar 2005 13:50:49 -0500 (EST) To: "Poul-Henning Kamp" References: <8706.1109867494@critter.freebsd.dk> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 13:50:49 -0500 In-Reply-To: <8706.1109867494@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 03 Mar 2005 17:31:34 +0100") Message-ID: <87is48k1h2.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 18:50:52 -0000 "Poul-Henning Kamp" writes: > We need more ideas and more people trying out ideas. There is a profession called "cryptographer" out there. They are the folks who try out these new ideas, and they fill lots of conference proceedings with their new ideas, including things like crypto modes designed specifically for disk encryption. People who are members of this profession spend many years learning what is and is not likely to work when it comes to various cryptographic schemes, and they often learn the hard way that most new ideas in cryptography fail under scrutiny. Even the best of them are very leery of recommending the use of their own new schemes in the real world before they have been heavily reviewed. Even if you are Ron Rivest or Don Coppersmith, you make mistakes, and sometimes bad ones. Were you a cryptographer, and were you proposing, in a theoretical way, a new cryptographic mode for doing disk encryption, and were you presenting it in a paper at Crypto or some such, well, that would be perfectly fine. People could then review it, tear it apart (or fail to) etc, and no one would be harmed. Instead, however, what is happening is that you are implementing your ideas, which do not appear to be very well founded in the experience the crypto community has gained at great price, and they're being tested first on actual users before any peer review of your design. You are hardly the first to do this of course. You follow in a long tradition. The 802.11 folks who designed WEP, the people who designed the security for Bluetooth, the authors of numerous PC security products, and many others, have all rolled their own crypto without being cryptographers and handed it off to unsuspecting users. The results range from unfortunate to downright deadly. WEP was a particularly amusing case, because, like you, its designers thought that it was safe to use an existing encryption algorithm in ways that they never even realized were new and potentially damaging. They didn't understand what they were doing, and so the results were very bad. Let me also mention that everyone who does crypto work hears, at intervals, what horrid insular people cryptographers are and how little respect they have for "outsiders". Actually, nothing could be further from the truth. The crypto community is very open -- but it is a meritocracy, and merit is not demonstrated by throwing lots of stuff to the wall and seeing what sticks. Perry From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 19:04:56 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBCF216A4CE for ; Thu, 3 Mar 2005 19:04:56 +0000 (GMT) Received: from hiroshima.ihack.net (209-6-103-199.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.103.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 575F643D1D for ; Thu, 3 Mar 2005 19:04:56 +0000 (GMT) (envelope-from abuse@spamalicious.com) Received: by hiroshima.ihack.net (Postfix, from userid 27753) id 63B6A2A65D5; Thu, 3 Mar 2005 19:04:26 +0000 (UTC) From: "Charles M. Hannum" Organization: By Noon Software, Inc. To: "ALeine" Date: Thu, 3 Mar 2005 19:04:25 +0000 User-Agent: KMail/1.7 References: <200503022115.j22LFnWk083926@marlena.vvi.at> In-Reply-To: <200503022115.j22LFnWk083926@marlena.vvi.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503031904.26219.abuse@spamalicious.com> X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@netbsd.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: elric@imrryr.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 19:04:56 -0000 On Wednesday 02 March 2005 21:15, ALeine wrote: > phk@phk.freebsd.dk wrote: > > I gave up on journalling myself because IMO it complicates > > things a lot and the problem it solves is very very small. > > If only hardware manufacturers were to equip hard drives with > a mechanism to ensure atomic writes. A capacitor large enough > to hold enough energy to flush the cache upon detecting the > power supply was cut would be sufficient. This has come up many times. In reality, no, that's nowhere near sufficient, because you might have to employ error correction during the write. In addition, in modern disks, the emphasis at power loss is on getting the heads off the disk as fast as possible -- if you don't, the disk is dead -- so any power available is devoted to that. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 19:38:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5173616A4E2 for ; Thu, 3 Mar 2005 19:38:42 +0000 (GMT) Received: from rs6.luxsci.com (rs6.luxsci.com [65.61.136.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id A610343D2F for ; Thu, 3 Mar 2005 19:38:41 +0000 (GMT) (envelope-from tv@duh.org) Received: from mail.duh.org (adsl-066-156-066-024.sip.asm.bellsouth.net [66.156.66.24]) (authenticated bits=0) by rs6.luxsci.com (8.12.11/8.12.11) with ESMTP id j23JcH3x000643 verify=NOT); Thu, 3 Mar 2005 13:38:20 -0600 Received: from localhost (localhost [127.0.0.1]) by mail.duh.org (8.13.1/8.13.1) with ESMTP id j23JbOA7001240; Thu, 3 Mar 2005 14:37:25 -0500 (EST) Date: Thu, 3 Mar 2005 14:37:24 -0500 (EST) From: Todd Vierling To: Poul-Henning Kamp In-Reply-To: <10479.1109877918@critter.freebsd.dk> Message-ID: References: <10479.1109877918@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: elric@imrryr.org cc: "Perry E. Metzger" cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 19:38:42 -0000 On Thu, 3 Mar 2005, Poul-Henning Kamp wrote: > At the time where I wrote GBDE, the best that was offered was CGD (and > similar) and users (not cryptographers!) didn't trust it Could you back up this claim, insofar that "users" did not trust cgd? I haven't seen any distrust of cgd -- in fact, I've seen quite a bit of welcome acceptace of cgd by both users *and* cryptographers. -- -- Todd Vierling From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 20:00:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 546C516A4CE for ; Thu, 3 Mar 2005 20:00:06 +0000 (GMT) Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id D199C43D3F for ; Thu, 3 Mar 2005 20:00:05 +0000 (GMT) (envelope-from tls@rek.tjls.com) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 47C2E98213; Thu, 3 Mar 2005 15:00:05 -0500 (EST) Received: (from tls@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j23K05C00242; Thu, 3 Mar 2005 15:00:05 -0500 (EST) Date: Thu, 3 Mar 2005 15:00:05 -0500 From: Thor Lancelot Simon To: Poul-Henning Kamp Message-ID: <20050303200005.GA21499@panix.com> References: <87is48k1h2.fsf@snark.piermont.com> <10479.1109877918@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10479.1109877918@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@netbsd.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tls@rek.tjls.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:00:06 -0000 On Thu, Mar 03, 2005 at 08:25:18PM +0100, Poul-Henning Kamp wrote: > > At the time where I wrote GBDE, the best that was offered was CGD (and > similar) and users (not cryptographers!) didn't trust it and history > have so far repeated. To quote David Hume, "Never an ought from an is." That "users" (who are they? how many of them? What criterion or criteria of trust do they apply?) _did_ not trust X says precisely nothing about whether users _should_ not trust X. You seem to deny that there is a particular domain of expertise that is cryptography, or perhaps more rightly two domains, one being largely a subset of the other: how to design good cryptographic algorithms and how to use good cryptographic algorithms safely. Personally, I think that you ought to know better, and that your insistence that there is no such expertise and that arbitrary users (or programmers guided by the sentiment of such users) should feel just as warranted to make recommendations about what other arbitrary users should do, in this domain, is grossly irresponsible. If you found out that "most army ordnance officers believe that ball powder is superior to IMR powder as a propellant in small-caliber rifle cartridges", would you ignore the advice of the engineer who designed and tested your new rifle that ball powder would cause the weapon to jam? A lot of people in Vietnam got dead that way: sometimes experts do know what they're talking about, you know, and sometimes giving uninformed advice can have extremely negative consequences. You call Roland's criticisms of GBDE "handwaving". It is very hard to see how his specific refutations of the numerical claims of security that you made in your GBDE paper should be rightly considered as such, or why, on the basis of those false claims, you should continue to feel confident that your advice on disk security is good advice. Thor From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 20:12:26 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7141B16A4CE for ; Thu, 3 Mar 2005 20:12:26 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E13443D1F for ; Thu, 3 Mar 2005 20:12:25 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id E0440D988C; Thu, 3 Mar 2005 15:12:23 -0500 (EST) To: "Poul-Henning Kamp" References: <10479.1109877918@critter.freebsd.dk> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 15:12:23 -0500 In-Reply-To: <10479.1109877918@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 03 Mar 2005 20:25:18 +0100") Message-ID: <87ekewjxp4.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:12:26 -0000 "Poul-Henning Kamp" writes: > In message <87is48k1h2.fsf@snark.piermont.com>, "Perry E. Metzger" writes: >>There is a profession called "cryptographer" out there. They are the >>folks who try out these new ideas, and they fill lots of conference >>proceedings with their new ideas, including things like crypto modes >>designed specifically for disk encryption. > > There is a world out here that's called the IT industry. Yes, there is. They routinely deploy bad security because they don't get people who know what they are doing involved. See WEP, for example, or a thousand other things. > When they badly needed a new password scrambler nobody from that > cryptographic discipline could be bothered with a problem already > long since solved in their academic journals and the task fell to > a more or less random programmer in the end. I have no idea what you're talking about, but if it is the original password hash algorithm in Unix, it was written by Bob Morris Sr., who went on to become one of the top technical guy at the NSA. If you're talking about MD5 which is used in many modern Unixes, it was done by Ron Rivest, and even though he's really good, it has recently been (quite badly) broken. > At the time where I wrote GBDE, the best that was offered was CGD (and > similar) and users (not cryptographers!) didn't trust it and history > have so far repeated. I have no idea what you are talking about here. Can you find me a significant number of users who had CGD available and didn't want to use it? It was only available on NetBSD so far as I know, and it was adopted pretty quickly once it appeared. > I can add another property of the elite society of cryptographers: > if you are not a card carrying member of their society, the majority > of their members can not even be bothered to reply to an email from > an outsider. This does hamper communiation a bit. Actually, you can show up at any crypto conference you like, and you'll likely be taken seriously so long as you know what you're talking about even if the people talking to you have no idea who you are. As with most gatherings of geeks, the only real ticket you need is competence. There are also plenty of places to send email to cryptographers where you will be inundated with replies. If you had forwarded a description of your disk protection work to cryptography@metzdowd.com, you would have gotten plenty of responses. The same is probably true of sci.crypt and lots of other places. > Maybe the problem is that cryptographers, like true computer > scientists, write in nothing less portable than pencil number two ? It is rare to see a new algorithm show up from someone like Ron Rivest without some C code also appearing. That's pretty common in the crypto world. When the Chinese team that cracked a bunch of hash algorithms last summer presented their work, they had worked examples of their stuff. However, how is this relevant? Would you deride your doctor for not programming? Do you write medical diagnostic software without so much as reading a medical journal or talking to a doctor? There is no shame in admitting that there may be other fields than "software engineering" that have valuable information to share with you. > If some card-carrying member of the cryptographic establishment were > to offer the Open Source operating systems an implementation which > were approved by all (or some qualified quorum of) the high priests > of their brother hood, then I am sure that it would be received with > praise and thanks of no end. I think you don't quite get it the point. 1) No one claims that you need to be a cryptographer to write something like GBDE. What is being claimed is that you should not have invented your own cryptographic modes, and that you might have wanted to ask some professionals about your approach. 2) CGD *has* been looked at by a bunch of people, and was written to carefully use standard algorithms in a standard way. If you don't like using NetBSD code because NetBSD people have cooties, fine -- I don't care, write your own. However, you should at least pay the same attention to conservative use of cryptographic algorithms and having people review your work is a good idea, too. 3) You've made some very bizarre claims about the security of your system. Some of these claims have already been shown on their face to be incorrect, such as your claimed work factor for breaking your new "improved" crypto modes. Some of your claims are harder to disprove but none the less seem suspicious. Other comments have been made to the effect that you have ignored certain threat models. Now, when Phil Zimmermann was criticized for inventing Bass-o-Matic for PGP v1 and for otherwise not designing things right, he could have dug in his heels and said "I don't see why I should do anything differently." Instead, he admitted his mistakes and wrote a version 2. Are your users better served by you digging in your heels and saying "GDBE is perfect as it is", or by admitting you are wrong and changing your design? Will you be like Phil Zimmermann or like the guys who peddle snake oil crypto? Your choice how you want to be known -- as someone who admits mistakes, or as someone too proud to ever change his work to fix problems. Perry From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 20:14:59 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3F7416A4CE for ; Thu, 3 Mar 2005 20:14:59 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FE8943D4C for ; Thu, 3 Mar 2005 20:14:59 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id 9D140D9877; Thu, 3 Mar 2005 15:14:58 -0500 (EST) To: "Poul-Henning Kamp" References: <9678.1109872268@critter.freebsd.dk> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 15:14:58 -0500 In-Reply-To: <9678.1109872268@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 03 Mar 2005 18:51:08 +0100") Message-ID: <87acpkjxkt.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:14:59 -0000 "Poul-Henning Kamp" writes: > Don't let peole like Thor scare you away, progress happens when people > try to follow their ideas, even if told that they are fools by people > who (think they) know better. They laughed at Fulton. They also laughed at Bozo the Clown. There is nothing wrong with innovation, but there is nothing wrong with reading the literature, either. Perry From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 20:43:41 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0D3216A4CE for ; Thu, 3 Mar 2005 20:43:41 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1B5943D39 for ; Thu, 3 Mar 2005 20:43:40 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id EF175D989A; Thu, 3 Mar 2005 15:43:39 -0500 (EST) To: "ALeine" References: <200503022348.j22Nm48I086259@marlena.vvi.at> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 15:43:39 -0500 In-Reply-To: <200503022348.j22Nm48I086259@marlena.vvi.at> (aleine@austrosearch.net's message of "Wed, 2 Mar 2005 15:48:04 -0800 (PST)") Message-ID: <873bvcjw90.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@NetBSD.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: elric@imrryr.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:43:42 -0000 "ALeine" writes: >> There is a profession called "cryptographer" out there. They are >> the folks who try out these new ideas, and they fill lots of >> conference proceedings with their new ideas, including things like crypto >> modes designed specifically for disk encryption. > > You are mistaking people who design cryptographic algorithms and those > who design cryptographic systems which integrate those algorithms into > functional systems. No, I am not. PHK invented new cryptographic modes for his work. The fact that he does not understand this is part of the problem. >> People who are members of this profession spend many years >> learning what is and is not likely to work when it comes to various >> cryptographic schemes, and they often learn the hard way that >> most new ideas in cryptography fail under scrutiny. Even the best of them >> are very leery of recommending the use of their own new schemes in >> the real world before they have been heavily reviewed. Even if you >> are Ron Rivest or Don Coppersmith, you make mistakes, and sometimes bad >> ones. > > Would you care to explain what qualifies Roland as a more competent > cyrptographic system designer than PHK? Roland didn't try to do anything that wasn't already heavily understood in the literature. He invented no cryptographic modes. He used only algorithms that have been pre-vetted. He also asked a bunch of people who know better than he does to check his work. Thus, you don't have to trust Roland at all. He didn't invent any new way of using any of the algorithms. You have to trust only the designers of the block cipher you choose to use (I'd suggest AES) and the password algorithm you choose to use (though the PKCS stuff is very good already). In order to permit even greater defense against key cracking, he put in a very standard and straightforward mechanism to permit N factor authentication. >> Were you a cryptographer, and were you proposing, in a >> theoretical way, a new cryptographic mode for doing disk encryption, >> and were you presenting it in a paper at Crypto or some such, well, >> that would be perfectly fine. People could then review it, tear it >> apart (or fail to) etc, and no one would be harmed. > > The papers are there, the code is there, review it, analyze it, talk > about it on TV. Just because it was not done in the way academics > like to do it does not mean it has any less merit. Heck, I would love > to see Erez Zadok's NCryptFS, but the academic process seems to be so > slow that we'll be lucky to see anything before 2006. If PHK took > that road we'd be looking forward to GBDE in FreeBSD 7. Somehow, Roland managed to write CGD without any real trouble. That's because rather than innovating, he used well understood primitives in well understood ways. >> Instead, however, what is happening is that you are implementing >> your ideas, which do not appear to be very well founded in the >> experience the crypto community has gained at great price, and >> they're being tested first on actual users before any peer review >> of your design. > > There is a reason everything happens so slowly in the academic > circles. Everyone is trying to cover their asses and trying so > hard not to be wrong that they analyze everything ad nauseum. No. You Do Not Understand. Cryptography is *brittle*. This has nothing to do with academic sloth. The point is that the best designers routinely have their work smashed to little bits. Are you as good a cryptographer as Ron Rivest? I certainly am not. Somehow, however, MD5 has been crushed anyway. This is not unusual. Cryptographic algorithms are not like sorting algorithms or graph traversal algorithms. When you're doing 3DES, it is not obvious that doing the CBC on the outside instead of between the rounds is critical to good security -- indeed it wasn't obvious even to trained cryptographers. If you aren't as good as Ron Rivest, then why are you expecting to design a new cryptographic mode on your first try without any issues arising? >> WEP was a particularly amusing case, because, like you, its >> designers thought that it was safe to use an existing encryption >> algorithm in ways that they never even realized were new and potentially >> damaging. They didn't understand what they were doing, and so the >> results were very bad. > > WEP relies on RC4 and has a 24-bit IV which means the key stream will > definitely get reused after 5 hours of heavy traffic. WEP is even weaker than its design. That is because its designers did not know what they were doing. Inventing new cryptographic modes is dangerous. >> Let me also mention that everyone who does crypto work hears, at >> intervals, what horrid insular people cryptographers are and how >> little respect they have for "outsiders". Actually, nothing could >> be further from the truth. The crypto community is very open -- but >> it is a meritocracy, and merit is not demonstrated by throwing lots >> of stuff to the wall and seeing what sticks. > > Everyone who has the proper education from one of the elite > universities, knows the right people, has not dared publish > anything seriously relevant to outdo their mentor before he > retires and everyone who dismisses everyone else who does not > have the same pedigree of a proper cryptographer is welcome > to join the crypto community, of course. Anyone can get a paper published at Crypto or Eurocrypt. You need no PhD or other credentials. All you have to do is have something interesting to say. People who are "outsiders" get stuff published. Your claim is baseless. In general, geeks are meritocratic. Crypto people are not unlike other geeks. If you find that crypto people laugh at you, it is probably not because you don't know the right people, but because you put your foot in your mouth and swallowed hard. Perry From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 20:52:49 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D447816A4CE for ; Thu, 3 Mar 2005 20:52:49 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3388343D39 for ; Thu, 3 Mar 2005 20:52:49 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id 76246D989A; Thu, 3 Mar 2005 15:52:48 -0500 (EST) To: "Poul-Henning Kamp" References: <10983.1109882590@critter.freebsd.dk> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 15:52:48 -0500 In-Reply-To: <10983.1109882590@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 03 Mar 2005 21:43:10 +0100") Message-ID: <87y8d4ih9b.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: elric@imrryr.org cc: Todd Vierling cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 20:52:49 -0000 "Poul-Henning Kamp" writes: > In message , Todd Vierling writes: >>On Thu, 3 Mar 2005, Poul-Henning Kamp wrote: >> >>> At the time where I wrote GBDE, the best that was offered was CGD (and >>> similar) and users (not cryptographers!) didn't trust it >> >>Could you back up this claim, insofar that "users" did not trust cgd? I >>haven't seen any distrust of cgd -- in fact, I've seen quite a bit of >>welcome acceptace of cgd by both users *and* cryptographers. > > Some of the people I talked to were very unhappy about the same key > being used for all sectors on the disk. Now, was that in the first day after cgd was committed or the second? As I recall, you committed GBDE 48 hours after CGD was committed in NetBSD. I'd be curious to hear about how much you changed your design in that period in response to feedback on cgd. (Please correct me if I'm wrong about the time gap.) However: > Some of the people I talked to were very unhappy about the same key > being used for all sectors on the disk. Even a small weakness in > the cipher becomes a big hole because of the amount of data this > offers for analysis. I think we've already established that this fear, though understandable, is not a reasonable one under the circumstances. See several postings already made. You are better off just using AES with a longer key than the GBDE mechanism. Perry From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:01:15 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E030916A4CE for ; Thu, 3 Mar 2005 21:01:15 +0000 (GMT) Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA7DA43D46 for ; Thu, 3 Mar 2005 21:01:13 +0000 (GMT) (envelope-from tls@rek.tjls.com) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 23F26981DB; Thu, 3 Mar 2005 16:01:13 -0500 (EST) Received: (from tls@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j23L1DZ12992; Thu, 3 Mar 2005 16:01:13 -0500 (EST) Date: Thu, 3 Mar 2005 16:01:13 -0500 From: Thor Lancelot Simon To: tech-security@netbsd.org, hackers@freebsd.org, cryptography@metzdowd.com Message-ID: <20050303210113.GA19398@panix.com> References: <20050303200005.GA21499@panix.com> <10848.1109882513@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10848.1109882513@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tls@rek.tjls.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 21:01:16 -0000 On Thu, Mar 03, 2005 at 09:41:53PM +0100, Poul-Henning Kamp wrote: > In message <20050303200005.GA21499@panix.com>, Thor Lancelot Simon writes: > >On Thu, Mar 03, 2005 at 08:25:18PM +0100, Poul-Henning Kamp wrote: > > >To quote David Hume, "Never an ought from an is." > > I'm Danish by birth so english is only my second language, so I > apologize for mangling it. To be clear, the question is hardly one of linguistics. Perhaps if I call the reasoning mistake in question "the naturalistic fallacy" it will be more familiar to you than if I just use the common paraphrase from Hume? What I am trying to get across is that you argued from what some (poorly-specified) group of people _do_ believe (that "cgd", though it had existed for precisely two days when you checked GBDE into the FreeBSD source tree, so this seems unlikely in the extreme, was not secure) to what everyone _should_ believe (that in fact it is not secure). That's not a kind of reasoning I find very persuasive. > But in difference from everybody else (it seems) I also asked users > and administrators what they needed and wanted from a cryptographic > disk facility. Unfortunately, you seem to assume that "users and administrators" were, in general, capable of correctly turning their abstract goals about avoiding risk into concrete principles of cryptosystem design. I would submit, in fact, that this is precisely the expertise that you do not acknowledge exists. > And then I tried very hard to engage somebody with the right > union-card to do a review for me, and despite the fact that funding > were available under the DARPA contract nobody would bite. That surprises me, since I didn't see any such attempt at engagement in any of the usual places where such experts communicate (I will leave your "crypto-clergy" and "union-card" rhetoric aside). Did you solicit review on the cryptography mailing list? On sci.crypt? At conferences or in journals? You say that experts told you that they were concerned about the amount of data being encrypted with a single key in prior-art cryptosystems. Did it occur to you that, at the time, almost all such cryptosystems used algorithms with a 64 bit block size, and that that precise concern motivated the increase in block size in newer ciphers, including AES? Thor From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:26:39 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11C8C16A4CE for ; Thu, 3 Mar 2005 21:26:39 +0000 (GMT) Received: from mail.foolishgames.com (mail.foolishgames.com [216.55.178.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id B718F43D31 for ; Thu, 3 Mar 2005 21:26:38 +0000 (GMT) (envelope-from laffer1@mail.foolishgames.com) Received: from mail.foolishgames.com (localhost.foolishgames.com [127.0.0.1]) by mail.foolishgames.com (8.13.3/8.12.11) with ESMTP id j23LQL2n009136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2005 13:26:21 -0800 (PST) (envelope-from laffer1@mail.foolishgames.com) X-Authentication-Warning: mail.foolishgames.com: Host localhost.foolishgames.com [127.0.0.1] claimed to be mail.foolishgames.com Received: from localhost (laffer1@localhost)j23LQLL4009133; Thu, 3 Mar 2005 13:26:21 -0800 (PST) (envelope-from laffer1@mail.foolishgames.com) Date: Thu, 3 Mar 2005 13:26:21 -0800 (PST) From: laffer1 To: Julian Elischer In-Reply-To: <4227712F.5060906@elischer.org> Message-ID: <20050303132600.P8921@mail.foolishgames.com> References: <20050303041042.3198.qmail@web52709.mail.yahoo.com> <4227712F.5060906@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: freebsd-hackers@freebsd.org cc: Lucas Holt cc: kamalp@acm.org Subject: Re: sched_4BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 21:26:39 -0000 This looks like a linux thing to me... http://en.wikipedia.org/wiki/NPTL If its a spec, i'd like to know how. On Thu, 3 Mar 2005, Julian Elischer wrote: > > > Kamal R. Prasad wrote: > >> --- Julian Elischer wrote: >> >> >>> Kamal R. Prasad wrote: >>> >>> >>>> --- Lucas Holt wrote: >>>> >>>> >>>> >>>> >>>>> Wouldn't a multi threaded program potentially need >>>>> more cpu time than vi? >>>>> >>>> No. That is not a given. >>>> >>>> >>>> >>>> >>>>> Multithreaded apps are created to do a lot of >>>>> computation or because they have a lot of concurrent activity >>>>> >>> that >>> >>>>> might block right? >>>>> >>>>> >>>>> >>>> Threads are meant to take advantage of concurrency. >>>> >>>> Maybe the freebsd implementation should implement >>>> >>> NPTL >>> >>>> in entirety. >>>> >>>> >>>> >>> NPTL? >>> New Pthreads Library from Library? >>> >> Yes. >> >>> isn't that GPL'd? >>> >>> >> No -it is a standard. The linux implementation of nptl >> is gpl'ed. >> regards >> -kamal >> > > so how does that differ from what we have ... a native pthreads library? > >> >> >> ===== >> ------------------------------------------------------------ >> Kamal R. Prasad >> UNIX systems consultant kamalp@acm.org >> >> In theory, there is no difference between theory and practice. In practice, >> there is:-). >> ------------------------------------------------------------ >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:36:36 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA1D616A4CE for ; Thu, 3 Mar 2005 21:36:36 +0000 (GMT) Received: from rs6.luxsci.com (rs6.luxsci.com [65.61.136.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 364FC43D4C for ; Thu, 3 Mar 2005 21:36:36 +0000 (GMT) (envelope-from tv@duh.org) Received: from mail.duh.org (adsl-066-156-066-024.sip.asm.bellsouth.net [66.156.66.24]) (authenticated bits=0) by rs6.luxsci.com (8.12.11/8.12.11) with ESMTP id j23LaICk017676 verify=NOT); Thu, 3 Mar 2005 15:36:19 -0600 Received: from localhost (localhost [127.0.0.1]) by mail.duh.org (8.13.1/8.13.1) with ESMTP id j23LYOt1007611; Thu, 3 Mar 2005 16:34:25 -0500 (EST) Date: Thu, 3 Mar 2005 16:34:24 -0500 (EST) From: Todd Vierling To: Poul-Henning Kamp In-Reply-To: <11285.1109884555@critter.freebsd.dk> Message-ID: References: <11285.1109884555@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: elric@imrryr.org cc: "Perry E. Metzger" cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 21:36:36 -0000 On Thu, 3 Mar 2005, Poul-Henning Kamp wrote: > And if CGD is _so_ officially approved as you say, then I can not > for the life of me understand how it can use the same key to generate > the IV and perform the encryption. At the very least two different > keys should have been used at the "expense" of making the masterkey > 512 bits instead of 256. Technically, two different keys are used. The IV is generated from the block number (although it's pluggable for other IV generation methods, should one be desired; take a look!). This makes part of the "extended" 320-bit (256 + 64 bit off_t) key a known quantity *for a given ciphertext block*, but not the whole disk. This makes attacks a little more difficult than standard 256-bit symmetric AES, as the ciphertext is salted differently depending on the number of the test block. -- -- Todd Vierling From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:41:50 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E582A16A4CE for ; Thu, 3 Mar 2005 21:41:50 +0000 (GMT) Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id B569443D55 for ; Thu, 3 Mar 2005 21:41:50 +0000 (GMT) (envelope-from tls@rek.tjls.com) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id 0F6D1A704E; Thu, 3 Mar 2005 16:41:50 -0500 (EST) Received: (from tls@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j23Lfoj17272; Thu, 3 Mar 2005 16:41:50 -0500 (EST) Date: Thu, 3 Mar 2005 16:41:50 -0500 From: Thor Lancelot Simon To: Poul-Henning Kamp Message-ID: <20050303214150.GA28836@panix.com> References: <87y8d4ih9b.fsf@snark.piermont.com> <11285.1109884555@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11285.1109884555@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@netbsd.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tls@rek.tjls.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 21:41:51 -0000 On Thu, Mar 03, 2005 at 10:15:55PM +0100, Poul-Henning Kamp wrote: > > And if CGD is _so_ officially approved as you say, then I can not > for the life of me understand how it can use the same key to generate > the IV and perform the encryption. At the very least two different > keys should have been used at the "expense" of making the masterkey > 512 bits instead of 256. Why "should" two different keys have been used? It is possible that I misunderstand the underlying theory, but so far as I do understand it the only real requirement for IVs is that the Hamming distance between any two used with the same encryption key be large. Are you concerned about a key recovery attack? If so, can you give an outline of how it would work? -- Thor Lancelot Simon tls@rek.tjls.com "The inconsistency is startling, though admittedly, if consistency is to be abandoned or transcended, there is no problem." - Noam Chomsky From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 21:51:15 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0298716A4CE for ; Thu, 3 Mar 2005 21:51:15 +0000 (GMT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id B42FC43D1F for ; Thu, 3 Mar 2005 21:51:14 +0000 (GMT) (envelope-from tls@rek.tjls.com) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id DFDBF58B1C; Thu, 3 Mar 2005 16:51:13 -0500 (EST) Received: (from tls@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j23LpEk13692; Thu, 3 Mar 2005 16:51:14 -0500 (EST) Date: Thu, 3 Mar 2005 16:51:14 -0500 From: Thor Lancelot Simon To: tech-security@netbsd.org, hackers@freebsd.org, cryptography@metzdowd.com Message-ID: <20050303215114.GA18604@panix.com> References: <11487.1109886334@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11487.1109886334@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tls@rek.tjls.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 21:51:15 -0000 On Thu, Mar 03, 2005 at 10:45:34PM +0100, Poul-Henning Kamp wrote: > > Since the attacker know the block number the IV generation doesn't > add strength. > > In fact expose any weakness in the algorithm even more because it > offers two-way leverage on the algorithm. > > It also adds a very efficient hit-detector for a brute force attack. > > It would have been much better to use a different key to generate the IV. > > And did he salt the block number at all ? I don't think so... I think there's a misunderstanding here. Why do you think secrecy (unpredictability?) is an important property of an IV for a block cipher used in CBC mode? It's not an encryption key, it's an IV. It just has to have a large Hamming difference from any _other_ IV used with the same cipher key. -- Thor Lancelot Simon tls@rek.tjls.com "The inconsistency is startling, though admittedly, if consistency is to be abandoned or transcended, there is no problem." - Noam Chomsky From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 22:14:47 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80E3216A4CE for ; Thu, 3 Mar 2005 22:14:47 +0000 (GMT) Received: from mail3.panix.com (mail3.panix.com [166.84.1.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 149BF43D3F for ; Thu, 3 Mar 2005 22:14:47 +0000 (GMT) (envelope-from tls@rek.tjls.com) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 6A93C98214; Thu, 3 Mar 2005 17:14:46 -0500 (EST) Received: (from tls@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j23MEkA18679; Thu, 3 Mar 2005 17:14:46 -0500 (EST) Date: Thu, 3 Mar 2005 17:14:46 -0500 From: Thor Lancelot Simon To: ALeine Message-ID: <20050303221446.GA26823@netbsd.org> References: <200503030155.j231to9f088685@marlena.vvi.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503030155.j231to9f088685@marlena.vvi.at> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@netbsd.org cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tls@rek.tjls.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 22:14:47 -0000 On Wed, Mar 02, 2005 at 05:55:50PM -0800, ALeine wrote: > > He designed GBDE to always be harder than and never easier > to break than the cryptographic algorithms it relies on. Some very well-intentioned (and plenty smart) people at MIT designed the PCBC cipher mode to always be harder than and never easier to break than the cryptographic algorithms it relies on. Don Coppersmith designed the CBCM mode to always be harder than and never easier to break than the CBC mode of the 3DES algorithm. Unfortunately, all these well-intentioned and very intelligent people were wrong. The novel cryptographic modes they designed to always be harder to break were in fact sometimes -- in fact, in the case of PCBC, pretty much always -- easier to break than the boring, ordinary, pedestrian constructions they were meant to replace. And after all those well meaning and clever people got burned over the years, the consensus of the community of experts (as I percieve it, anyway) gradually became that novel cryptographic constructions should not be used in implementations until they had been extensively studied over a period of many years by experts. Those who do not know the mistakes of the past are doomed to repeat them. Thor From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 22:54:20 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FD2416A4CE for ; Thu, 3 Mar 2005 22:54:20 +0000 (GMT) Received: from hiroshima.ihack.net (209-6-103-199.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.103.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B69B43D41 for ; Thu, 3 Mar 2005 22:54:20 +0000 (GMT) (envelope-from abuse@spamalicious.com) Received: by hiroshima.ihack.net (Postfix, from userid 27753) id 02A4F2A65D5; Thu, 3 Mar 2005 22:53:50 +0000 (UTC) From: "Charles M. Hannum" Organization: By Noon Software, Inc. To: "ALeine" Date: Thu, 3 Mar 2005 22:53:49 +0000 User-Agent: KMail/1.7 References: <200503030243.j232hegV089625@marlena.vvi.at> In-Reply-To: <200503030243.j232hegV089625@marlena.vvi.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503032253.49819.abuse@spamalicious.com> X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: elric@imrryr.org cc: tls@rek.tjls.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 22:54:20 -0000 I'm not going to defend what Thor said, nor do I even think it's worth discussing as it largely amounts to an "appeal to privileged knowledge." However, this is some extremely sloppy thinking in your writing. To wit: On Thursday 03 March 2005 02:43, ALeine wrote: > At any time half of all the people are wrong about something, it's > only a matter of time when your time will come to be in the wrong > half or rather the right half to be wrong. That's a false dichotomy. There are many subjects on which the vast majority of people agree (such, as, I'll wager, the roundness of the Earth). > Just because there is a tendency for new cryptographic systems to > be broken does not mean this applies to GBDE, otherwise anything > new would be considered wrong and we might as well stop even trying > to innovate. Give GBDE a chance. It is being given a chance. "Giving it a chance" does not mean "stepping back and ignoring it until someone publishes an exploit." At least one weakness has been identified -- namely, using a weaker encryption mode for the key-key blocks can reduce the strength of the entire system. Or to put it metaphorically, "an algorithm is only as strong as its weakest link." > GBDE is not replacing anything because there was nothing like it to > replace in the first place. That's purely false. There are several other disk encryption systems around. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 23:18:21 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7465A16A4CE for ; Thu, 3 Mar 2005 23:18:21 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E1BB43D48 for ; Thu, 3 Mar 2005 23:18:20 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id E15A9D989A; Thu, 3 Mar 2005 18:18:18 -0500 (EST) To: "Poul-Henning Kamp" References: <11201.1109884126@critter.freebsd.dk> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 18:18:18 -0500 In-Reply-To: <11201.1109884126@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 03 Mar 2005 22:08:46 +0100") Message-ID: <87ll94iait.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 23:18:21 -0000 "Poul-Henning Kamp" writes: > I have a better idea: Why don't we get the cryptographers to > show up at computer science conferences ? They do. Perhaps you might want to listen to them. I remember a certain talk at BSDCon where someone criticized the design of the kernel RNG during the talk on it. He mentioned that the person giving the presentation had stated a few inaccurate things, such as claiming that there was a proof of security for Schneier's Yarrow algorithm and a few other howlers. As I recall, he was thoroughly criticized for mentioning these things. As I also recall, when said person brought the topic up with a certain person named PHK, he said "I don't want to hear about it." >>1) No one claims that you need to be a cryptographer to write >> something like GBDE. What is being claimed is that you should not >> have invented your own cryptographic modes, and that you might have >> wanted to ask some professionals about your approach. > > You have not actually studied GBDE yet, right ? I read your paper. > You don't actually know if I invented my own "cryptographic modes" > or not, do you ? You did. >>2) CGD *has* been looked at by a bunch of people, and was written to >> carefully use standard algorithms in a standard way. If you don't >> like using NetBSD code because NetBSD people have cooties, fine -- >> I don't care, write your own. However, you should at least pay the >> same attention to conservative use of cryptographic algorithms and >> having people review your work is a good idea, too. > > Even if I were alone in the world with the sentiment, I would never > call CGDs use of the same key for all sectors "conservative". You are entitled to your opinion. It is easy to break things in attempting to make them "more secure". I'm reminded of inner-CBC 3DES. It is not obvious why inner CBC would be a problem and outer CBC is not -- and yet inner CBC is a problem. Generally speaking, you are best off talking to someone who knows what they are doing and asking them for help first rather than inventing. The cryptography mailing list would be happy to discuss anything you need ideas on. So would sci.crypt and other fora. >>3) You've made some very bizarre claims about the security of your >> system. Some of these claims have already been shown on their face >> to be incorrect, such as your claimed work factor for breaking your >> new "improved" crypto modes. > > Sorry, they have only been disproved in a significantly larger universe > than the one my users inhabit. That doesn't count to me. Being stubborn on this isn't going to help your users. The math is pretty obvious here. Sure a brute force isn't practical -- but neither is a brute force of AES-256. The point is if you are going to claim a higher work factor than AES-256, you have to justify it, and if someone points out an obvious flaw in your logic and shows the work factor is lower than that for AES-256, the gentlemanly thing to do is say "you are correct, I was mistaken." >> Instead, he admitted his mistakes and wrote a version 2. > > Any qualified, factually correct critique of GBDE will be taken very > serious by me. I am very much looking forward to it. What Roland > has provided is not it. Roland's criticism is reasonable. Rather than getting angry, why don't you consider it? You don't have to adopt CGD -- build something else if you like. You could go off and try to discuss the algorithms you are using openly and see what people in the field have to say. Being openminded, by the way, includes not assuming in advance that having a different key for every block is a good idea or similar things. It means listening to the experts, and if you don't understand something, learning what they know so you have an informed basis for comment. -- Perry E. Metzger perry@piermont.com From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 23:22:28 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24E9D16A4CF for ; Thu, 3 Mar 2005 23:22:28 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6195E43D31 for ; Thu, 3 Mar 2005 23:22:27 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id B0CB3D9877; Thu, 3 Mar 2005 18:22:26 -0500 (EST) To: "Poul-Henning Kamp" References: <11285.1109884555@critter.freebsd.dk> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 18:22:26 -0500 In-Reply-To: <11285.1109884555@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 03 Mar 2005 22:15:55 +0100") Message-ID: <87hdjsiabx.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: elric@imrryr.org cc: Todd Vierling cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 23:22:28 -0000 "Poul-Henning Kamp" writes: >>I think we've already established that this fear, though >>understandable, is not a reasonable one under the circumstances. See >>several postings already made. You are better off just using AES with >>a longer key than the GBDE mechanism. > > I'm sorry, I reached the exact opposite conclusion. > > The work that was referred to earlier of defactorizing AES into a > very large number of equations would be exactly the kind of attack > I would worry about if I have 80 million sectors with the same key. That attack was shown to be bogus. It is highly unlikely that any such attack will ever show up, given the structure of AES. I would not be shocked if an attack on AES *did* show up, but it would likely not be of this sort, and it would likely make no difference in that context whether you encrypt the whole disk with one key or not even if such an attack appeared. > If that attack comes through, but relies on some partiular bit > combination being present on the plaintext or ciphertext of the > algoritm, I see no reason why I would want to improve the attackers > odds by a factor of 80 million. Again, it would do no such thing even if the bogus attack was real. > And if CGD is _so_ officially approved as you say, then I can not > for the life of me understand how it can use the same key to generate > the IV and perform the encryption. The IV doesn't matter. So long as the IV is different for each block you are fine. Any function that produces a decent shuffle would be acceptable. (Well, not quite *any*. For various reasons you may want the hamming distance between successive IVs to be large on average, but this achieves that.) -- Perry E. Metzger perry@piermont.com From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 23:40:33 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CEA216A4DB for ; Thu, 3 Mar 2005 23:40:33 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id D000A43D54 for ; Thu, 3 Mar 2005 23:40:31 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id 083A3D988C; Thu, 3 Mar 2005 18:40:31 -0500 (EST) To: "ALeine" References: <200503030155.j231to9f088685@marlena.vvi.at> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 18:40:30 -0500 In-Reply-To: <200503030155.j231to9f088685@marlena.vvi.at> (aleine@austrosearch.net's message of "Wed, 2 Mar 2005 17:55:50 -0800 (PST)") Message-ID: <87d5ugi9ht.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@NetBSD.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: elric@imrryr.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 23:40:35 -0000 "ALeine" writes: > perry@piermont.com wrote: >> > You are mistaking people who design cryptographic algorithms >> > and those who design cryptographic systems which integrate those >> > algorithms into functional systems. >> >> No, I am not. PHK invented new cryptographic modes for his work. >> The fact that he does not understand this is part of the problem. > > He designed GBDE to always be harder than and never easier > to break than the cryptographic algorithms it relies on. I have no doubt that was the intent. The question is, did he achieve it? >> > Would you care to explain what qualifies Roland as a more >> > competent cyrptographic system designer than PHK? >> >> Roland didn't try to do anything that wasn't already heavily >> understood in the literature. He invented no cryptographic modes. >> He used only algorithms that have been pre-vetted. He also asked a >> bunch of people who know better than he does to check his work. >> >> Thus, you don't have to trust Roland at all. He didn't invent any >> new way of using any of the algorithms. You have to trust only the >> designers of the block cipher you choose to use (I'd suggest AES) >> and the password algorithm you choose to use (though the PKCS stuff >> is very good already). In order to permit even greater defense >> against key cracking, he put in a very standard and straightforward >> mechanism to permit N factor authentication. > > MD5 was believed to be heavily understood in literature. It was > well established. Look at what happened to it. Yup. And Roland made the algorithm you use for encrypting your disk *pluggable*. That way, if AES is broken, you can replace it with the next big thing and move on with your life. Now, if AES is indeed broken, GBDE is in serious trouble, but CGD is not. Specific users of CGD have to change their drives, but the framework continues to work as advertised. > The fact that Roland did not invent any new ways of using algorithms > does not mean that CGD is more secure. It does, however, mean right from the get-go that the standard analysis you use for looking at this works right out of the box. You don't have to invent anything new to figure out if it works right. > In fact, IMHO it is less secure because it uses > the same key for the entire disk and because it reuses the same key > for IV generation and encryption. Do you know enough about cryptography to have an opinion, humble or not? For example, if I handed you something encrypted in a polyalphabetic cipher and asked you to tell me the key length, off the top of your hand would you know how to use the index of coincidence to do that? If I asked you to explain the difference between the security of inner and outer CBC 3DES, could you tell me? Could you explain what a characteristic is and how it is used in differential cryptanalysis? I'm not saying, by the way, that you should take my opinion or anyone else's as gospel. Argument from authority is worthless. At crypto conferences you will find differing opinions -- merely understanding crypto doesn't mean you are right. You should learn enough to form your own opinion. However, that implies that you must first learn enough that you have a basis on which to form it. If you don't know anything about medicine, do you have any good basis for telling your anesthesiologist to use a different drug in your surgery? So you say that to you, using one key for the entire disk is a bad idea. Very good. On what basis do you say this? Now it *is* true that you shouldn't use a key for too much data, and we have some ways these days of calculating how much data "too much" is. Do you understand how that calculation is performed? > You have to trust Roland to integrate the well known and understood > algorithms in a correct way, trusting the algorithms alone is not > enough. His code did indeed have some bugs to begin with. It was reviewed and they were fixed. > I am not designing cryptographic algorithms, what PHK did with > GBDE cannot be compared to inventing MD5, snap out of it, you > are starting to sound like a broken record. But the problem is that he crossed a line, so it *can* be compared to things like inventing MD5. He isn't merely using existing algorithms in well known ways. He is, in fact, using algorithms in modes that they having been used in before and making very very specific claims of work factors to break these new modes. >> WEP is even weaker than its design. That is because its designers >> did not know what they were doing. > > I assure you PHK knows very well what he is doing I've read his paper. I must respectfully disagree. > and I think you should not mention his name in the same breath along > with the names of the designers of WEP. The comparison seems to be perfectly apt -- people competent in one field assuming that another very complicated field is trivial, and extending their work into that other field, in which they are no longer competent. >> Inventing new cryptographic modes is dangerous. > > Living is dangerous, today you are here, tomorrow you might get > hit by a bus. But that does not mean you will stay inside your > house where you are safe (at least from buses) forever, does it? It does mean that if I invented a new mode for using a set of ciphers, I would first send them to a bunch of crypto geeks to vet, then I would write a detailed paper, and after a couple of years I might consider actually using it in the real world. Perry From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 23:45:19 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F291016A4CE for ; Thu, 3 Mar 2005 23:45:18 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CE7E43D2F for ; Thu, 3 Mar 2005 23:45:18 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id 894EED9877; Thu, 3 Mar 2005 18:45:17 -0500 (EST) To: Roland Dowdeswell References: <20050303225849.0E7143700F@arioch.imrryr.org> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 18:45:17 -0500 In-Reply-To: <20050303225849.0E7143700F@arioch.imrryr.org> (Roland Dowdeswell's message of "Thu, 03 Mar 2005 17:58:49 -0500") Message-ID: <878y54i99u.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: briggs@netbsd.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 23:45:19 -0000 Roland Dowdeswell writes: > I realise that PHK has been claiming that you might get false > positives, and that you somehow have to maintain a matrix of past > this and that. It is a lot simpler than this really. Of course, given that the unicity distance is much less than the text encrypted under one block. > For each key--key sector you are brute forcing, there are 2^128 > different keys to try. Now, the key--key sector protects 32 disk > sectors which contain 32 * 512 * 8 = 131072 bits. That means that > there are 2^131072 possibilities for what can be in those 32 sectors. > So, I think that we can see where I am going here? Yes. Small unicity distance, vanishingly low chance of false positive. > Now, granted not the entirety of the 32 sectors will be recognisable, > or necessarily even used---but a fair percentage will. Enough to > come up with numbers that may not be so astronomically small, are > still staggeringly small---a staggeringly small possibility that > such a false positive generating key actually exists at all. There is a good paper by Dave Wagner and Steve Bellovin on how to detect that you have the right plaintext, btw, even without needing things that can actually "understand" what they are looking at. > Disklabels for example have a checksum. The checksum might not be > terribly strong, but the chance that two different valid disklabels > could even be decrypted with different keys is small, I would > imagine. The checksum takes off 2^32 seemingly valid disklabels > and what about the rest of the fields? There's lots of redundant > information in there that could be cross referenced. You don't even need that. A very cheap statistical test will show that you have the right key with very good probability. However, given checksums, you pretty much have the plaintext nailed. -- Perry E. Metzger perry@piermont.com From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 23:55:29 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA15016A4CE for ; Thu, 3 Mar 2005 23:55:29 +0000 (GMT) Received: from bcd.geek.com.au (geek.com.au [203.17.37.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E40FB43D1F for ; Thu, 3 Mar 2005 23:55:28 +0000 (GMT) (envelope-from dan@geek.com.au) Received: by bcd.geek.com.au (Postfix, from userid 106) id DDD2949FA8; Fri, 4 Mar 2005 10:55:25 +1100 (EST) Date: Fri, 4 Mar 2005 10:55:25 +1100 From: Daniel Carosone To: Poul-Henning Kamp Message-ID: <20050303235525.GC8805@bcd.geek.com.au> Mail-Followup-To: Poul-Henning Kamp , "Perry E. Metzger" , ALeine , ticso@cicely.de, elric@imrryr.org, hackers@freebsd.org, tech-security@NetBSD.org References: <87ll94iait.fsf@snark.piermont.com> <12311.1109893353@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0lnxQi9hkpPO77W3" Content-Disposition: inline In-Reply-To: <12311.1109893353@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: elric@imrryr.org cc: "Perry E. Metzger" cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 23:55:30 -0000 --0lnxQi9hkpPO77W3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 04, 2005 at 12:42:33AM +0100, Poul-Henning Kamp wrote: > The fact that you just need to break one single sector in CGD before > you get the entire disk contents gives a disadvantage to CGD of > 2^26 before we even consider the nature of the attack. That is not > conservative when it could have been trivially avoided. The mechanisms gbde takes to avoid it are far from trivial. -- Dan. --0lnxQi9hkpPO77W3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (NetBSD) iD8DBQFCJ6PtEAVxvV4N66cRAu2aAJ90wGQvnTXbr8az6JUtat0FRxe3YACfXFPU AmOzn4bCdW/XSkeRhcf21as= =yaj5 -----END PGP SIGNATURE----- --0lnxQi9hkpPO77W3-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 00:10:17 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC3C616A4CE for ; Fri, 4 Mar 2005 00:10:17 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88A5543D39 for ; Fri, 4 Mar 2005 00:10:17 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id D4D7BD988C; Thu, 3 Mar 2005 19:10:16 -0500 (EST) To: "Poul-Henning Kamp" , tls@rek.tjls.com References: <11487.1109886334@critter.freebsd.dk> <20050303215114.GA18604@panix.com> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 19:10:16 -0500 In-Reply-To: <20050303215114.GA18604@panix.com> (Thor Lancelot Simon's message of "Thu, 3 Mar 2005 16:51:14 -0500") Message-ID: <87wtsogtjr.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@netbsd.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 00:10:18 -0000 Thor Lancelot Simon writes: > I think there's a misunderstanding here. Why do you think secrecy > (unpredictability?) is an important property of an IV for a block > cipher used in CBC mode? It's not an encryption key, it's an IV. Indeed. The IV can (subject to some constraints) be anything you like. Not having it public at very, very best denies one block from the ciphertext to the attacker -- ultimately not very useful in this application to prevent cracking given the low unicity distance. -- Perry E. Metzger perry@piermont.com From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 00:12:30 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56FF816A4CE for ; Fri, 4 Mar 2005 00:12:30 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id F11BB43D1F for ; Fri, 4 Mar 2005 00:12:29 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id 4B88DD989A; Thu, 3 Mar 2005 19:12:29 -0500 (EST) To: tls@rek.tjls.com References: <200503030155.j231to9f088685@marlena.vvi.at> <20050303221446.GA26823@netbsd.org> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 19:12:29 -0500 In-Reply-To: <20050303221446.GA26823@netbsd.org> (Thor Lancelot Simon's message of "Thu, 3 Mar 2005 17:14:46 -0500") Message-ID: <87psyggtg2.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: tech-security@netbsd.org cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 00:12:30 -0000 Thor Lancelot Simon writes: > On Wed, Mar 02, 2005 at 05:55:50PM -0800, ALeine wrote: >> >> He designed GBDE to always be harder than and never easier >> to break than the cryptographic algorithms it relies on. > > Some very well-intentioned (and plenty smart) people at MIT > designed the PCBC cipher mode to always be harder than and > never easier to break than the cryptographic algorithms it > relies on. Don Coppersmith designed the CBCM mode to always > be harder than and never easier to break than the CBC mode > of the 3DES algorithm. FYI, Don Coppersmith has forgotten more crypto than most people in the world in the field have ever known. Among other things to his credit was this little algorithm called DES that he helped bring to life. He too makes mistakes. Perry From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 00:18:11 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5AAD16A4CE for ; Fri, 4 Mar 2005 00:18:11 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81E4743D4C for ; Fri, 4 Mar 2005 00:18:11 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id DD6C2D988C; Thu, 3 Mar 2005 19:18:10 -0500 (EST) To: "Poul-Henning Kamp" References: <9418.1109872131@critter.freebsd.dk> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 19:18:10 -0500 In-Reply-To: <9418.1109872131@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 03 Mar 2005 18:48:51 +0100") Message-ID: <87ll94gt6l.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@NetBSD.org cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 00:18:12 -0000 "Poul-Henning Kamp" writes: > If the component (well respected etc etc) algorithms I have used > in GBDE contains flaws so that they become individually less > intrinsicly safe because their input is the output of another such > algorithm, then the crypto-world has problems they need to work on. The crypto world is a world of very brittle materials developed by humans with finite capacities. We do our best, but we make mistakes. Combining algorithms in such a way that the result is unexpectedly weak has been seen on several occasions. The reason cryptographers are very cautious is because they have been burned repeatedly. > Despite my best efforts to get people interested in reviewing GBDE, > it doesn't seem to have succeeded in getting any attention until > now, and I am very much looking forward to the competent review > and input this will generate. If you wish to hear my suggestions on how to get review, feel free to contact me offline. Perry From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 00:45:56 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F284016A4CE for ; Fri, 4 Mar 2005 00:45:55 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5C3C43D1D for ; Fri, 4 Mar 2005 00:45:54 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id 4E177D988C; Thu, 3 Mar 2005 19:45:53 -0500 (EST) To: "Poul-Henning Kamp" References: <12311.1109893353@critter.freebsd.dk> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 19:45:53 -0500 In-Reply-To: <12311.1109893353@critter.freebsd.dk> (Poul-Henning Kamp's message of "Fri, 04 Mar 2005 00:42:33 +0100") Message-ID: <87bra0grwe.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 00:45:56 -0000 "Poul-Henning Kamp" writes: >>> You don't actually know if I invented my own "cryptographic modes" >>> or not, do you ? >> >>You did. > > I did ? Cool, I should patent them! :-) I would encourage it. It will keep others from wanting to use them. >>> Sorry, they have only been disproved in a significantly larger universe >>> than the one my users inhabit. That doesn't count to me. >> >>Being stubborn on this isn't going to help your users. The math is >>pretty obvious here. Sure a brute force isn't practical -- but neither >>is a brute force of AES-256. > > No, not right now. And if a break was found, it isn't clear that all your you would actually protect against it very effectively. The simpler and safer solution is to have the ability to replace your algorithm easily. > But do we know that a brute force attack is unfeasible on AES-256 > tens years from now ? No, we don't. What we do know is that it seems pretty unlikely that the general *mechanism* of CGD is flawed given the security of its components. Since the components may be flawed, the system permits easy selection of other algorithms. My strong suggestion for you is that you adopt a similar approach -- build a good framework that, given good algorithms, will provide security, and make it easy for users to change over if an algorithm falls. When we were designing IPSec, there was a very interesting proposal called SKIP, which had as its main flaw that we could never really alter algorithms if we picked it. That alone damned it. As it turns out, our decision was a good one. > And are we sure that the reuse of key material > which happens in CGD will not materially aid any attacks that may > be developed in the next decade ? I will never say never, but the "reuse" is for IVs. Now, if you examine what it means for something to be an IV in a CBC context, you will see that you are, in a very real sense, not using the key any differently than it is used elsewhere. That is to say, you are encrypting a piece of data under the key and then using the output as a value to xor with another piece of data. That is pretty much the definition of CBC mode. Essentially what you have is prepended the block number to each block and then run CBC over the whole block using a zero IV. That of course means that the first block is now theoretically vulnerable in reuse, but since it isn't secret and is never reused and isn't even placed on the disk, we don't really care. It is possible that this usage is subtly bad, but it has been studied in many other contexts, such as in cryptographic network protocols, and it is likely reasonable. Again, I will never say never, just as I would never claim AES is safe forever. > The fact that you just need to break one single sector in CGD before > you get the entire disk contents gives a disadvantage to CGD of > 2^26 before we even consider the nature of the attack. I disagree with your analysis, but lets consider what you are saying. You are claiming, in essence, that AES 256 isn't good enough for you, and that you need a better cipher. If it isn't good enough for you, I suggest that rather than bandaid AES 256, what you should do is actually find a better cipher to use. > The goal for GBDE is to give credible denial of access for up to > 25 years, Well, so is stock AES 256. I don't see why I should assume your construction is any better. What do you know that the NIST/NSA review of AES did not know? -- Perry E. Metzger perry@piermont.com From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 00:49:04 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0CFB16A4CE for ; Fri, 4 Mar 2005 00:49:04 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1847743D46 for ; Fri, 4 Mar 2005 00:49:04 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id 6A443D988C; Thu, 3 Mar 2005 19:49:03 -0500 (EST) To: "Poul-Henning Kamp" References: <12467.1109893619@critter.freebsd.dk> From: "Perry E. Metzger" Date: Thu, 03 Mar 2005 19:49:03 -0500 In-Reply-To: <12467.1109893619@critter.freebsd.dk> (Poul-Henning Kamp's message of "Fri, 04 Mar 2005 00:46:59 +0100") Message-ID: <877jkogrr4.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 00:49:04 -0000 "Poul-Henning Kamp" writes: > In message <87d5ugi9ht.fsf@snark.piermont.com>, "Perry E. Metzger" writes: >>> MD5 was believed to be heavily understood in literature. It was >>> well established. Look at what happened to it. >> >>Yup. And Roland made the algorithm you use for encrypting your disk >>*pluggable*. That way, if AES is broken, you can replace it with the >>next big thing and move on with your life. >> >>Now, if AES is indeed broken, GBDE is in serious trouble, but CGD is >>not. Specific users of CGD have to change their drives, but the >>framework continues to work as advertised. > > Gee Perry, now you're spreading FUD. > > You know perfectly well that it would take less than one hour to > substitute another algorithm in the GBDE source code. But you aren't built for that from the get-go. I would strongly suggest you change that -- make your cipher a user configurable component. I also very strongly suggest that the biggest real threat you face isn't someone cracking AES but key management issues. CGD is in some sense largely a framework for letting you do all sorts of neat things with key management in a disk encryption context. You may want to add similar features -- the most practical attack against your system as it stands is a dictionary attack. -- Perry E. Metzger perry@piermont.com From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 01:34:09 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B726C16A4CE for ; Fri, 4 Mar 2005 01:34:09 +0000 (GMT) Received: from machshav.com (machshav.com [147.28.0.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4583743D62 for ; Fri, 4 Mar 2005 01:34:09 +0000 (GMT) (envelope-from smb@cs.columbia.edu) Received: by machshav.com (Postfix, from userid 512) id A34FFFB28F; Thu, 3 Mar 2005 20:34:08 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 94CB1FB285; Thu, 3 Mar 2005 20:34:07 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 330F83BFE3B; Thu, 3 Mar 2005 20:34:05 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 03 Mar 2005 23:19:11 +0100." <11649.1109888351@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Mar 2005 20:34:05 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050304013405.330F83BFE3B@berkshire.machshav.com> X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@NetBSD.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com cc: tls@rek.tjls.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 01:34:09 -0000 In message <11649.1109888351@critter.freebsd.dk>, "Poul-Henning Kamp" writes: >I have studied the AES papers and in particular the attacks and >critisisms of it very carefully, and they have proven a whole lot >of things to be impossible, but they have not proven that there >are not more that needs to be proven impossible. > >When DES was designed, nobody knew that differential attacks existed. No, no one in the open sector new. DES was specifically designed to resist differential cryptanalysis. The best source for information on how DES was designed is Don Coppersmith's paper "The Data Encryption Standard (DES) and its strength against attacks", IBM Journal of Researchand Development, Vol. 38, n. 3, pp. 243-250, May 1994. It's worth noting that in the ~30 years since DES was designed, exactly *one* attack significantly better than brute force was found: linear cryptanalysis. Coppersmith's paper shows how that could have been prevented, too. A few years ago, Biham came up with a 2^79 attack against a slightly-weakened version of Skipjack, an NSA cipher. I mentioned that to a friend who has -- let's say "connections". He smiled and said "2^79 complexity against an 80-bit cipher? I don't call that an attack, I call that good engineering". Since then, I've heard other statements from well-connected people that boil down to this: NSA has a deep understanding of how strong a cipher is. In that vein, I'll note that 256-bit AES is approved for Top Secret traffic. > >Shortly after AES was gold-plated the earlier mentioned attack >method where it is decomposed into a massive number of equations >was presented. > As noted, that attack is discredited. --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 02:14:03 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3879C16A4CE for ; Fri, 4 Mar 2005 02:14:03 +0000 (GMT) Received: from machshav.com (machshav.com [147.28.0.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B927543D41 for ; Fri, 4 Mar 2005 02:14:02 +0000 (GMT) (envelope-from smb@cs.columbia.edu) Received: by machshav.com (Postfix, from userid 512) id 4B863FB28F; Thu, 3 Mar 2005 21:14:02 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E2C24FB285; Thu, 3 Mar 2005 21:14:00 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 206813BFE3B; Thu, 3 Mar 2005 21:13:58 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: netbsd From: "Steven M. Bellovin" To: tls@rek.tjls.com In-Reply-To: Your message of "Thu, 03 Mar 2005 16:41:50 EST." <20050303214150.GA28836@panix.com> Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 03 Mar 2005 21:13:58 -0500 Sender: smb@cs.columbia.edu Message-Id: <20050304021358.206813BFE3B@berkshire.machshav.com> X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: tech-security@NetBSD.org cc: Poul-Henning Kamp cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 02:14:03 -0000 In message <20050303214150.GA28836@panix.com>, Thor Lancelot Simon writes: >On Thu, Mar 03, 2005 at 10:15:55PM +0100, Poul-Henning Kamp wrote: >> >> And if CGD is _so_ officially approved as you say, then I can not >> for the life of me understand how it can use the same key to generate >> the IV and perform the encryption. At the very least two different >> keys should have been used at the "expense" of making the masterkey >> 512 bits instead of 256. > >Why "should" two different keys have been used? It is possible that I >misunderstand the underlying theory, but so far as I do understand it >the only real requirement for IVs is that the Hamming distance between >any two used with the same encryption key be large. On this point, I tend to agree with phk -- it's generally a bad idea to use the same key in two different contexts, because there can be interactions. I'd be happier if a different mechanism were used to generate the IV, such as HMAC of the key and block number, or encryption of the block number with a hash of the key, or by stretching the input key to a longer output key per PKCS#5 and using the two halves for different purposes. While I don't see a real attack to worry about here, in some situations there's a possibility of a chosen plaintext attack: I write 0s to block #k; the ciphertext of the first 16 bytes of that block will be encryption of k under the same key. I hasten to add that that's *not* even close to a real attack for lots of reasons, not the least of which is that AES was designed to resist chosen plaintext attacks in far more devastating circumstances. The other change I think is important for cgd is to provide a key-changing mechanism. That is, I'd like to have a key from /dev/random or /dev/urandom used for the actual encryption, but have that key encrypted via the PKCS#5-converted password. That's a small change to cdgconfig; another change would be needed to provide the password-changing code. Again, phk is right about this point, though his paper misstates the reason: it's not that "all security policies we have ever seen, contain a rule which says 'passwords must be changed every N {days,weeks,months}'. This is sound thinking, and GBDE should support it." -- such policies tend to be rather stupid, in fact. Rather, it's addressing the crucial weakness of any of these schemes: users pick bad passwords. A more interesting, and to me open, question is whether or not one needs to worry about encrypting too much data with one key. AES in CBC mode does have a limit of 2^64 blocks, or 2^68 bytes. If we assume you can buy a 1 TB (i.e., 2^40 byte) disk today, and we assume that disk capacity is doubling every year, we'll hit that limit in 28 years. Of course, assuming that doubling will continue for 28 years is a stretch, but one can always use RAID to build bigger file systems. The real question, though, is whether or not there's a limit significantly smaller than 2^64 blocks. Note, too, that such a development doesn't affect the security of data written to today's smaller disks. But this discussion has degenerated into name-calling. I suggest that a pointer to the gbde paper be posted to the cryptography mailing list. Yes, Perry is the moderator; no, that's not a problem even for those he disagrees with. He does a clean, fair job. Besides, that list is one place where members of the Cryptographers' Guild do interact with "real programmers" -- the list has quite a collection of each, plus some people who live in both worlds. That latter category includes me (I don't design cipher algorithms; I do design -- and attack -- cryptographic protocols), David Wagner, Hugo Krawczyk (one of the inventors of HMAC), and many others. You can subscribe to that list by sending to cryptography@metzdowd.com. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 14:02:59 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDCCC16A4CE for ; Fri, 4 Mar 2005 14:02:59 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id C813C43D1D for ; Fri, 4 Mar 2005 14:02:56 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id A6253D988C; Fri, 4 Mar 2005 09:02:55 -0500 (EST) To: "Poul-Henning Kamp" References: <14890.1109921971@critter.freebsd.dk> From: "Perry E. Metzger" Date: Fri, 04 Mar 2005 09:02:55 -0500 In-Reply-To: <14890.1109921971@critter.freebsd.dk> (Poul-Henning Kamp's message of "Fri, 04 Mar 2005 08:39:31 +0100") Message-ID: <877jknik4w.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 14:02:59 -0000 "Poul-Henning Kamp" writes: > In message <87bra0grwe.fsf@snark.piermont.com>, "Perry E. Metzger" writes: >>My strong suggestion for you is that you adopt a similar approach -- >>build a good framework that, given good algorithms, will provide >>security, and make it easy for users to change over if an algorithm >>falls. > > If you actually look at GBDE, you will see that any and all of the > algorithms can be changed. They are used only in their most basic > capability. This was part of the design from the start: not to > rely on any single-source algorithm. I understand that, but the point is to make it user friendly. CGD lets you pick a number of crypto systems right now in its configuration. You can pick multiple key lengths, methods of deriving the key, etc. I've read through things like the GBDE command man page, how-tos, etc., and I found nothing that allows you to do stuff like change cipher with GBDE. I also don't find support for things like multi-factor authentication. All that could be added, of course, and I encourage you to do it -- but my point is that it isn't there now and you should look at doing it. If I can pick any one of several ciphers and key lengths already or specify things like multi-factor authentication, my apologies. In any case, please understand that my goal is not to tell your users that FreeBSD is garbage or anything like that. My goal is to get you to improve what you have done. If you want to tell me I'm an idiot or what have you, feel free, but I don't think that will serve your users particularly well. >>Well, so is stock AES 256. I don't see why I should assume your >>construction is any better. What do you know that the NIST/NSA review >>of AES did not know? > > That neither the authors of Rinjdael, its reviewers, nor NIST are > willing to offer a 25 year warranty on it. No one rational will give a warranty on *any* encryption system for *any* length of time. The best I can say, however, is that the US government has approved the use of AES with 256 bit keys for very highly secure communications, and they have a very demanding user community. Assuming that you can brute force a bit or two more key per year, and assuming that better cryptanalytic techniques doubled that somehow, you would still have many many years before 256 bit AES became a real issue. Anyone rational attacking you will look at other flaws in your system first. -- Perry E. Metzger perry@piermont.com From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 14:51:43 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 328D516A4CF for ; Fri, 4 Mar 2005 14:51:43 +0000 (GMT) Received: from mail.tnnet.fi (mail.tnnet.fi [217.112.240.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF99D43D5A for ; Fri, 4 Mar 2005 14:51:42 +0000 (GMT) (envelope-from jariruusu@users.sourceforge.net) Received: from localhost (localhost [127.0.0.1]) by mail.tnnet.fi (Postfix) with ESMTP id F1E572EDF02; Fri, 4 Mar 2005 16:51:36 +0200 (EET) Received: from mail.tnnet.fi ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25606-07; Fri, 4 Mar 2005 16:51:30 +0200 (EET) Received: from armas (a64.adsl.tnnet.fi [217.112.242.64]) by mail.tnnet.fi (Postfix) with ESMTP id BB6002EDEF5; Fri, 4 Mar 2005 16:51:28 +0200 (EET) Received: from localhost ([127.0.0.1] helo=users.sourceforge.net) by armas with esmtp (Exim) id 1D7E9I-0000HU-00; Fri, 04 Mar 2005 16:51:28 +0200 Sender: root@mail.tnnet.fi Message-ID: <422875F0.49877364@users.sourceforge.net> Date: Fri, 04 Mar 2005 16:51:28 +0200 From: Jari Ruusu X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.22aa1r8 i686) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp References: <11285.1109884555@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mail.tnnet.fi X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: ALeine cc: elric@imrryr.org cc: Todd Vierling cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: "Perry E. Metzger" cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 14:51:43 -0000 Poul-Henning Kamp wrote: > I am being a bit unfair here because I am lumping CGD in with the > equally defficient code in Linux (Loop-AES etc). It was mostly the > linux code I talked to people about, but CGD makes the same exact > mistake. Loop-AES for Linux has improved a lot since v1.X versions. Please take a look at recent v3.X versions which include security features that even your GBDE doesn't have. > It appears to me, that the people who designed CGD and the Linux > Loop-AES and similar focused very hard on the box that said "AES" > without giving much consideration to where the arrows between the > boxes went. Early versions of loop-AES were FUBARed, true. But why do you insist on ranting about fuckups that were fixed long time ago? -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 16:17:26 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D930116A4CE for ; Fri, 4 Mar 2005 16:17:26 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A76843D54 for ; Fri, 4 Mar 2005 16:17:26 +0000 (GMT) (envelope-from ant@emict.com) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id B6B573551D for ; Fri, 4 Mar 2005 18:17:23 +0200 (EET) Message-ID: <000401c520d5$a6b6ae00$090210ac@BORJA> From: "Andriy Tkachuk" To: Date: Fri, 4 Mar 2005 21:45:56 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 Subject: sched_ule, runqueues, priority, and O(1) sheduling question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 16:17:27 -0000 Hi folks. I wander how O(1) sheduling works in ULE. In ule.pdf Jeff wrote: Threads are picked from the current queue in priority order until the current queue is empty. As far as I understand the algorithm is O(n) where n - number of READY TO RUN processes, not all processes isn't it? thanks, Andriy. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 16:21:52 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AAD616A4CE; Fri, 4 Mar 2005 16:21:52 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA99043D31; Fri, 4 Mar 2005 16:21:51 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])j24GLnt2090689; Fri, 4 Mar 2005 11:21:49 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.3/8.12.1/Submit) id j24GLn9I090688; Fri, 4 Mar 2005 11:21:49 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Fri, 4 Mar 2005 11:21:49 -0500 From: Bosko Milekic To: Aziz KEZZOU Message-ID: <20050304162149.GA90499@technokratis.com> References: <37e13166050304080715525d7e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37e13166050304080715525d7e@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 04 Mar 2005 16:36:07 +0000 cc: freebsd-net@freebsd.org cc: hackers@freebsd.org Subject: Re: generic network protocols parser ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 16:21:52 -0000 On Fri, Mar 04, 2005 at 11:07:34AM -0500, Aziz KEZZOU wrote: > Hi all, > I am wondering if any one knows about a generic parser which takes a > packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates > some data structre representing the packet ? > > I've been searching for a while and found that ethereal and tcpdump > for example use specific data structres and functions to dissect each > protocol packets. Is this the only approach possible ? > > My supervisor suggested using a TLV (Type/Length/Value) approach > instead. Any opinions about that? > > If no such a parser exists is there any practical reason why ? > > Thanks, > Aziz You can only go so far with generic parsing. Eventually you will want some protocol specific value to be extracted and your parser will have to know about what the packet looks like. What are you trying to do, exactly? -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 16:49:32 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 309F616A4CE for ; Fri, 4 Mar 2005 16:49:32 +0000 (GMT) Received: from mail.eecs.harvard.edu (bowser.eecs.harvard.edu [140.247.60.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id D174143D41 for ; Fri, 4 Mar 2005 16:49:31 +0000 (GMT) (envelope-from ellard@eecs.harvard.edu) Received: from localhost (localhost.eecs.harvard.edu [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id ED5E054C916 for ; Fri, 4 Mar 2005 11:49:30 -0500 (EST) Received: from mail.eecs.harvard.edu ([127.0.0.1]) by localhost (bowser.eecs.harvard.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40853-01 for ; Fri, 4 Mar 2005 11:49:30 -0500 (EST) Received: by mail.eecs.harvard.edu (Postfix, from userid 465) id BD59D54C8F0; Fri, 4 Mar 2005 11:49:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id BA97054C5C6 for ; Fri, 4 Mar 2005 11:49:30 -0500 (EST) Date: Fri, 4 Mar 2005 11:49:30 -0500 (EST) From: Daniel Ellard To: freebsd-hackers@freebsd.org Message-ID: <20050304114647.W40244@bowser.eecs.harvard.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at eecs.harvard.edu Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 16:49:32 -0000 Any chance some part of this discussion can be taken off-line? Or to freebsd-sec? -Dan From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 16:49:47 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E04F16A4CE for ; Fri, 4 Mar 2005 16:49:47 +0000 (GMT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF3D943D55 for ; Fri, 4 Mar 2005 16:49:46 +0000 (GMT) (envelope-from sjt@cisco.com) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2005 11:49:47 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-kan-a.cisco.com (IDENT:mirapoint@mira-kan-a.cisco.com [161.44.201.17])j24GnhjI019436; Fri, 4 Mar 2005 11:49:43 -0500 (EST) Received: from dhcp-kta1-161-44-193-137.cisco.com (dhcp-kta1-161-44-193-137.cisco.com [161.44.193.137]) by mira-kan-a.cisco.com (MOS 3.4.6-GR) with ESMTP id ABL82520; Fri, 4 Mar 2005 08:49:42 -0800 (PST) From: Steve Tremblett To: freebsd-hackers@freebsd.org In-Reply-To: <87y8d4ih9b.fsf@snark.piermont.com> References: <10983.1109882590@critter.freebsd.dk> <87y8d4ih9b.fsf@snark.piermont.com> Content-Type: text/plain Date: Fri, 04 Mar 2005 11:49:42 -0500 Message-Id: <1109954982.627.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: Poul-Henning Kamp cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 16:49:47 -0000 would people mind not bcc'ing freebsd-hackers? I've been deleting this thread from my inbox for a couple of days because it's not filtered into my bsd folders :) On Thu, 2005-03-03 at 15:52 -0500, Perry E. Metzger wrote: > "Poul-Henning Kamp" writes: > > In message , Todd Vierling writes: > >>On Thu, 3 Mar 2005, Poul-Henning Kamp wrote: > >> > >>> At the time where I wrote GBDE, the best that was offered was CGD (and > >>> similar) and users (not cryptographers!) didn't trust it > >> > >>Could you back up this claim, insofar that "users" did not trust cgd? I > >>haven't seen any distrust of cgd -- in fact, I've seen quite a bit of > >>welcome acceptace of cgd by both users *and* cryptographers. > > > > Some of the people I talked to were very unhappy about the same key > > being used for all sectors on the disk. > > Now, was that in the first day after cgd was committed or the second? > As I recall, you committed GBDE 48 hours after CGD was committed in > NetBSD. I'd be curious to hear about how much you changed your design > in that period in response to feedback on cgd. (Please correct me if > I'm wrong about the time gap.) > > However: > > > Some of the people I talked to were very unhappy about the same key > > being used for all sectors on the disk. Even a small weakness in > > the cipher becomes a big hole because of the amount of data this > > offers for analysis. > > I think we've already established that this fear, though > understandable, is not a reasonable one under the circumstances. See > several postings already made. You are better off just using AES with > a longer key than the GBDE mechanism. > > Perry > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 17:00:38 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5976716A4CE; Fri, 4 Mar 2005 17:00:38 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B949443D49; Fri, 4 Mar 2005 17:00:37 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j24H2OCQ011580; Fri, 4 Mar 2005 10:02:24 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <422893A5.1090907@samsco.org> Date: Fri, 04 Mar 2005 09:58:13 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: monthly@freebsd.org Subject: FreeBSD status report.... status! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 17:00:38 -0000 All, Thanks to the help of Max Laier and Tom Rhodes, the FreeBSD status reports are alive and will be much more regular. However, in the interest of not over-burdening the developers who submit reports, we've decided to switch from a bi-monthly cycle to a quarterly cycle. So, we will not be soliciting submissions this month, but we will solicit them next month. That will also coincide nicely with the release of FreeBSD 5.4, so we'll be looking for a lot of reports that highlight 5.x improvements. Thanks, Scott From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 17:47:14 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A17316A4CE; Fri, 4 Mar 2005 17:47:14 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D52543D53; Fri, 4 Mar 2005 17:47:13 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) j24HlBV1093337; Fri, 4 Mar 2005 09:47:12 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (nat-202.43.223.241.hongkong.corp.yahoo.com [202.43.223.241]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id j24Hl6DY051049; Fri, 4 Mar 2005 09:47:07 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Sat, 05 Mar 2005 01:47:05 +0800 Message-ID: From: gnn@freebsd.org To: Aziz KEZZOU In-Reply-To: <37e13166050304080715525d7e@mail.gmail.com> References: <37e13166050304080715525d7e@mail.gmail.com> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.7.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: hackers@freebsd.org Subject: Re: generic network protocols parser ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 17:47:14 -0000 At Fri, 4 Mar 2005 11:07:34 -0500, Aziz KEZZOU wrote: > > Hi all, > I am wondering if any one knows about a generic parser which takes a > packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates > some data structre representing the packet ? > > I've been searching for a while and found that ethereal and tcpdump > for example use specific data structres and functions to dissect each > protocol packets. Is this the only approach possible ? > > My supervisor suggested using a TLV (Type/Length/Value) approach > instead. Any opinions about that? > > If no such a parser exists is there any practical reason why ? > You might want to look at libnet and libnet-ng. Start here: http://www.packetfactory.net/libnet/ Perhaps not exactly what you want but the beginnings are there. Later, George From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 18:38:01 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5979F16A4CE for ; Fri, 4 Mar 2005 18:38:01 +0000 (GMT) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 466B443D1D for ; Fri, 4 Mar 2005 18:38:00 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j24IbmYL029539 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 5 Mar 2005 05:37:50 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j24Ibm7l008040; Sat, 5 Mar 2005 05:37:48 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j24Ibl5t008039; Sat, 5 Mar 2005 05:37:47 +1100 (EST) (envelope-from pjeremy) Date: Sat, 5 Mar 2005 05:37:47 +1100 From: Peter Jeremy To: ALeine Message-ID: <20050304183747.GS57256@cirb503493.alcatel.com.au> References: <200503022115.j22LFnWk083926@marlena.vvi.at> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200503022115.j22LFnWk083926@marlena.vvi.at> User-Agent: Mutt/1.4.2i cc: phk@phk.freebsd.dk cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 18:38:01 -0000 [CC list pruned] On Wed, 2005-Mar-02 13:15:49 -0800, ALeine wrote: >If only hardware manufacturers were to equip hard drives with >a mechanism to ensure atomic writes. A capacitor large enough >to hold enough energy to flush the cache upon detecting the >power supply was cut would be sufficient. I'm not sure thus is readily practical at the drive level. Based on some back-of-envelope calculations using figures in a Seagate Barracuda manual (which I happened to have handy): - Random seek is 9.5 msec. - Rotational period is 8.3msec - Power consumption at 50% R/W, 50% seek is 0.82A @ 12V + 0.68A @ 5V A single random seek + track write will take 17.8 msec. This translates to an electrical charge of 0.015C @ 12V and 0.012C @ 5V. Assuming the drive is designed to allow the supply rails to droop 20% whilst functioning correctly during this shutdown phase (which is a significantly bigger drop than the standard specifications), a single random seek + track write would require the drive to include a 6000礔 capacitor on the 12V rail and a 12000礔 capacitor on the 5V rail. As a first order approximation all Unix disk operations are writes (reads can be satisfied from the buffer cache). Given the size of current generation drive caches, it's more likely that there are around 50 writes cached - which requires capacitors 50 times as large - which would make them significantly larger than the drive itself. > They could even use >a battery the status of which could be monitored via S.M.A.R.T., >I don't see how implementing something like that could possibly >make the cost noticably higher. Batteries (and standard supercaps) are generally designed to release their energy over an extended period - several minutes is the lower realistic limit. It would make sense to build a battery backup system which maintained power for (say) 5 minutes. It's not realistic to build a battery backup system that can release all it's available energy in 1 second. If you're going to the effort of building a battery backup system, you might as well backup the entire computer. These are available off the shelf and have the added advantage of allowing users and the system to clean up before the power goes away. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 19:06:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 30DC416A4CE; Fri, 4 Mar 2005 19:06:10 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j24J69IU076428; Fri, 4 Mar 2005 14:06:09 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j24J67X8076427; Fri, 4 Mar 2005 14:06:07 -0500 (EST) (envelope-from green) Date: Fri, 4 Mar 2005 14:06:06 -0500 From: Brian Fundakowski Feldman To: Peter Jeremy Message-ID: <20050304190606.GF6011@green.homeunix.org> References: <200503022115.j22LFnWk083926@marlena.vvi.at> <20050304183747.GS57256@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050304183747.GS57256@cirb503493.alcatel.com.au> User-Agent: Mutt/1.5.6i cc: ALeine cc: phk@phk.freebsd.dk cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 19:06:10 -0000 On Sat, Mar 05, 2005 at 05:37:47AM +1100, Peter Jeremy wrote: > [CC list pruned] > > On Wed, 2005-Mar-02 13:15:49 -0800, ALeine wrote: > >If only hardware manufacturers were to equip hard drives with > >a mechanism to ensure atomic writes. A capacitor large enough > >to hold enough energy to flush the cache upon detecting the > >power supply was cut would be sufficient. > > I'm not sure thus is readily practical at the drive level. Based > on some back-of-envelope calculations using figures in a Seagate > Barracuda manual (which I happened to have handy): > - Random seek is 9.5 msec. > - Rotational period is 8.3msec > - Power consumption at 50% R/W, 50% seek is 0.82A @ 12V + 0.68A @ 5V > > A single random seek + track write will take 17.8 msec. This translates > to an electrical charge of 0.015C @ 12V and 0.012C @ 5V. > > Assuming the drive is designed to allow the supply rails to droop 20% > whilst functioning correctly during this shutdown phase (which is a > significantly bigger drop than the standard specifications), a single > random seek + track write would require the drive to include a 6000礔 > capacitor on the 12V rail and a 12000礔 capacitor on the 5V rail. > > As a first order approximation all Unix disk operations are writes > (reads can be satisfied from the buffer cache). Given the size of > current generation drive caches, it's more likely that there are > around 50 writes cached - which requires capacitors 50 times as large > - which would make them significantly larger than the drive itself. This is not what anyone is asking to achieve. What is being asked is not to lose a whole track just because one sector on the track was being written upon power loss. Dealing with many in-order writes being lost (in order), upon power loss, is something the filesystems are already written to assume, and the fsync(2) semantics are designed to work with. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 19:41:34 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDA9E16A4CE; Fri, 4 Mar 2005 19:41:34 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B26943D2D; Fri, 4 Mar 2005 19:41:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 3A5E37A41E; Fri, 4 Mar 2005 11:41:34 -0800 (PST) Message-ID: <4228B9ED.9040906@elischer.org> Date: Fri, 04 Mar 2005 11:41:33 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Aziz KEZZOU References: <37e13166050304080715525d7e@mail.gmail.com> In-Reply-To: <37e13166050304080715525d7e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: hackers@freebsd.org Subject: Re: generic network protocols parser ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 19:41:34 -0000 Aziz KEZZOU wrote: >Hi all, >I am wondering if any one knows about a generic parser which takes a >packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates >some data structre representing the packet ? > > you might look at DPF (a packet filter/classifier).. it has an interesting filter description language. >I've been searching for a while and found that ethereal and tcpdump >for example use specific data structres and functions to dissect each >protocol packets. Is this the only approach possible ? > >My supervisor suggested using a TLV (Type/Length/Value) approach >instead. Any opinions about that? > >If no such a parser exists is there any practical reason why ? > >Thanks, >Aziz >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 20:05:00 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 40DFC16A4CE; Fri, 4 Mar 2005 20:05:00 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j24K4xTm076678; Fri, 4 Mar 2005 15:04:59 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j24K4xXT076677; Fri, 4 Mar 2005 15:04:59 -0500 (EST) (envelope-from green) Date: Fri, 4 Mar 2005 15:04:58 -0500 From: Brian Fundakowski Feldman To: Aziz KEZZOU Message-ID: <20050304200458.GG6011@green.homeunix.org> References: <37e13166050304080715525d7e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37e13166050304080715525d7e@mail.gmail.com> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: hackers@freebsd.org Subject: Re: generic network protocols parser ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 20:05:00 -0000 On Fri, Mar 04, 2005 at 11:07:34AM -0500, Aziz KEZZOU wrote: > Hi all, > I am wondering if any one knows about a generic parser which takes a > packet (mbuf) of a certain protocol (e.g RSVP ) as input and generates > some data structre representing the packet ? > > I've been searching for a while and found that ethereal and tcpdump > for example use specific data structres and functions to dissect each > protocol packets. Is this the only approach possible ? > > My supervisor suggested using a TLV (Type/Length/Value) approach > instead. Any opinions about that? > > If no such a parser exists is there any practical reason why ? Ethereal uses TLV... -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 22:08:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A9B216A4CE; Fri, 4 Mar 2005 22:08:10 +0000 (GMT) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA44843D2D; Fri, 4 Mar 2005 22:08:09 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id ED9C8CFAD; Fri, 4 Mar 2005 17:08:08 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id DC2EF1A0991; Fri, 4 Mar 2005 17:08:05 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16936.56389.812572.568326@canoe.dclg.ca> Date: Fri, 4 Mar 2005 17:08:05 -0500 To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Subject: quagga and OSPFD and point-to-point tunnels. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 22:08:10 -0000 Here is an odd situation. If I start quagga ospfd after creating gre, tun, or gif devices, ospfd recognises them as point-to-point interfaces and everything works. However, if I start quagga and then create interfaces afterwards, the interfaces are not recognised as point-to-point interfaces and OSPF packets only travel in one direction (into the box). I'm not sure if the problem lies solely with quagga or FreeBSD or a little of both. For one, does the GRE device not have the POINTOPOINT flag set immediately? Has someone banged their head against this problem? It appears to cover all versions of FreeBSD, but I'm using 5.3-RELEASE-p5 to test. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 22:23:11 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6638F16A4CE for ; Fri, 4 Mar 2005 22:23:11 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE6CF43D46 for ; Fri, 4 Mar 2005 22:23:10 +0000 (GMT) (envelope-from wbierman@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so701466rnf for ; Fri, 04 Mar 2005 14:23:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Lqy7IAKODXUtXHxrlmiOob5IAXvkuzP9QQgTYsokI4F6eaGHOjUPymsVgXY4uQZPK8ALMh/IAjA/9IeW1B/0/I/GyK5ZWebsZ5JfLMLusfPx/+rov9IdVrPnJ1eQQ2k/sxfHtrapHgpuTPTZGIJY/t/21nf5f+g0GHfKlK3rjoQ= Received: by 10.38.99.65 with SMTP id w65mr191219rnb; Fri, 04 Mar 2005 14:23:09 -0800 (PST) Received: by 10.38.88.21 with HTTP; Fri, 4 Mar 2005 14:23:09 -0800 (PST) Message-ID: Date: Fri, 4 Mar 2005 12:23:09 -1000 From: William Bierman To: freebsd-hackers@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Subject: Re: init troubles with custom install .. perhaps a kernel bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: William Bierman List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 22:23:11 -0000 On Thu, 3 Mar 2005 22:25:37 -1000, William Bierman wrote: > Hello. I have been endeavoring to create my own livecd which will > mount a remote share from which to run scripts installing a ghost > image onto a local hard drive. I realize this may be more trouble > than it's worth, but I am doing it to easily assimilate new machines > into a Beowulf cluster... so I think it is. > > I have done everything I can think of to do this properly: > > 1) I used the process defined in the bsdlabel man page for setting up > the slices/partitions/labels/etc. (search for dd in the man page) > > 2) I extracted the ghost images, in the form of tarballs, to the /, > /usr, and /var slices. There is a partition for /tmp, but empty. I > also setup a 1Gb swap slice. These slices are setup to mirror how > they would be if I were to use the standard fbsd install cd. > > Now, here's the problem.. the kernel loads, and I start getting a list > of the devices it detects, and it reaches the point of 'Mounting root > from "ufs:ad0s1a"', then locks up. Either init is not being called, > or is stalling somewhere. I have disabled pnp in my BIOS settings, > and I have a single 16G IDE hard disk to which these operations are > being performed. I have tried the various options in the boot menu > (single user, safe mode, verbose logging, etc.) and the only useful > information I get is when in verbose logging mode, it reaches the halt > point, and additionally says: > > start_init: trying /sbin/init > > then halts. > > Could anyone shed some light on this for me? I can provide whatever > additional information may be necessary. I have done some extra tinkering with this. I have inserted debug statements in init_main.c and kern_init.c to figure out where the halt occurs, however it seems that the kernel process terminates succesfully after its execve() call. I also inserted a print statement at the start of init, which does not get displayed. I used warning() in init.c. I don't know the kernel back to front, but it seems the problem is in the handoff between the kernel and init. Again, any additional information can be provided (including the modifications I made to give debug statements to the kernel and init). Thanks! William From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 22:23:29 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F349C16A4EE for ; Fri, 4 Mar 2005 22:23:28 +0000 (GMT) Received: from evelocity03.evelocity.net (evelocity03.evelocity.net [64.240.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCEDC43D48 for ; Fri, 4 Mar 2005 22:23:27 +0000 (GMT) (envelope-from jyoung@ziggy.evelocity.net) Received: from ziggy.evelocity.net ([192.168.200.3])j24MMqZ2006510; Fri, 4 Mar 2005 17:22:52 -0500 Received: from ziggy.evelocity.net (localhost.evelocity.net [127.0.0.1]) by ziggy.evelocity.net (8.13.1/8.13.1) with ESMTP id j24Mb7Fb091327; Fri, 4 Mar 2005 16:37:07 -0600 (CST) (envelope-from jyoung@ziggy.evelocity.net) Received: from localhost (jyoung@localhost)j24Mb5e8091324; Fri, 4 Mar 2005 16:37:05 -0600 (CST) (envelope-from jyoung@ziggy.evelocity.net) Date: Fri, 4 Mar 2005 16:37:05 -0600 (CST) From: Jason Young To: Peter Jeremy In-Reply-To: <20050304183747.GS57256@cirb503493.alcatel.com.au> Message-ID: <20050304161201.B87252@ziggy.evelocity.net> References: <200503022115.j22LFnWk083926@marlena.vvi.at> <20050304183747.GS57256@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-762004626-1109975825=:87252" X-Spam-Status: No, score=-5.5 required=6.5 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0-r124864 X-Spam-Checker-Version: SpamAssassin 3.1.0-r124864 (2005-01-10) on evelocity03.evelocity.net cc: ALeine cc: phk@phk.freebsd.dk cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 22:23:29 -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. --0-762004626-1109975825=:87252 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 5 Mar 2005, Peter Jeremy wrote: > [CC list pruned] > > On Wed, 2005-Mar-02 13:15:49 -0800, ALeine wrote: >> If only hardware manufacturers were to equip hard drives with >> a mechanism to ensure atomic writes. A capacitor large enough >> to hold enough energy to flush the cache upon detecting the >> power supply was cut would be sufficient. > > I'm not sure thus is readily practical at the drive level. Based > on some back-of-envelope calculations using figures in a Seagate > Barracuda manual (which I happened to have handy): > - Random seek is 9.5 msec. > - Rotational period is 8.3msec > - Power consumption at 50% R/W, 50% seek is 0.82A @ 12V + 0.68A @ 5V > > A single random seek + track write will take 17.8 msec. This translates > to an electrical charge of 0.015C @ 12V and 0.012C @ 5V. > > Assuming the drive is designed to allow the supply rails to droop 20% > whilst functioning correctly during this shutdown phase (which is a > significantly bigger drop than the standard specifications), a single > random seek + track write would require the drive to include a 6000=B5F > capacitor on the 12V rail and a 12000=B5F capacitor on the 5V rail. > > As a first order approximation all Unix disk operations are writes > (reads can be satisfied from the buffer cache). Given the size of > current generation drive caches, it's more likely that there are > around 50 writes cached - which requires capacitors 50 times as large > - which would make them significantly larger than the drive itself. > >> They could even use >> a battery the status of which could be monitored via S.M.A.R.T., >> I don't see how implementing something like that could possibly >> make the cost noticably higher. > > Batteries (and standard supercaps) are generally designed to release > their energy over an extended period - several minutes is the lower > realistic limit. It would make sense to build a battery backup system > which maintained power for (say) 5 minutes. It's not realistic to > build a battery backup system that can release all it's available > energy in 1 second. > > If you're going to the effort of building a battery backup system, > you might as well backup the entire computer. These are available > off the shelf and have the added advantage of allowing users and > the system to clean up before the power goes away. > > --=20 > Peter Jeremy I must be missing something, but I'll succumb to the temptation and ask: Why not put a flash chip into the drive's onboard electronics, of the same= =20 size as the drive's cache, or the max possible size of all outstanding=20 cached writes? If power dies, park the heads immediately. Use your=20 last-gasp energy source of choice to commit the write cache contents into= =20 nonvolatile storage. Next time it's powered up, the drive firmware could=20 flush the outstanding write requests to "real" storage before coming ready= =20 to the operating system. At least some modern drives (seen this on HP/Compaq servers, etc) already= =20 have flash-upgradeable firmware. It's just a matter of adding a little=20 more. You would use it only when power fails, so it's not like you would=20 wear it out. Surely this would require far less power than spinning and seeking the=20 disk for the required amount of time? It might take longer based on the=20 flash chip's write speed, but that's probably a feature, since a small=20 battery would be able to supply much less current over time. Cost should=20 be reasonably low since this stuff is in all sorts of consumer devices. Jason Young, CCIE #8607 (R&S, Voice), MCSE Consulting Engineer e-velocity technical consulting, llc. (513)677-6223 x108 --0-762004626-1109975825=:87252-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 22:25:01 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 856C916A4CE for ; Fri, 4 Mar 2005 22:25:01 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3056D43D3F for ; Fri, 4 Mar 2005 22:25:01 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j242TkoH015208; Thu, 3 Mar 2005 18:29:51 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j242TdVH015207; Thu, 3 Mar 2005 18:29:39 -0800 (PST) (envelope-from www) Date: Thu, 3 Mar 2005 18:29:39 -0800 (PST) Message-Id: <200503040229.j242TdVH015207@marlena.vvi.at> To: abuse@spamalicious.com From: "ALeine" cc: elric@imrryr.org cc: tls@rek.tjls.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 22:25:01 -0000 abuse@spamalicious.com wrote: > I'm not going to defend what Thor said, nor do I even think it's > worth discussing as it largely amounts to an "appeal to privileged > knowledge." > However, this is some extremely sloppy thinking in your writing. You do not understand what was said. > To wit: > > On Thursday 03 March 2005 02:43, ALeine wrote: > > At any time half of all the people are wrong about something, > > it's only a matter of time when your time will come to be in the > > wrong half or rather the right half to be wrong. > > That's a false dichotomy. There are many subjects on which the > vast majority of people agree (such, as, I'll wager, the roundness > of the Earth). Have you ever heard of statistical probability distribution and the logical principle of bivalence (tertium non datur)? If at any time there are x people then exists (vertically mirrored E) such a proposition P that for at least x/2 of the people the proposition R "x is wrong about P" holds true. The people who are wrong and the proposition(s) are dynamic and change with time but that property remains true at all times in a system with sufficient propositions and a large enough number of people. Q.E.D. > It is being given a chance. "Giving it a chance" does not mean > "stepping back and ignoring it until someone publishes an exploit." Giving it a chance does not mean spreading FUD about it and shouting around "It's new, it must be bad! I have not even read the papers or looked at the code myself, but I will criticize it because I like NetBSD better!" If you want to really be constructive do something that is constructive, analyze GBDE, write a paper, improve the code. You're just adding noise to the discussion, you may have as well commented on my punctuation marks. > At least one weakness has been identified -- namely, using a weaker > encryption mode for the key-key blocks can reduce the strength of > the entire system. Or to put it metaphorically, "an algorithm is only > as strong as its weakest link." You really don't know what you're talking about, do you? > > GBDE is not replacing anything because there was nothing like > > it to replace in the first place. > > That's purely false. There are several other disk encryption > systems around. You're right, IIRC PKZIP v1.10 had DES encryption back in 1990, someone should have told PHK! :-P Please, get a clue, read PHK's papers. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 22:30:38 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AF1216A4CE for ; Fri, 4 Mar 2005 22:30:38 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B24E743D39 for ; Fri, 4 Mar 2005 22:30:37 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j24MRhs7031256 for ; Fri, 4 Mar 2005 15:27:43 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 04 Mar 2005 15:27:43 -0700 (MST) Message-Id: <20050304.152743.08337586.imp@bsdimp.com> To: freebsd-hackers@freebsd.org From: Warner Losh X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Mar__4_15:27:43_2005_946)--" Content-Transfer-Encoding: 7bit Subject: Fw: Libre Software Meeting 2005 : Call for contributions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 22:30:38 -0000 ----Next_Part(Fri_Mar__4_15:27:43_2005_946)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I haven't seen this forwarded to the FreeBSD list, so I thought I'd take the liberty of forwarding it here. Warner ----Next_Part(Fri_Mar__4_15:27:43_2005_946)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: bounces-tech-kern-owner-imp=village.org@NetBSD.org Delivery-Date: Fri, 04 Mar 2005 13:21:39 -0700 Received: from rover.village.org (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j24KIe9T029930 for ; Fri, 4 Mar 2005 13:18:40 -0700 (MST) (envelope-from bounces-tech-kern-owner-imp=village.org@NetBSD.org) Received: from schizoid.village.org (schizoid.village.org [10.200.4.1]) by rover.village.org (8.13.1/8.13.1) with ESMTP id j24KIL6q072767 for ; Fri, 4 Mar 2005 13:18:21 -0700 (MST) (envelope-from bounces-tech-kern-owner-imp=village.org@NetBSD.org) Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by schizoid.village.org (8.12.9p2/8.12.9) with ESMTP id j24KIKVY058744 for ; Fri, 4 Mar 2005 13:18:20 -0700 (MST) (envelope-from bounces-tech-kern-owner-imp=village.org@NetBSD.org) Received: by mail.netbsd.org (Postfix, from userid 0) id 53A255438; Fri, 4 Mar 2005 20:17:49 +0000 (UTC) X-Original-To: tech-kern@NetBSD.org Delivered-To: tech-kern@NetBSD.org Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by mail.netbsd.org (Postfix) with ESMTP id D008C5178 for ; Fri, 4 Mar 2005 20:17:46 +0000 (UTC) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by postfix1-c.free.fr (Postfix) with ESMTP id C65E0CBD1FA for ; Fri, 4 Mar 2005 21:01:01 +0100 (CET) Received: from [192.168.1.2] (humanoidz.org [82.237.107.242]) by postfix3-2.free.fr (Postfix) with ESMTP id 132BAC07B; Fri, 4 Mar 2005 21:00:55 +0100 (CET) Message-ID: <4228BE76.1090806@enix.org> Date: Fri, 04 Mar 2005 21:00:54 +0100 From: Thomas Petazzoni User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: fr, en To: tech-kern@NetBSD.org Cc: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Subject: Libre Software Meeting 2005 : Call for contributions X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: tech-kern-owner@NetBSD.org Precedence: list X-MIME-Autoconverted: from quoted-printable to 8bit by harmony.village.org id j24KIe9T029930 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on harmony.village.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.2 Mime-Version: 1.0 (modified by Mew) Content-Transfer-Encoding: quoted-printable (modified by Mew) CALL FOR CONTRIBUTIONS Libre Software Meeting 2005 --------------------------------------- Operating system design and implementation The Libre Software Meeting (LSM) has been one of the most important Free Software events in France since the year 2000 [0]. This year, the meeting will take place from July 5th to July 9th in Dijon, to the East of France. The Libre Software Meeting aims at allowing designers and developers of free software projects [1] from different places to meed and and share their ideas and experiences. LSM is also an opportunity to discuss societal issues. Technical conferences cover a wide range of topics, from high-level programming languages to databases, through security concerns. The "operating system design and development" topic is looking for speakers to present free software projects. Technical topics include (but are not limited to): * design and implementation of operating systems: architecture, services, libraries, use of high-level languages and advanced programming techniques such as AOP, dynamic reconfiguration, etc.;= * kernel subsystems: schedulers, I/O schedulers, virtual memory management, etc.; * filesystem implementation: journalized, distributed filesystems, etc.; * realtime extensions to free operating systems; * virtualization tools (i.e. Xen, User-Mode-Linux, etc.); * kernel development tools : debuggers, performance evaluation, etc.= ; * distributed operating systems; * embedded systems development. Programs of previous years are available online [2]. The program for 2005 is being defined and a tentative program is available online [3]. There is no programme committee (it is not a scientific conference) and selection process is expected to remain as lightweight as possible. Volunteers should contact Thomas Petazzoni and Ludovic Court=E8s by June 2005. Speakers= are encouraged to write a small paper (6 to 12 A4 sheets) summarizing their presentation (in an open format such as PostScript or PDF). Ludovic Court=E8s and Thomas Petazzoni. [0] http://lsm2000.abul.org , http://lsm2001.abul.org , http://lsm2002.abul.org , http://lsm2003.abul.org , http://lsm2004.abul.org . [1] http://www.gnu.org/philosophy/free-sw.html [2] http://wiki.ael.be/rmll2003/index.php/ThemeOperatingSystem , http://lsm2002.abul.org/program/topic06/topic06.php3 , http://lsm2000.abul.org/program/topic06_en.html . [3] http://www.rencontresmondiales.org/sections/conference/noyau_et_sys= teme -- = PETAZZONI Thomas - thomas.petazzoni@enix.org http://thomas.enix.org - Jabber: thomas.petazzoni@jabber.dk KOS: http://kos.enix.org/ - SOS: http://sos.enix.org Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E 1624 F653 CB30 98D3 F7A7 ----Next_Part(Fri_Mar__4_15:27:43_2005_946)---- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 22:43:49 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B2E316A4CE for ; Fri, 4 Mar 2005 22:43:49 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id C357443D1D for ; Fri, 4 Mar 2005 22:43:48 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j242mgoH015612; Thu, 3 Mar 2005 18:48:45 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j242mY55015610; Thu, 3 Mar 2005 18:48:34 -0800 (PST) (envelope-from www) Date: Thu, 3 Mar 2005 18:48:34 -0800 (PST) Message-Id: <200503040248.j242mY55015610@marlena.vvi.at> To: perry@piermont.com From: "ALeine" cc: tech-security@NetBSD.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: elric@imrryr.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 22:43:49 -0000 perry@piermont.com wrote: > I have no doubt that was the intent. The question is, did he > achieve it? You seem to be making claims to the contrary, but at the same time you do not even know some basic facts about GBDE. Have you really read even the gbde(8) man page? If so, how come you missed that big notice in bold at the very top, informing users that "GBDE should be considered a slightly suspect experimental facility." It was not encrypted, so I'm sure you could have read it. But no, you come running and start spreading FUD about GBDE and making claims about GBDE being promoted as "the perfect solution." For someone who talks a lot about merit your words and actions show very little of it. > Yup. And Roland made the algorithm you use for encrypting your > disk *pluggable*. That way, if AES is broken, you can replace it > with the next big thing and move on with your life. > Now, if AES is indeed broken, GBDE is in serious trouble, but CGD > is not. Specific users of CGD have to change their drives, but the > framework continues to work as advertised. GBDE can easily be extended to be modular in that way. AFAIK PHK does not see a need for that because he does not want to increase the complexity, but it might be implemented at some point, it's just not a priority. If AES is broken, can CGD re-encrypt the entire drive using the new replacement algorithm on the fly, without requiring any additional storage? If not, having such modularity is a bit of a joke, it gives users a false sense of security. > > The fact that Roland did not invent any new ways of using > > algorithms does not mean that CGD is more secure. > > It does, however, mean right from the get-go that the standard > analysis you use for looking at this works right out of the box. > You don't have to invent anything new to figure out if it works > right. Sometimes the biggest mistakes hide in simplicity, I believe SMB demonstrated that point quite aptly with the Needham-Schroeder protocol flaw that was totally obvious, but went unnoticed for 18 years. When a 3 line protocol can be so obviously flawed and the flaw goes unnoticed for such a long time I hope you are not overly confident about CGD working right. > Do you know enough about cryptography to have an opinion, humble > or not? For example, if I handed you something encrypted in a > polyalphabetic cipher and asked you to tell me the key length, > off the top of your hand would you know how to use the index of > coincidence to do that? If I asked you to explain the difference > between the security of inner and outer CBC 3DES, could you tell > me? Could you explain what a characteristic is and how it is used > in differential cryptanalysis? Have you actually read any of my posts or do you have a template of questions that you send to anyone you feel "is welcome to join the crypto community?" You speak of the openness and merit and how the crypto community undeserverdly has a bad reputation for being elitist and dismissive of outsiders, yet you are only reinforcing that very same stereotype in the worst way. Your condescending tone is not welcome, but in case you seriously expected an answer I suggest you take a course in cryptography, you may even get help from someone at sci.crypto, I hear they are really friendly there and you should be able to find the right pair for your kind of character(istic) there. :-> > I'm not saying, by the way, that you should take my opinion or > anyone else's as gospel. Argument from authority is worthless. > At crypto conferences you will find differing opinions -- merely > understanding crypto doesn't mean you are right. You should > learn enough to form your own opinion. However, that implies that > you must first learn enough that you have a basis on which to form > it. If you don't know anything about medicine, do you have any good > basis for telling your anesthesiologist to use a different drug in > your surgery? After what I've seen from you I would hardly call you an author, let alone an authority on anything. You contradict yourself at least twice a day, you make unsubstantiated claims, you talk down to people and the chip on your shoulder is one of the biggest I've seen. Worst of all, you have the time to keep wasting people's time with your noise. If you are bored take up a hobby, perhaps hosting a radio show might be fun? > So you say that to you, using one key for the entire disk is a > bad idea. Very good. On what basis do you say this? On the same basis that I prefer to wear a jacket with many pockets rather than a bag. You, of course, have read all my previous posts in this discussion and know what I am talking about, that's why you had to ask me about something I already explained. > Now it *is* true that you shouldn't use a key for too much data, > and we have some ways these days of calculating how much data "too > much" is. Do you understand how that calculation is performed? Are you sure it would be OK for me to answer that question? After all, I'm not a member of the crypto community and I might insult some member of the crypto community by answering. Oh, well, I'll just have to risk it. AES 256 CBC mode collision after: key size * 2^(cipher block size / 2) = 16 * 2^(128/2) = 2^68 bytes > > You have to trust Roland to integrate the well known and > > understood algorithms in a correct way, trusting the algorithms > > alone is not enough. > > His code did indeed have some bugs to begin with. It was reviewed > and they were fixed. For now. At least the most obvious ones - or should I say the least obvious ones? > > I am not designing cryptographic algorithms, what PHK did with > > GBDE cannot be compared to inventing MD5, snap out of it, you > > are starting to sound like a broken record. > > But the problem is that he crossed a line, so it *can* be > compared to things like inventing MD5. He isn't merely using existing > algorithms in well known ways. He is, in fact, using algorithms in modes > that they having been used in before and making very very specific > claims of work factors to break these new modes. Oh my GOD, he crossed the line, how dare he! There are probably angry cryptographers picketing in front of his house now. Luckily it's quite cold this time of year in Denmark as well, so they should not be there long. > > I assure you PHK knows very well what he is doing > > I've read his paper. I must respectfully disagree. I must respectfully disagree with you, then. > > and I think you should not mention his name in the same breath > > along with the names of the designers of WEP. > > The comparison seems to be perfectly apt -- people competent in > one field assuming that another very complicated field is trivial, > and extending their work into that other field, in which they are no > longer competent. Again you've proven that you do not even read what people here have written, even if they replied to you directly. I believe PHK has great respect for the cryptographers and the profession as such and that he in no way finds it to be trivial, quite the opposite. But you seem to enjoy writing more than reading and you probably talk a lot because you enjoy hearing the sound of your own voice. Maybe a radio show would be something for you to consider? :-> > It does mean that if I invented a new mode for using a set of > ciphers, I would first send them to a bunch of crypto geeks to vet, > then I would write a detailed paper, and after a couple of years I > might consider actually using it in the real world. If you ever invent anything usable in a production environment let me know. Also let me know when your radio show will be on and on what frequency so I know when to tune out. :-> ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 23:13:06 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A18FF16A4CE for ; Fri, 4 Mar 2005 23:13:06 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B62143D5E for ; Fri, 4 Mar 2005 23:13:04 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j243HxoH016009; Thu, 3 Mar 2005 19:18:01 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j243HrZ2016007; Thu, 3 Mar 2005 19:17:53 -0800 (PST) (envelope-from www) Date: Thu, 3 Mar 2005 19:17:53 -0800 (PST) Message-Id: <200503040317.j243HrZ2016007@marlena.vvi.at> To: elric@imrryr.org From: "ALeine" cc: briggs@netbsd.org cc: perry@piermont.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 23:13:06 -0000 elric@imrryr.org wrote: > It is a serial attack that is: > > for (i=0; i < n; i++) { > crack the i'th key--key block; > } > > So it is actually where $n$ is the number of key--key sectors: [ ASCII art removed and sent to the museum of modern arts :-> ] > > So, for a disk with 2^30 key--key sectors it would be > > 2^30 * 2^128 = 2^158 > > I realise that PHK has been claiming that you might get false > positives, and that you somehow have to maintain a matrix of past > this and that. It is a lot simpler than this really. Your assumption is wrong. First of all, the first sector of the encrypted image does not necessarily start at the beginning of the disk, nor does the last sector have to be the last sector of the disk. At initialization first_sector, last_sector and total_sectors can be set so that the encrypted image is placed at an offset from both sides of the disk. If you also use random_flush that free space (padding) is filled with random garbage automatically, so one cannot detect where the encrypted image actually begins or ends. I would like to see some statistics regarding the distribution of superblock, inode and directory structures, but I believe the attack you are describing cannot be automated to the point of being practical. You also completely ignored the fact that the smallest logical data sector size is 512 bytes, but that it can also be set to any reasonable 2^n size (as PHK already pointed out, 2kb is the recommended size on FFS). You can only guess as to the size of the logical sector. You also have to take into acount the fact that there are at least 4 512 byte lock sectors (regardless of the size of the logical sector) which will thwart your automated brute forcing attempt further. Lock sectors can be anywhere, their location is picked randomly at initialization and everything else has to map around them, so you cannot assume anything about their location or know that you stumbled upon them. If you take into account that you cannot be sure that you got a complete zone or that you are indeed looking at a single logical data sector things become complicated quickly, so your estimate is way too optimistic. BTW, since you claim to have studied the papers, you may want to start using the correct terminology, there is no such thing as a key-key sector, there are only key sectors, data sectors, lock sectors, the master key, generated key-keys and sector keys. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 23:17:35 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44F1916A4CE for ; Fri, 4 Mar 2005 23:17:35 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45DDD43D55 for ; Fri, 4 Mar 2005 23:17:34 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j243MBoH016074; Thu, 3 Mar 2005 19:22:16 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j243M5Fe016073; Thu, 3 Mar 2005 19:22:05 -0800 (PST) (envelope-from www) Date: Thu, 3 Mar 2005 19:22:05 -0800 (PST) Message-Id: <200503040322.j243M5Fe016073@marlena.vvi.at> To: jwise@draga.com From: "ALeine" cc: elric@imrryr.org cc: tls@rek.tjls.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 23:17:35 -0000 jwise@draga.com wrote: > Your disk has 2^128 sectors? Where can I buy one of those? In the same movie I referenced in the post you took that from. :-> Either there or in the dream I referenced a bit later. :-> ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 23:26:48 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA9CE16A4CF for ; Fri, 4 Mar 2005 23:26:48 +0000 (GMT) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B39643D2D for ; Fri, 4 Mar 2005 23:26:48 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j24NQc0e024777 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 5 Mar 2005 10:26:39 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j24NQc7l008364; Sat, 5 Mar 2005 10:26:38 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j24NQbUb008363; Sat, 5 Mar 2005 10:26:37 +1100 (EST) (envelope-from pjeremy) Date: Sat, 5 Mar 2005 10:26:37 +1100 From: Peter Jeremy To: Jason Young Message-ID: <20050304232636.GB4394@cirb503493.alcatel.com.au> References: <200503022115.j22LFnWk083926@marlena.vvi.at> <20050304183747.GS57256@cirb503493.alcatel.com.au> <20050304161201.B87252@ziggy.evelocity.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050304161201.B87252@ziggy.evelocity.net> User-Agent: Mutt/1.4.2i cc: ALeine cc: phk@phk.freebsd.dk cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 23:26:49 -0000 On Fri, 2005-Mar-04 16:37:05 -0600, Jason Young wrote: >Why not put a flash chip into the drive's onboard electronics, of the same >size as the drive's cache, or the max possible size of all outstanding >cached writes? That seems to be a better idea. ISTR that once upon a time, vendors made chips that had RAM shadowed by EEPROM which gave you the non-volatility of EEPROM with the read/write performance of RAM. Since the EEPROM was written at once, you only needed 10-20 msec hold-up to preserve your RAM. >At least some modern drives (seen this on HP/Compaq servers, etc) already >have flash-upgradeable firmware. It's just a matter of adding a little >more. You would use it only when power fails, so it's not like you would >wear it out. I think that most modern drives have very little firmware in ROM - just a bootstrap - with most of the firmware stored on the disk itself. -- Peter Jeremy From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 23:30:08 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 047C716A4CE for ; Fri, 4 Mar 2005 23:30:08 +0000 (GMT) Received: from pedigree.cs.ubc.ca (pedigree.cs.ubc.ca [142.103.6.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A632643D2F for ; Fri, 4 Mar 2005 23:30:07 +0000 (GMT) (envelope-from kcai@cs.ubc.ca) Received: from granville.cs.ubc.ca (granville.cs.ubc.ca [142.103.7.20]) by pedigree.cs.ubc.ca (8.12.10/8.11.4) with ESMTP id j24NU4J5020074; Fri, 4 Mar 2005 15:30:04 -0800 (PST) Date: Fri, 4 Mar 2005 15:30:04 -0800 (PST) From: Kan Cai To: hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Brad Penoff Subject: FreeBSD 4.11-RELEASE & SACK X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 23:30:08 -0000 Greetings, I posted this question on freebsd-question list yesterday, but no replies. So I am just trying my luck here. Thanks in advance. I've installed the standard FreeBSD 4.11-RELEASE and have realized that the sysctl option for enabling SACK in TCP is not available (net.inet.tcp.do_sack). Additionally, the tcp_sack.c file is not in the /usr/src/sys/netinet so I'm guessing this indicates that I need a patch. Hoping to be able to use SACK in FreeBSD 4.11-RELEASE, I wanted to ask : 1) Is my guess correct (Do I need a patch)? Or is my kernel configuration file missing an option? 2) Assuming I need a patch, what patch is generally recommended for using SACK under TCP in FreeBSD 4.11-RELEASE? Any help would be most appreciated. Thanks, ken From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 23:38:35 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E2D816A4CE for ; Fri, 4 Mar 2005 23:38:35 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDFAE43D31 for ; Fri, 4 Mar 2005 23:38:34 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j243hVoH016422; Thu, 3 Mar 2005 19:43:33 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j243hPdC016421; Thu, 3 Mar 2005 19:43:25 -0800 (PST) (envelope-from www) Date: Thu, 3 Mar 2005 19:43:25 -0800 (PST) Message-Id: <200503040343.j243hPdC016421@marlena.vvi.at> To: abuse@spamalicious.com From: "ALeine" cc: elric@imrryr.org cc: tls@rek.tjls.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 23:38:35 -0000 abuse@spamalicious.com wrote: > The principle of bivalence merely states that every proposition > is either true or false. "Tertium non datur" is the law of the > excluded middle, which is not the same. > Furthermore, neither one says anything about half > the population falling on one side or the other; you're either making > that up or confusing it with something else. > > I refer you to: > > http://en.wikipedia.org/wiki/Bivalent > http://en.wikipedia.org/wiki/Law_of_excluded_middle You are wrong, tertium non datur is the law of the exclusion of the THIRD possibility (it stems from Latin and means "the third is not given"), meaning that any statement can only be either true or false. Some of us have learned mathematics at school, you should try that too, eventhough Wikipedia can be informative, I'm sure. :-> > > You really don't know what you're talking about, do you? > > Hey, you're the one who argued that it's 2^384 to break. Even > PHK's own paper on GBDE puts the effort to break it at 2^129. > Who is it that hasn't read the paper? Roland argued against 2^384, I argued against Roland's underestimate of 2^158, not for 2^384 specifically. Please learn to pay attention. > > You're right, IIRC PKZIP v1.10 had DES encryption back in 1990, > > someone should have told PHK! :-P Please, get a clue, read PHK's > > papers. > > And yet more nonsense. PKZIP isn't even a disk encryption > system. And you know very well that CGD and Loop-AES both predate > GBDE. Claiming that there is "nothing like it" is objectively false. > > Now, if you'd care to stop making ad hominem attacks, perhaps > there can be some useful discussion. Perfer et obdura, dolor hic tibi proderit olim. :-)) Go check if that is in Wikipedia. :-)) You can email me for the translation if you cannot find it online. :-> ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 00:05:28 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A088016A4CE for ; Sat, 5 Mar 2005 00:05:28 +0000 (GMT) Received: from mail21.sea5.speakeasy.net (mail21.sea5.speakeasy.net [69.17.117.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FDCA43D46 for ; Sat, 5 Mar 2005 00:05:28 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 27924 invoked from network); 5 Mar 2005 00:05:28 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail21.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 5 Mar 2005 00:05:27 -0000 Received: from hydrogen.funkthat.com (qjylqn@localhost.funkthat.com [127.0.0.1])j2505QGH083982; Fri, 4 Mar 2005 16:05:26 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j2505PQX083979; Fri, 4 Mar 2005 16:05:25 -0800 (PST) Date: Fri, 4 Mar 2005 16:05:24 -0800 From: John-Mark Gurney To: Thor Lancelot Simon Message-ID: <20050305000524.GC89312@funkthat.com> Mail-Followup-To: Thor Lancelot Simon , tech-security@netbsd.org, hackers@freebsd.org, cryptography@metzdowd.com References: <20050303200005.GA21499@panix.com> <10848.1109882513@critter.freebsd.dk> <20050303210113.GA19398@panix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050303210113.GA19398@panix.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: tech-security@netbsd.org cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 00:05:28 -0000 Thor Lancelot Simon wrote this message on Thu, Mar 03, 2005 at 16:01 -0500: > [.. ] (that "cgd", though > it had existed for precisely two days when you checked GBDE into the Just because I am tired of incorrect information (repeated) when it is freely available on the respective websites: CGD: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/cgd.c Revision 1.1 / (download) - annotate - [select for diffs], Fri Oct 4 18:22:35 2002 UTC (2 years, 5 months ago) by elric BDE: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/bde/g_bde.c Revision 1.1 / (download) - annotate - [select for diffs], Sat Oct 19 17:02:16 2002 UTC (2 years, 4 months ago) by phk So, according to this, CGD existed in NetBSD's source tree 15 days before GBDE was committed... And it took me all of one minute to find this. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 00:47:11 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F50D16A4CE for ; Sat, 5 Mar 2005 00:47:11 +0000 (GMT) Received: from mail.foolishgames.com (mail.foolishgames.com [216.55.178.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C66843D49 for ; Sat, 5 Mar 2005 00:47:11 +0000 (GMT) (envelope-from luke@foolishgames.com) Received: from [192.168.0.49] (24.247.120.6.kzo.mi.chartermi.net [24.247.120.6]) (authenticated bits=0)j250l5B0080177 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Mar 2005 16:47:06 -0800 (PST) (envelope-from luke@foolishgames.com) X-Authentication-Warning: mail.foolishgames.com: Host 24.247.120.6.kzo.mi.chartermi.net [24.247.120.6] claimed to be [192.168.0.49] Message-Id: X-Habeas-Swe-6: email in exchange for a license for this Habeas X-Habeas-Swe-3: like Habeas SWE (tm) Date: Fri, 4 Mar 2005 19:46:38 -0500 X-Habeas-Swe-8: Message (HCM) and not spam. Please report use of this From: Lucas Holt X-Habeas-Swe-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-Swe-2: brightly anticipated In-Reply-To: <000401c520d5$a6b6ae00$090210ac@BORJA> References: <000401c520d5$a6b6ae00$090210ac@BORJA> To: "Andriy Tkachuk" X-Habeas-Swe-7: warrant mark warrants that this is a Habeas Compliant Mime-Version: 1.0 (Apple Message framework v619.2) X-Habeas-Swe-4: Copyright 2002 Habeas (tm) Content-Type: text/plain; charset=US-ASCII; format=flowed X-Habeas-Swe-1: winter into spring Content-Transfer-Encoding: 7bit X-Habeas-Swe-9: mark in spam to . X-Mailer: Apple Mail (2.619.2) cc: freebsd-hackers@freebsd.org Subject: Re: sched_ule, runqueues, priority, and O(1) sheduling question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 00:47:11 -0000 I haven't looked at it, but could it just be referring to retrieving a thread from the queue. Just pulling something off a queue is a O(1) operation. The order it places things in the queue probably is not. :) On Mar 4, 2005, at 11:15 AM, Andriy Tkachuk wrote: > Hi folks. > > I wander how O(1) sheduling works in ULE. > In ule.pdf Jeff wrote: > > Threads are picked from the current queue in priority order until the > current queue is empty. > > As far as I understand the algorithm is O(n) > where n - number of READY TO RUN processes, > not all processes isn't it? > > thanks, > Andriy. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > > Lucas Holt Luke@FoolishGames.com ________________________________________________________ FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) FoolishGames.net (Enemy Territory IoM site) From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 00:52:55 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA6DB16A4CE for ; Sat, 5 Mar 2005 00:52:55 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1E3243D53 for ; Sat, 5 Mar 2005 00:52:55 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 8C3007A425; Fri, 4 Mar 2005 16:52:55 -0800 (PST) Message-ID: <422902E7.1080104@elischer.org> Date: Fri, 04 Mar 2005 16:52:55 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Kan Cai References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: Brad Penoff Subject: Re: FreeBSD 4.11-RELEASE & SACK X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 00:52:55 -0000 Kan Cai wrote: > > Greetings, > > I posted this question on freebsd-question list yesterday, but no > replies. So I am just trying my luck here. Thanks in advance. > > I've installed the standard FreeBSD 4.11-RELEASE and have realized > that the sysctl option for enabling SACK in TCP is not available > (net.inet.tcp.do_sack). Additionally, the tcp_sack.c file is not in > the /usr/src/sys/netinet so I'm guessing this indicates that I need a > patch. Hoping to be able to use SACK in FreeBSD 4.11-RELEASE, I wanted > to ask : > > 1) Is my guess correct (Do I need a patch)? Or is my kernel > configuration file missing an option? > 2) Assuming I need a patch, what patch is generally recommended for > using SACK under TCP in FreeBSD 4.11-RELEASE? the people who contributed the SACK code contrinuted it only to the 5.x or later relases. It would be up to someone else to the the back port to 4.x. > > Any help would be most appreciated. Thanks, > > ken > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 01:33:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CAF116A4CE for ; Sat, 5 Mar 2005 01:33:10 +0000 (GMT) Received: from panther.cs.ucla.edu (Panther.CS.UCLA.EDU [131.179.128.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A5D143D2F for ; Sat, 5 Mar 2005 01:33:10 +0000 (GMT) (envelope-from yanyu@CS.UCLA.EDU) Received: from localhost (yanyu@localhost)j251X9410985 for ; Fri, 4 Mar 2005 17:33:09 -0800 (PST) Date: Fri, 4 Mar 2005 17:33:09 -0800 (PST) From: Yan Yu To: FreeBSD-Hackers In-Reply-To: <42288070.8030507@telus.net> Message-ID: References: <42288070.8030507@telus.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: filedesc struct in filedesc.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 01:33:10 -0000 Hello, all, I have a Q on filedesc.h: i am wondering whether the order of the field in struct _filedesc_ (in sys/filedesc.h) matters? I added a field to _filedesc_ struct in filedesc.h. It is a dynamically allocated list, just as fd_ofiles, or fd_ofilefalgs. I put my new added list right after fd_fileflags, and allocate/initialize it just as fd_ofiles or fd_ofileflags. Even if I put little of my extra code in except this data field, and codes to allocate and initialize it ( i put it in fdgrowtable(), just as the existing kernel initialize fd_ofiles, or fd_ofileflgs. (i believe i did this allcaotion/initialization part right:) the problem i had is page fault and then crashes the kernel. If I put my extra data fields at the end of _filedesc_ or _filedesc0_ struct, it then works.. My Q is: is there places in the kernel that not directly use the field name to access a member of "filedesc" struct, but implicitly assuming the ordering of the fields in "strcut filedesc", e.g., they may use offset to access a field? so then my new added field may mess up the original code? I found one such place in fdgrowtable() in kern_descrip.c there is one such line: ------------------------------------------ nfileflags = (char *)&ntable[nnfiles]; ------------------------------------------ so it allocates and assumes that fd_ofileflags is right after fd_ofiles in _filedesc_ struct. I am curious is there other places in the kernel that implicitly use the info on the order that those fields are defined? i hope my Q makes sense.. many thanks, yan From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 06:57:46 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EA0216A4CE for ; Sat, 5 Mar 2005 06:57:46 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 672CD43D1D for ; Sat, 5 Mar 2005 06:57:45 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id 52D4B3567B for ; Sat, 5 Mar 2005 08:57:41 +0200 (EET) Message-ID: <009501c52150$9f272450$090210ac@BORJA> From: "Andriy Tkachuk" To: References: <000401c520d5$a6b6ae00$090210ac@BORJA> Date: Sat, 5 Mar 2005 12:27:34 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: sched_ule, runqueues, priority, and O(1) sheduling question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 06:57:46 -0000 >I haven't looked at it, but could it just be referring to retrieving a > thread from the queue. Just pulling something off a queue is a O(1) > operation. The order it places things in the queue probably is not. :) You rihgt - just pulling something off a queue is a O(1) operation, but before pulling algorithm is finding the thread with highest priority, with it have to pull - this is not the O(1) operation. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 19:45:17 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE8C916A4CE for ; Fri, 4 Mar 2005 19:45:17 +0000 (GMT) Received: from himring.draga.com (himring.draga.com [168.100.199.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DB0143D4C for ; Fri, 4 Mar 2005 19:45:17 +0000 (GMT) (envelope-from jwise@draga.com) Received: from himring.draga.com (localhost [127.0.0.1]) by himring.draga.com (8.12.11/8.12.11) with ESMTP id j24JixqI019495; Fri, 4 Mar 2005 14:44:59 -0500 (EST) Received: from localhost (jwise@localhost)j24JisZx009084; Fri, 4 Mar 2005 14:44:54 -0500 (EST) X-Authentication-Warning: himring.draga.com: jwise owned process doing -bs Date: Fri, 4 Mar 2005 14:44:49 -0500 (EST) From: Jim Wise To: Jason Thorpe In-Reply-To: Message-ID: References: <200503030033.j230XG4G086979@marlena.vvi.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sat, 05 Mar 2005 13:01:48 +0000 cc: ALeine cc: elric@imrryr.org cc: tls@rek.tjls.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 19:45:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 4 Mar 2005, Jason Thorpe wrote: > On Mar 2, 2005, at 4:33 PM, ALeine wrote: > >> You need 2^128 steps to break the encryption of a single sector. >> But you have no idea which of the 2^128 sectors is the right one, Your disk has 2^128 sectors? Where can I buy one of those? - -- Jim Wise jwise@draga.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (NetBSD) iD8DBQFCKLq2pRpI6SYACmIRAonlAKCxPFbBha4kmRTpV2nkjoTl1N2m0QCfeZoE +uZPC9k43JnMYlQQlTaP+S4= =UFPu -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 22:59:29 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87C7916A4CE for ; Fri, 4 Mar 2005 22:59:29 +0000 (GMT) Received: from hiroshima.ihack.net (209-6-103-199.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.103.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE1C643D39 for ; Fri, 4 Mar 2005 22:59:28 +0000 (GMT) (envelope-from abuse@spamalicious.com) Received: by hiroshima.ihack.net (Postfix, from userid 27753) id C2CDD2A65D3; Fri, 4 Mar 2005 22:58:57 +0000 (UTC) From: "Charles M. Hannum" Organization: By Noon Software, Inc. To: "ALeine" Date: Fri, 4 Mar 2005 22:58:56 +0000 User-Agent: KMail/1.7 References: <200503040229.j242TdVH015207@marlena.vvi.at> In-Reply-To: <200503040229.j242TdVH015207@marlena.vvi.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503042258.57064.abuse@spamalicious.com> X-Mailman-Approved-At: Sat, 05 Mar 2005 13:01:48 +0000 cc: elric@imrryr.org cc: tls@rek.tjls.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 22:59:29 -0000 On Friday 04 March 2005 02:29, ALeine wrote: > > To wit: > > > > On Thursday 03 March 2005 02:43, ALeine wrote: > > > At any time half of all the people are wrong about something, > > > it's only a matter of time when your time will come to be in the > > > wrong half or rather the right half to be wrong. > > > > That's a false dichotomy. There are many subjects on which the > > vast majority of people agree (such, as, I'll wager, the roundness > > of the Earth). > > Have you ever heard of statistical probability distribution and the > logical principle of bivalence (tertium non datur)? The principle of bivalence merely states that every proposition is either true or false. "Tertium non datur" is the law of the excluded middle, which is not the same. Furthermore, neither one says anything about half the population falling on one side or the other; you're either making that up or confusing it with something else. I refer you to: http://en.wikipedia.org/wiki/Bivalent http://en.wikipedia.org/wiki/Law_of_excluded_middle > > It is being given a chance. "Giving it a chance" does not mean > > "stepping back and ignoring it until someone publishes an exploit." > > Giving it a chance does not mean spreading FUD about it and shouting > around "It's new, it must be bad! I have not even read the papers or > looked at the code myself, but I will criticize it because I like > NetBSD better!" And, in fact, I have not done that, so you're constructing a strawman. > > At least one weakness has been identified -- namely, using a weaker > > encryption mode for the key-key blocks can reduce the strength of > > the entire system. Or to put it metaphorically, "an algorithm is only > > as strong as its weakest link." > > You really don't know what you're talking about, do you? Hey, you're the one who argued that it's 2^384 to break. Even PHK's own paper on GBDE puts the effort to break it at 2^129. Who is it that hasn't read the paper? http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf > > That's purely false. There are several other disk encryption > > systems around. > > You're right, IIRC PKZIP v1.10 had DES encryption back in 1990, someone > should have told PHK! :-P Please, get a clue, read PHK's papers. And yet more nonsense. PKZIP isn't even a disk encryption system. And you know very well that CGD and Loop-AES both predate GBDE. Claiming that there is "nothing like it" is objectively false. Now, if you'd care to stop making ad hominem attacks, perhaps there can be some useful discussion. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 19:23:42 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F388F16A4CE for ; Fri, 4 Mar 2005 19:23:41 +0000 (GMT) Received: from mail.shagadelic.org (isc-temp1.netbsd.org [204.152.190.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id A07CB43D41 for ; Fri, 4 Mar 2005 19:23:39 +0000 (GMT) (envelope-from thorpej@shagadelic.org) Received: from [17.221.46.63] (A17-221-46-63.apple.com [17.221.46.63]) by mail.shagadelic.org (Postfix) with ESMTP id D21C03CA27B; Fri, 4 Mar 2005 11:23:38 -0800 (PST) In-Reply-To: <200503030033.j230XG4G086979@marlena.vvi.at> References: <200503030033.j230XG4G086979@marlena.vvi.at> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Thorpe Date: Fri, 4 Mar 2005 11:23:36 -0800 To: "ALeine" X-Mailer: Apple Mail (2.619.2) X-Mailman-Approved-At: Sat, 05 Mar 2005 13:01:48 +0000 cc: elric@imrryr.org cc: tls@rek.tjls.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 19:23:42 -0000 On Mar 2, 2005, at 4:33 PM, ALeine wrote: > You need 2^128 steps to break the encryption of a single sector. > But you have no idea which of the 2^128 sectors is the right one, You may not know "for sure", but you can make a pretty well educated guess. You are basically ignoring Roland's argument that disks are well-structured. Start by looking for the MBR partition map / disklabel / GPT. Those are kept in well-known places, so you can greatly narrow your search space. Use the info contained therein to find likely superblock locations. Etc. You do not have to brute-force the entire disk. You just have to be smart about how you search. -- thorpej From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 19:29:16 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E767716A4CE for ; Fri, 4 Mar 2005 19:29:16 +0000 (GMT) Received: from snark.piermont.com (snark.piermont.com [166.84.151.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98CCB43D39 for ; Fri, 4 Mar 2005 19:29:15 +0000 (GMT) (envelope-from perry@piermont.com) Received: by snark.piermont.com (Postfix, from userid 1000) id 3D754D9877; Fri, 4 Mar 2005 14:29:14 -0500 (EST) To: "Poul-Henning Kamp" References: <17360.1109947952@critter.freebsd.dk> From: "Perry E. Metzger" Date: Fri, 04 Mar 2005 14:29:14 -0500 In-Reply-To: <17360.1109947952@critter.freebsd.dk> (Poul-Henning Kamp's message of "Fri, 04 Mar 2005 15:52:32 +0100") Message-ID: <87psyfgqgl.fsf@snark.piermont.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sat, 05 Mar 2005 13:01:48 +0000 cc: ALeine cc: tech-security@NetBSD.org cc: elric@imrryr.org cc: hackers@freebsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 19:29:17 -0000 "Poul-Henning Kamp" writes: > In message <877jknik4w.fsf@snark.piermont.com>, "Perry E. Metzger" writes: >>The best I can say, however, is that the US >>government has approved the use of AES with 256 bit keys for very >>highly secure communications, and they have a very demanding user >>community. > > (There is a big difference in what crypto you need for communications, > storage, and archiving.) In general, yes, but not in this context. In communications you need stuff like authentication that you don't always need in archiving. Anyway, the need for long term safety on a government top secret message is unlikely to be lower than the requirement in a storage context. That's because the adversary can store your message for 30 years just as you can. > My philosophy in this, (as implemented in GBDE), is to trust the > algorithms to do their job, but to not offer an attacker any more > leverage against them than I absolutely have to. In theory, that's a fine sentiment. The problem is that it is very hard to achieve that. > It has been said by various people that "there are [currently] > no cause to think that using the same key for many millions of > sectors is a problem". > > I belive that is a fair and balanced summary, and I trust the > people to know what they talk about and I belive them. > > Nontheless, I do not consider it good engineering to expose the > algorithm to unnecessary stress, even if we currently belive we > have a 220 bits margin of safety, if by trivial means, I can avoid > that stress on the algorithm and maintain 256 bits of margin. Let me phrase this in software engineering terms, but it applies also at the crypto layer. In theory, this is a nice idea, but imagine if, in the course of producing your "improved" version, you are actually increasing the risk because there is more code to audit and that code is more complex. (On the crypto side, the issue is that you're combining operations in complex ways that are hard to analyze. Even if you wish to do such a thing, you are in general better off doing it in a way that is designed to be easy to analyze. Often changes that are seemingly trivial to a layman make a big difference in what you can analyze in cryptography and cryptographic protocols.) > But in the case something unforeseen happens, I know that GBDE will > yield its secrets only one sector at a time and CGD will spill all > the eggs at once because it has only one basket. You have one basket too -- the master key. What if there's a nice time/memory tradeoff attack to locate it on your disk? At very best, I can gain a security factor of N this way, where N is the number of disk sectors. In truth, however, one can probably do much better if you're willing to spend some money. Then, of course, what if your algorithm for turning your master key into a sector key key isn't very good? That last bit is equivalent to the "key scheduling" problem you find in many cryptosystems -- and bad key-schedulers are notorious for causing serious trouble. You may think that you've increased the work factor, but perhaps you haven't. The literature is full of unfortunate instances of that. In any case, cracking AES-128 on every sector is pretty clearly cheaper than cracking AES-256 assuming AES is good. If AES is bad, well, your lock sector or attacking the whole disk are again possibilities. I suspect that the security you add by slowing down your crypto enough to do all the master keying you do is likely a lot smaller than simply moving to AES-256 would have given you. If AES isn't good enough for you, you can do stuff like triple-AES, but I think that's likely overkill. > As for making user selectable ciphers and keysizes I decided against > it for two reasons. > > The first reason is that it adds complexity. The code is easily verified though by using test vectors for standard algorithms. In any case, it is a lot simpler to do that than what you have done. You've added substantial complexity behind the scenes, much of which is hard to analyse. > The second is that it offers complexity. > > Adding complexity in the implementation is wrong for all the reasons > we all agree on. To justify that complexity, a benefit must be > proven. The benefit is straightforward -- the user can select their tradeoff between speed and security, and between simplicity in keying and added security from multi-factor keying, and the user can switch to a new algorithm if an old one proves wanting, without even having to compile a new kernel. > In all my interviews and talks with people, I found nobody who > wanted that level of flexibility. Everybody, almost in unison sang > from the "AES is the annointed king and 128 bit is the his key > size." hymn. Then why didn't you stick to AES-128 throughout? :) > The other complexity is for the user. The more questions the user > has to determine the correct answer to, the less likely he is to > get it all right if he is not a subject matter specialist. That's what friendly install software is for. You need not emasculate a system, however, for fear that an advanced user might want to turn knobs. You can simply make sure that the defaults are okay. > Finally, on keying schemes: I didn't put a keying scheme on GBDE > because I belive in the "tools not policies" dogma. The gbde(8) > userland program should be (but isn't quite) flexible enough to > support any keying scheme people decide to use. CGD is similar in that the kernel isn't doing all the flexible key management stuff -- that's userland. > PS: Will you be at BSDcan ? It would be a good chance to corner > a whiteboard and some beer. Possibly. If I am, see you there. -- Perry E. Metzger perry@piermont.com From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 23:32:02 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BECB16A4CE for ; Fri, 4 Mar 2005 23:32:02 +0000 (GMT) Received: from hiroshima.ihack.net (209-6-103-199.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.103.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7DE943D46 for ; Fri, 4 Mar 2005 23:32:01 +0000 (GMT) (envelope-from abuse@spamalicious.com) Received: by hiroshima.ihack.net (Postfix, from userid 27753) id B7CD62A65D3; Fri, 4 Mar 2005 23:31:30 +0000 (UTC) From: "Charles M. Hannum" Organization: By Noon Software, Inc. To: "ALeine" Date: Fri, 4 Mar 2005 23:31:30 +0000 User-Agent: KMail/1.7 References: <200503040317.j243HrZ2016007@marlena.vvi.at> In-Reply-To: <200503040317.j243HrZ2016007@marlena.vvi.at> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503042331.30560.abuse@spamalicious.com> X-Mailman-Approved-At: Sat, 05 Mar 2005 13:01:48 +0000 cc: elric@imrryr.org cc: briggs@netbsd.org cc: perry@piermont.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 23:32:02 -0000 On Friday 04 March 2005 03:17, ALeine wrote: > Your assumption is wrong. First of all, the first sector of the > encrypted image does not necessarily start at the beginning of > the disk, nor does the last sector have to be the last sector > of the disk. At initialization first_sector, last_sector and > total_sectors can be set so that the encrypted image is placed > at an offset from both sides of the disk. If you also use > random_flush that free space (padding) is filled with random > garbage automatically, so one cannot detect where the encrypted > image actually begins or ends. >... > You also have to take into acount the fact that there are at > least 4 512 byte lock sectors (regardless of the size of the > logical sector) which will thwart your automated brute forcing > attempt further. Lock sectors can be anywhere, their location is > picked randomly at initialization and everything else has to map > around them, so you cannot assume anything about their location > or know that you stumbled upon them. There are at least two ways to determine this information fairly easily: 1) If you're doing analysis of a cold disk, it is ~trivial to tell the difference between a sector that has been written only once and a sector that has been rewritten. 2) When used in a SAN environment, or an environment where multiple accesses to the drive can be done over time, it is possible to determine this fairly quickly using traffic analysis. The GBDE paper even touches on this in section 10.3. Have you read it? From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 4 19:58:14 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB47516A4CE for ; Fri, 4 Mar 2005 19:58:14 +0000 (GMT) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0552443D1D for ; Fri, 4 Mar 2005 19:58:14 +0000 (GMT) (envelope-from thomas.petazzoni@enix.org) Received: from [192.168.1.2] (humanoidz.org [82.237.107.242]) by postfix3-1.free.fr (Postfix) with ESMTP id 29B5F1734A9; Fri, 4 Mar 2005 20:58:13 +0100 (CET) Message-ID: <4228BDD4.2070302@enix.org> Date: Fri, 04 Mar 2005 20:58:12 +0100 From: Thomas Petazzoni User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: fr, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 05 Mar 2005 13:04:51 +0000 cc: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Subject: Libre Software Meeting 2005 : Call for contributions X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 19:58:15 -0000 CALL FOR CONTRIBUTIONS Libre Software Meeting 2005 --------------------------------------- Operating system design and implementation The Libre Software Meeting (LSM) has been one of the most important Free Software events in France since the year 2000 [0]. This year, the meeting will take place from July 5th to July 9th in Dijon, to the East of France. The Libre Software Meeting aims at allowing designers and developers of free software projects [1] from different places to meed and and share their ideas and experiences. LSM is also an opportunity to discuss societal issues. Technical conferences cover a wide range of topics, from high-level programming languages to databases, through security concerns. The "operating system design and development" topic is looking for speakers to present free software projects. Technical topics include (but are not limited to): * design and implementation of operating systems: architecture, services, libraries, use of high-level languages and advanced programming techniques such as AOP, dynamic reconfiguration, etc.; * kernel subsystems: schedulers, I/O schedulers, virtual memory management, etc.; * filesystem implementation: journalized, distributed filesystems, etc.; * realtime extensions to free operating systems; * virtualization tools (i.e. Xen, User-Mode-Linux, etc.); * kernel development tools : debuggers, performance evaluation, etc.; * distributed operating systems; * embedded systems development. Programs of previous years are available online [2]. The program for 2005 is being defined and a tentative program is available online [3]. There is no programme committee (it is not a scientific conference) and selection process is expected to remain as lightweight as possible. Volunteers should contact Thomas Petazzoni and Ludovic Court=E8s by June 2005. Speakers are encouraged to write a small paper (6 to 12 A4 sheets) summarizing their presentation (in an open format such as PostScript or PDF). Ludovic Court=E8s and Thomas Petazzoni. [0] http://lsm2000.abul.org , http://lsm2001.abul.org , http://lsm2002.abul.org , http://lsm2003.abul.org , http://lsm2004.abul.org . [1] http://www.gnu.org/philosophy/free-sw.html [2] http://wiki.ael.be/rmll2003/index.php/ThemeOperatingSystem , http://lsm2002.abul.org/program/topic06/topic06.php3 , http://lsm2000.abul.org/program/topic06_en.html . [3] http://www.rencontresmondiales.org/sections/conference/noyau_et_syste= me --=20 PETAZZONI Thomas - thomas.petazzoni@enix.org http://thomas.enix.org - Jabber: thomas.petazzoni@jabber.dk KOS: http://kos.enix.org/ - SOS: http://sos.enix.org Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E 1624 F653 CB30 98D3 F7A7 From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 14:38:40 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62CBD16A4CE; Sat, 5 Mar 2005 14:38:40 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CF5343D39; Sat, 5 Mar 2005 14:38:39 +0000 (GMT) (envelope-from des@des.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0ICV0032FV2GKC80@bgo1smout1.broadpark.no>; Sat, 05 Mar 2005 15:32:40 +0100 (CET) Received: from dsa.des.no ([80.203.228.37]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0ICV00E7SVERG9G0@bgo1sminn1.broadpark.no>; Sat, 05 Mar 2005 15:40:03 +0100 (CET) Received: by dsa.des.no (Pony Express, from userid 666) id F3EA445194; Sat, 05 Mar 2005 15:38:02 +0100 (CET) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 2726A45190; Sat, 05 Mar 2005 15:38:00 +0100 (CET) Received: by xps.des.no (Postfix, from userid 1001) id 09C3F33C5A; Sat, 05 Mar 2005 15:38:00 +0100 (CET) Date: Sat, 05 Mar 2005 15:37:59 +0100 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <20050304020340.GU73981@wantadilla.lemis.com> To: Greg 'groggy' Lehey Message-id: <86ekeuyx88.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <20050304013622.GS73981@wantadilla.lemis.com> <20050304014035.GA20301@odin.ac.hmc.edu> <20050304020340.GU73981@wantadilla.lemis.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: cc: FreeBSD Hackers Subject: Re: Setting maximum data size X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 14:38:40 -0000 Greg 'groggy' Lehey writes: > Some values can be specified like this: > > hw.physmem=3D"1G" # Limit physical memory. See loader(8) > > That doesn't seem to work for MAXDSIZ. I have a patch for this which will go in as soon as I'm done testing it. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 14:51:03 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B925516A4CE for ; Sat, 5 Mar 2005 14:51:03 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 717CF43D2D for ; Sat, 5 Mar 2005 14:51:03 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j24Iu0oH032916; Fri, 4 Mar 2005 10:56:02 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j24Itmfa032915; Fri, 4 Mar 2005 10:55:48 -0800 (PST) (envelope-from www) Date: Fri, 4 Mar 2005 10:55:48 -0800 (PST) Message-Id: <200503041855.j24Itmfa032915@marlena.vvi.at> To: abuse@spamalicious.com From: "ALeine" cc: elric@imrryr.org cc: briggs@netbsd.org cc: perry@piermont.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@netbsd.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 14:51:03 -0000 abuse@spamalicious.com wrote: > There are at least two ways to determine this information fairly easily: As easily as one can get accepted into the crypto community? :-> > 1) If you're doing analysis of a cold disk, it is ~trivial to tell > the difference between a sector that has been written only once and > a sector that has been rewritten. This is hardly trivial, you are basing your statement on the false assumption that one cannot or will not do anything to protect the encrypted image after the initialization. One can do a lot. For example, one can regularly scrub the unused areas around the encrypted image (padding) with dd(1) using if=/dev/{u,}random and similar. This can be fully automated with a cron job. One can also regularly scatter files with misleading names and contents. These files would be of various sizes, some would be filled with random garbage and others would be specially constructed as to cause a false negative upon possible decryption by brute force or other means. This is easy to implement and very effective, for example, you can use this approach to encrypt a file full of random garbage with the same algorithm as the underlying mechanism (AES 128 in this case). You could also construct a file containing fake metadata and fragments (even from other filesystems like EXT2 etc.), which would send an attacker on a wild goose chase if they were to somehow manage to decrypt part of the contents of such a file. Such a fake metadata file would have to be padded to the appropriate length with other valid-looking data in such a way that it would be contained entirely in a single zone, otherwise it would expose the remaining sectors is the zone. Perhaps GBDE could be extended to make such a thwarting subterfuging mechanism possible through means of a utility which would guarantee the exclusive placement of a file in a separate zone (or zones if it were bigger than a single zone, of course). It could be called gezcp or something like that. Poul-Henning, what do you think of this feature? :-) One could then have a cron job periodically (say, every 5 minutes) launch a script which would scatter the misleading files in specified locations, always making sure not to use more than the specified amount of disk space. These files would be recycled, of course, with older ones being randomly replaced by new ones. This would be fully automated and would introduce a good level of dispersion of misleading contents and regular data written to the disk by the user(s). It would also obscure access and write patterns to the point of making this attack vector very unattractive. > 2) When used in a SAN environment, or an environment where > multiple accesses to the drive can be done over time, it is > possible to determine this fairly quickly using traffic analysis. > The GBDE paper even touches on this in section 10.3. Have you > read it? First of all, protection against traffic analysis on a SAN is in the territory of hot disk protection and GBDE, as you must have surely read, is designed for cold disk protection. SANs are by definition high availability environments and as such have high volume traffic, so if you have someone who has access to be able to monitor that traffic and can also analyze such high volumes of traffic and can also clone your entire SAN storage devices unnoticed without causing a service disruption then you have much bigger problems, so worrying about GBDE should be the least of your concerns. :-) Second of all, the cleaning lady copy attack (described in section 10.3), where someone can regularly make bit-wise copies of the entire disk containing the encrypted image and determine the location of sensitive structures by means of differential analysis is not very practical. If someone has that kind of access to your computer then they are more likely to use a hardware keylogger and intercept the passphrase. You can get such keyloggers for less than $100, take a look at Key Katcher, for example: http://www.thinkgeek.com/gadgets/electronic/5a05/an Also, the journaling mechanism I mentioned in my previous posts combined with the thwarting and subterfuging approaches I described above would make any kind of differential analysis very difficult and no longer practical. Who is clutching at straws now? :-> ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 15:48:23 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C21216A4CE for ; Sat, 5 Mar 2005 15:48:23 +0000 (GMT) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD60343D41 for ; Sat, 5 Mar 2005 15:48:20 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0)j25FpbK9058465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Mar 2005 17:51:38 +0200 (EET) Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id 2B93FF2; Sat, 5 Mar 2005 17:48:01 +0200 (EET) Date: Sat, 5 Mar 2005 17:48:01 +0200 From: Andrey Simonenko To: Andriy Tkachuk Message-ID: <20050305154800.GA468@pm514-9.comsys.ntu-kpi.kiev.ua> References: <000401c520d5$a6b6ae00$090210ac@BORJA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401c520d5$a6b6ae00$090210ac@BORJA> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.82/737/Tue Mar 1 08:22:18 2005 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean cc: freebsd-hackers@freebsd.org Subject: Re: sched_ule, runqueues, priority, and O(1) sheduling question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 15:48:23 -0000 On Fri, Mar 04, 2005 at 09:45:56PM +0530, Andriy Tkachuk wrote: > Hi folks. > > I wander how O(1) sheduling works in ULE. > In ule.pdf Jeff wrote: > > Threads are picked from the current queue in > priority order until the current queue is empty. > > As far as I understand the algorithm is O(n) > where n - number of READY TO RUN processes, > not all processes isn't it? As I understood, algorithm is O(1). Everything said below is only my point of view, please correct me if I'm wrong. All threads which are kept in the current queue, are really not kept in one physical queue. They are kept in several queues, number of this queues is less than number of priorities, so several priorities are indistinguishable in the queue. To find a thread with higher priority first non-empty queue should be find. There is a bitmap for all queues and each bit in this bitmap says if queue is empty or not. To find first nonzero bit special machine-dependent instruction is used (for x86 this is bsf), if a machine word is not enough to keep all bits, then several words are used. When first non-empty queue (that is queue with maximum priority) was found, everything what is needed, is removing first (last) thread from this queue. If the queue became empty its bit in the bitmap of all queue is cleared and it is set again if the queue becomes non-empty. Details: kern/sched_ule.c struct kseq{}, check what is ksq_next and what is ksq_curr sys/runq.h check comments in this file kern/kern_switch.c check runq_*() functions and runq_findbit(). Follow this path: mi_switch() -> sched_ule.c:sched_switch() -> choosethread() -> shced_ule.c:shced_choose() -> kseq_choose() -> runq_choose() kseq_runq_rem() -> runq_remove() From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 16:40:56 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B6EC16A4CE for ; Sat, 5 Mar 2005 16:40:56 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C15943D5A for ; Sat, 5 Mar 2005 16:40:54 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j24KjeoH034410; Fri, 4 Mar 2005 12:45:52 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j24KjMDe034408; Fri, 4 Mar 2005 12:45:22 -0800 (PST) (envelope-from www) Date: Fri, 4 Mar 2005 12:45:22 -0800 (PST) Message-Id: <200503042045.j24KjMDe034408@marlena.vvi.at> To: elric@imrryr.org From: "ALeine" cc: tech-security@netbsd.org cc: phk@phk.freebsd.dk cc: hackers@freebsd.org Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 16:40:56 -0000 Someone from the NetBSD community who wishes to remain unnamed sent me the following email, so I thought I would comment on it here because there seem to be many others who are confused about the same issue. > My thinking is that for each of 2^30 sectors, you're looking for > one of 2^128 keys. So for sector 0, 2^128 keys. For sector 1, > 2^128 keys. For sector 2, 2^128 keys. That 3 sectors and 3 * 2^128 > keys. 2^30 sectors: 2^30 * 2^128 keys, 2^(30+128) = 2^158. That assumption is wrong, sectors are not completely independent data, they are connected in such a way that if you want the entire disk, you want the right variation of all the keys for all of the sectors on that disk. In a 128 bit key, each bit can be either 0 or 1. How many key variations exist? The number of possible values a bit can have to the power of the number of bits in the key (key length in bits), which is: 2^128 Now, on a disk consisting of 2^30 sectors, each sector can be encrypted with one of 2^128 possible keys. How many disk variations exist? The number of possible keys for a single sector to the power of the number of sectors in a disk (disk size in sectors), which is: (2^128)^(2^30) = 2^(128*2^30) = 2^(2^37) = 2^137438953472 Let me give you an example. Let's say you are looking for an English 3 letter word. The English alphabet has 26 letters, so if you were to try to guess that word by brute forcing it, how many attempts would it take to try all the variations? The following perl script will answer that question by enumerating and listing all the variations. As you can see there are 17576 (26^3) and not 78 (3*26) variations, as some falsely believe. The same can be applied to sectors. You could argue that once you assume you have the right letter you might be able to guess another letter because the number of valid three letters words is a known subset of all the variations and because you know that the entropy of the English language is low (around 2.1 bits/letter), but even when you take those facts and apply them to sectors you will see that it would take much more than 2^158 steps to brute force GBDE because although the sectors are structured and you could guess a lot, the data entropy is not zero. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 17:23:45 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 103C416A4CE for ; Sat, 5 Mar 2005 17:23:45 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id A84DB43D46 for ; Sat, 5 Mar 2005 17:23:44 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j24LSXoH035278; Fri, 4 Mar 2005 13:28:35 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j24LSH4d035277; Fri, 4 Mar 2005 13:28:17 -0800 (PST) (envelope-from www) Date: Fri, 4 Mar 2005 13:28:17 -0800 (PST) Message-Id: <200503042128.j24LSH4d035277@marlena.vvi.at> To: smb@cs.columbia.edu From: "ALeine" cc: elric@imrryr.org cc: abuse@spamalicious.com cc: briggs@NetBSD.org cc: perry@piermont.com cc: phk@phk.freebsd.dk cc: hackers@freebsd.org cc: tech-security@NetBSD.org cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 17:23:45 -0000 smb@cs.columbia.edu wrote: > >For example, one can regularly scrub the unused areas around the > >encrypted image (padding) with dd(1) using if=/dev/{u,}random and > >similar. This can be fully automated with a cron job. > > > >One can also regularly scatter files with misleading names and > > contents. > > etc. I think we need to be careful about phrases like "one can". I was not assuming one would and I never implied that one should, if you read my previous posts you probably noticed that all the changes to GBDE I proposed were to be implemented in a way that would let the user decide what they wanted. I was only stating what could be done, in the end the user is the one who decides what they want, but if they are aware of those threats they can do a lot about them - if they choose to. One can also choose not to use encryption at all. > I decided to stop supposing and gather some real data, so I wrote some > analysis tools to measure the entropy of disk drives. I need to > rewrite some of my tools and do a lot more analysis, but I think the > results thus far are quite interesting. See > http://www.cs.columbia.edu/~smb/rawdisk-entropy.ps That seems very interesting, I will take a look! :-) We both posted at about the same time talking about data entropy. Well, given the topic that could hardly be considered a coincidence. :-)) Could you make the tools you used publically available? I would very much like to run that kind of analysis on my disks, especially now that I'm planning the implementation of the GBDE changes I proposed. It would also be interesting to see the statistics from others, perhaps someone would be willing to put up some kind of web site so people could submit their results into a database. > Anyway -- the moral of the story is that you really need to analyze > your environment and your threat model when designing crypto. The > answer to SAN link eavesdropping might be IPsec or link encryptors; the > answer to cleaning lady attacks might be cleared personnel, two party > rules, or other non-crypto solutions. But don't assume, and don't say > "one can" or "one should". (As a footnote, I realized that my own cgd > "partition" (via vnd) was created from /dev/zero instead of /dev/urandom; > the result is that the entropy of the file itself reveals almost > exactly how much of the cgd partition is in use. I'll have to correct > that....) I agree with you on the first part and about assuming, but I disagree about the "one can" part. Saying that one can do something does not imply that one should or that one would do that, it only implies that an option exists. So you falsely assumed that I assumed when I was in fact only addressing the other poster's false assumption that users would do nothing. :-> They might do nothing, but they can do a lot if they choose to. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net