From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 00:16:35 2003 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 7E51616A4CE; Sun, 23 Nov 2003 00:16:35 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FA9D43FAF; Sun, 23 Nov 2003 00:16:34 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 527795B648; Sun, 23 Nov 2003 00:15:16 -0800 (PST) From: Wes Peters Organization: Softweyr To: Stefan =?iso-8859-1?q?E=DFer?= Date: Sun, 23 Nov 2003 00:16:31 -0800 User-Agent: KMail/1.5.4 References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311211333.39520.wes@softweyr.com> <20031121235607.GB16700@StefanEsser.FreeBSD.org> In-Reply-To: <20031121235607.GB16700@StefanEsser.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200311230016.31498.wes@softweyr.com> cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 23 Nov 2003 08:16:35 -0000 On Friday 21 November 2003 03:56 pm, Stefan E=DFer wrote: > On 2003-11-21 14:09 -0800, Wes Peters wrote: > > As for performance, you really need to flush the on-device cache on > > each pass to make sure the bit patterns get written to the platter in > > proper order. I don't see any clever way to coalesce the writing of > > the various patterns to multiple blocks short of a kernel thread, > > either, so performance would be abysmal. Imagine removing a large > > file, overwriting each block in 37 (IIRC) passes, syncing all the way > > through the on-disk cache after *every block.* > > I may be way off, but I do not think, that a special thread or > a cache flush after each block is required: > > A simple algorithm could just mark each buffer with a special > kind of dirty flag and a counter for the pass number (in fact, > the existing dirty flag could be used, and a counter set to the > number of passes required, with 0 indicating that the buffer is > to be flushed to disk "as is" in the normal way). Oh, but you're wrong, if you actually want to ERASE the data on the disk=20 platters. That's why I've referred people to the obliterate program in=20 ports several times. Read the references contained there, then come back=20 to this discussion. If you just want to zero the blocks, that is a lot easier, but you're not=20 really protecting anything from anyone who can get their hands on the=20 disk. =2D-=20 Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 00:19:13 2003 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 D2E1816A4CF; Sun, 23 Nov 2003 00:19:13 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1277143FBF; Sun, 23 Nov 2003 00:19:13 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 3A3B672DC7; Sun, 23 Nov 2003 00:17:55 -0800 (PST) From: Wes Peters Organization: Softweyr To: Stefan =?iso-8859-1?q?E=DFer?= , Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= Date: Sun, 23 Nov 2003 00:19:11 -0800 User-Agent: KMail/1.5.4 References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <20031122105400.GA4506@StefanEsser.FreeBSD.org> In-Reply-To: <20031122105400.GA4506@StefanEsser.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200311230019.11310.wes@softweyr.com> cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 23 Nov 2003 08:19:13 -0000 On Saturday 22 November 2003 02:54 am, Stefan E=DFer wrote: > On 2003-11-22 11:04 +0100, Dag-Erling Sm=F8rgrav wrote: > > Stefan E=DFer writes: > > > I may be way off, but I do not think, that a special thread or > > > a cache flush after each block is required: [...] > > > > What happens if you yank the power cord? > > Worst case: The same thing that happened, if the you lost power > a fraction of a second earlier, just before the unlink or loss > of last reference to the file ... > > Nothing short of a self-destruct mechanism will do any better ;-) Poppycock. Encrypting the data before it hits the disk is a fine=20 protection against somebody later recovering the data, either=20 inadvertantly or nefariously. > Back to the subject of this thread: > > You could write a special flag "needs to be securely removed" to > the inode. That way, an interrupted overwrite process could be > continued after next reboot (for example initiated by fsck). But why would somebody trying to steal your data run fsck on it? You're=20 not thinking paranoid enough. =2D-=20 Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 04:15:12 2003 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 76B0016A4CF; Sun, 23 Nov 2003 04:15:12 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8553243F75; Sun, 23 Nov 2003 04:15:10 -0800 (PST) (envelope-from se@freebsd.org) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng8.kundenserver.de with esmtp (Exim 3.35 #1) id 1ANt8q-0005jk-00; Sun, 23 Nov 2003 13:15:04 +0100 Received: from [80.132.236.72] (helo=Gatekeeper.FreeBSD.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1ANt8q-0005S0-00; Sun, 23 Nov 2003 13:15:04 +0100 Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 75D675F18; Sun, 23 Nov 2003 13:15:02 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id 21AD41F18; Sun, 23 Nov 2003 13:15:02 +0100 (CET) Date: Sun, 23 Nov 2003 13:15:01 +0100 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Wes Peters Message-ID: <20031123121501.GA1133@StefanEsser.FreeBSD.org> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311211333.39520.wes@softweyr.com> <20031121235607.GB16700@StefanEsser.FreeBSD.org> <200311230016.31498.wes@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200311230016.31498.wes@softweyr.com> User-Agent: Mutt/1.5.5.1i Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fa3fae9b6ca38d745862a668565919f6 cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 23 Nov 2003 12:15:12 -0000 On 2003-11-23 00:16 -0800, Wes Peters wrote: > On Friday 21 November 2003 03:56 pm, Stefan E=DFer wrote: > > A simple algorithm could just mark each buffer with a special > > kind of dirty flag and a counter for the pass number (in fact, > > the existing dirty flag could be used, and a counter set to the > > number of passes required, with 0 indicating that the buffer is > > to be flushed to disk "as is" in the normal way). >=20 > Oh, but you're wrong, if you actually want to ERASE the data on the dis= k=20 > platters. That's why I've referred people to the obliterate program in= =20 > ports several times. Read the references contained there, then come ba= ck=20 > to this discussion. This is rude! It's been some time since I read the Gutmann paper, but I still remember=20 the points he made and even quite a number of the details. Either my (English) language skills are insufficient to make my point,=20 or you just didn't read what I wrote. I thought it was obvious that=20 if I'm talking of several passes, that each one writes specific data=20 (either a complement of the original data, a suitable pattern or random=20 data).=20 What I'm suggesting is to have the obliteration implemented as an add on to the dirty buffer flush, with the difference that the=20 buffer contents is prepared for the next step of the erasure process, written out, and then not declared free but again prepared for the next overwrite pass. A counter is required to keep the required state information for each individual buffer. AFAIK, there is no=20 need to retain original data (or its complement) for the process, so in fact all that is needed is a pass counter and the very simple FA. There is no need for a special thread, and that was the point I was trying to make. Takling of obliterate: There is the patterns[] array and the "passno" variable attached to a buffer could select one of those patterns on each pass of the elevator. (Well, may be a seperate thread might be better to prepare buffers by filling in the correct patterns at slightly=20 reduced priority ...) > If you just want to zero the blocks, that is a lot easier, but you're n= ot=20 > really protecting anything from anyone who can get their hands on the=20 > disk. Who is talking about just zeroing blocks ? Please take the time to actually read the messages you reply to ... Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 04:46:28 2003 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 9428616A4CE; Sun, 23 Nov 2003 04:46:28 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B96A43FA3; Sun, 23 Nov 2003 04:46:25 -0800 (PST) (envelope-from se@freebsd.org) Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng4.kundenserver.de with esmtp (Exim 3.35 #1) id 1ANtd9-0004sV-00; Sun, 23 Nov 2003 13:46:23 +0100 Received: from [80.132.236.72] (helo=Gatekeeper.FreeBSD.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1ANtd9-0008Bi-00; Sun, 23 Nov 2003 13:46:23 +0100 Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 537325F18; Sun, 23 Nov 2003 13:46:21 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id 06F931F18; Sun, 23 Nov 2003 13:46:21 +0100 (CET) Date: Sun, 23 Nov 2003 13:46:20 +0100 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Wes Peters Message-ID: <20031123124620.GB1133@StefanEsser.FreeBSD.org> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <20031122105400.GA4506@StefanEsser.FreeBSD.org> <200311230019.11310.wes@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200311230019.11310.wes@softweyr.com> User-Agent: Mutt/1.5.5.1i Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fa3fae9b6ca38d745862a668565919f6 cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 23 Nov 2003 12:46:28 -0000 On 2003-11-23 00:19 -0800, Wes Peters wrote: > On Saturday 22 November 2003 02:54 am, Stefan E=DFer wrote: > > On 2003-11-22 11:04 +0100, Dag-Erling Sm=F8rgrav wrote: > > > Stefan E=DFer writes: > > > > I may be way off, but I do not think, that a special thread or > > > > a cache flush after each block is required: [...] > > > > > > What happens if you yank the power cord? > > > > Worst case: The same thing that happened, if the you lost power > > a fraction of a second earlier, just before the unlink or loss > > of last reference to the file ... > > > > Nothing short of a self-destruct mechanism will do any better ;-) >=20 > Poppycock. Encrypting the data before it hits the disk is a fine=20 > protection against somebody later recovering the data, either=20 > inadvertantly or nefariously. Aren't we again unneccessarily rude here ? Encrypting data and secure removal of data are orthogonal and in case you need one, the other propbably won't be a good choice. In doubt, I'd use encyption at the disk block level to protect sensitive=20 data, but that's not the topic of this thread, IIRC. The subject was to get rid of remnants of data (whether encrypted or not) from some magnetic media (and similar methods might be suitable for flash media with different patterns and a smaller number of passes). > Back to the subject of this thread: > > > > You could write a special flag "needs to be securely removed" to > > the inode. That way, an interrupted overwrite process could be > > continued after next reboot (for example initiated by fsck). >=20 > But why would somebody trying to steal your data run fsck on it? You'r= e=20 > not thinking paranoid enough. Sorry, but what are you talking about ? fsck could identify incompletely erased (in the sense of multipass overwrite with specific patterns) blocks, if that state was marked in=20 the inode. This is not meant as protection in case power is removed and the disk=20 is analyzed off-line since most probably no fsck will ever be run over=20 the filesystem again. It is meant to protect against a power failure (or reboot) with data not being erased according to the specification, which might survive for a long time after next start (not by an attacker but in normal=20 service). This is extra paranoia (compare to a crash while "obliterate" is overwriting blocks, which will not be restarted after a crash ...) It seems that you are opposed to having "secure erase" support in the kernel, and in fact, I'm not sure it is that useful, myself. But in case it is considered useful and implemented (I'd try it myself, if I was interested in using this feature), then we should discuss the techical (and security) aspects of several designs and that's what I'm trying to do. Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 08:31:49 2003 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 4AA4A16A4CE; Sun, 23 Nov 2003 08:31:49 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97BFA43FA3; Sun, 23 Nov 2003 08:31:45 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 4F1B35309; Sun, 23 Nov 2003 17:31:44 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 361565308; Sun, 23 Nov 2003 17:31:36 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id BAC0133C86; Sun, 23 Nov 2003 17:31:35 +0100 (CET) To: Stefan =?iso-8859-1?q?E=DFer?= References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311211333.39520.wes@softweyr.com> <20031121235607.GB16700@StefanEsser.FreeBSD.org> <200311230016.31498.wes@softweyr.com> <20031123121501.GA1133@StefanEsser.FreeBSD.org> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sun, 23 Nov 2003 17:31:35 +0100 In-Reply-To: <20031123121501.GA1133@StefanEsser.FreeBSD.org> (Stefan =?iso-8859-1?q?E=DFer's?= message of "Sun, 23 Nov 2003 13:15:01 +0100") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: ss X-Spam-Status: No, hits=2.5 required=5.0 tests=RCVD_IN_DYNABLOCK autolearn=no version=2.60 cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 23 Nov 2003 16:31:49 -0000 Stefan E=DFer writes: > What I'm suggesting is to have the obliteration implemented as an > add on to the dirty buffer flush, with the difference that the=20 > buffer contents is prepared for the next step of the erasure process, > written out, and then not declared free but again prepared for the > next overwrite pass. This next pass won't be until thirty seconds later, so it'll take about half an hour to completely obliterate a file. Furthermore, unmounting a file system less than half an hour after a file is deleted or truncated will fail, and shutting down will most likely leave the file system unclean due to repeated failures to flush the dirty buffer list. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 09:04:43 2003 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 D9EF816A4CE; Sun, 23 Nov 2003 09:04:43 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D1AF43FDF; Sun, 23 Nov 2003 09:04:42 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id hANH4ZDx008800; Sun, 23 Nov 2003 18:04:35 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 23 Nov 2003 17:31:35 +0100." Date: Sun, 23 Nov 2003 18:04:35 +0100 Message-ID: <8799.1069607075@critter.freebsd.dk> cc: Stefan =?iso-8859-1?q?E=DFer?= cc: freebsd-hackers@FreeBSD.org cc: Rayson Ho Subject: Re: "secure" file flag? 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, 23 Nov 2003 17:04:44 -0000 1. Look for BIO_DELETE in the kernel. 2. Use GBDE or other encryption. 3. Stop bikeshed now, 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 Sun Nov 23 09:50:35 2003 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 EF39216A4CE; Sun, 23 Nov 2003 09:50:34 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB54B43F93; Sun, 23 Nov 2003 09:50:33 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 22EC35B650; Sun, 23 Nov 2003 09:49:13 -0800 (PST) From: Wes Peters Organization: Softweyr To: Stefan =?iso-8859-1?q?E=DFer?= Date: Sun, 23 Nov 2003 09:50:32 -0800 User-Agent: KMail/1.5.4 References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311230016.31498.wes@softweyr.com> <20031123121501.GA1133@StefanEsser.FreeBSD.org> In-Reply-To: <20031123121501.GA1133@StefanEsser.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200311230950.32243.wes@softweyr.com> cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 23 Nov 2003 17:50:35 -0000 On Sunday 23 November 2003 04:15 am, Stefan E=DFer wrote: > On 2003-11-23 00:16 -0800, Wes Peters wrote: > > On Friday 21 November 2003 03:56 pm, Stefan E=DFer wrote: > > > A simple algorithm could just mark each buffer with a special > > > kind of dirty flag and a counter for the pass number (in fact, > > > the existing dirty flag could be used, and a counter set to the > > > number of passes required, with 0 indicating that the buffer is > > > to be flushed to disk "as is" in the normal way). > > > > Oh, but you're wrong, if you actually want to ERASE the data on the > > disk platters. That's why I've referred people to the obliterate > > program in ports several times. Read the references contained there, > > then come back to this discussion. > > This is rude! > > It's been some time since I read the Gutmann paper, but I still > remember the points he made and even quite a number of the details. > > Either my (English) language skills are insufficient to make my point, > or you just didn't read what I wrote. I thought it was obvious that > if I'm talking of several passes, that each one writes specific data > (either a complement of the original data, a suitable pattern or random > data). I'm sorry, I must've cut out the part where you wrote that it isn't=20 necessary to flush the data through the drive cache. It is, because the=20 patterns have to be applied in order and may not work if applied out of=20 order. Therefore, you have to flush the data from the drives own cache=20 onto the platters after you have applied each pattern. You can optimize this by moving the solution to a different layer or=20 implementing a kernel thread, but the drive cache sync does need to be=20 done. > What I'm suggesting is to have the obliteration implemented as an > add on to the dirty buffer flush, with the difference that the > buffer contents is prepared for the next step of the erasure process, > written out, and then not declared free but again prepared for the > next overwrite pass. A counter is required to keep the required > state information for each individual buffer. AFAIK, there is no > need to retain original data (or its complement) for the process, > so in fact all that is needed is a pass counter and the very simple > FA. There is no need for a special thread, and that was the point > I was trying to make. Yes, I see. For each block, you store the index of the next pattern to be= =20 written as each current pattern > Takling of obliterate: There is the patterns[] array and the "passno" > variable attached to a buffer could select one of those patterns on > each pass of the elevator. (Well, may be a seperate thread might be > better to prepare buffers by filling in the correct patterns at > slightly reduced priority ...) This would probably be an optimal solution. Given the difference between CPU performance and disk I/O speed, I've come= =20 to the conclusion disk encryption is probably a lower-cost solution. The=20 big problem with disk encryption is the question "where do I get the keys=20 from." =2D-=20 Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 10:11:36 2003 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 9DF4616A4CE; Sun, 23 Nov 2003 10:11:36 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 842D743F75; Sun, 23 Nov 2003 10:11:35 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 303435B69B; Sun, 23 Nov 2003 10:10:13 -0800 (PST) From: Wes Peters Organization: Softweyr To: Stefan =?iso-8859-1?q?E=DFer?= Date: Sun, 23 Nov 2003 10:11:32 -0800 User-Agent: KMail/1.5.4 References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311230019.11310.wes@softweyr.com> <20031123124620.GB1133@StefanEsser.FreeBSD.org> In-Reply-To: <20031123124620.GB1133@StefanEsser.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200311231011.32965.wes@softweyr.com> cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 23 Nov 2003 18:11:36 -0000 On Sunday 23 November 2003 04:46 am, Stefan E=DFer wrote: > On 2003-11-23 00:19 -0800, Wes Peters wrote: > > On Saturday 22 November 2003 02:54 am, Stefan E=DFer wrote: > > > On 2003-11-22 11:04 +0100, Dag-Erling Sm=F8rgrav wrote: > > > > Stefan E=DFer writes: > > > > > I may be way off, but I do not think, that a special thread or > > > > > a cache flush after each block is required: [...] > > > > > > > > What happens if you yank the power cord? > > > > > > Worst case: The same thing that happened, if the you lost power > > > a fraction of a second earlier, just before the unlink or loss > > > of last reference to the file ... > > > > > > Nothing short of a self-destruct mechanism will do any better ;-) > > > > Poppycock. Encrypting the data before it hits the disk is a fine > > protection against somebody later recovering the data, either > > inadvertantly or nefariously. > > Aren't we again unneccessarily rude here ? > > Encrypting data and secure removal of data are orthogonal and in case > you need one, the other propbably won't be a good choice. Both are completely adequate to protect the data on the disk from=20 disclosure. > In doubt, I'd use encyption at the disk block level to protect > sensitive data, but that's not the topic of this thread, IIRC. > > The subject was to get rid of remnants of data (whether encrypted or > not) from some magnetic media (and similar methods might be suitable > for flash media with different patterns and a smaller number of > passes). > > > Back to the subject of this thread: > > > You could write a special flag "needs to be securely removed" to > > > the inode. That way, an interrupted overwrite process could be > > > continued after next reboot (for example initiated by fsck). > > > > But why would somebody trying to steal your data run fsck on it?=20 > > You're not thinking paranoid enough. > > Sorry, but what are you talking about ? > > fsck could identify incompletely erased (in the sense of multipass > overwrite with specific patterns) blocks, if that state was marked in > the inode. But if someone is attempting to recover your deleted data, they're not=20 going to run tools that would potentially eliminate that data from the=20 disk. I'm designing to the idea of a disk that has been physically taken=20 to a data recovery lab, because the intermediate steps don't interest me. = =20 But you see that: > This is not meant as protection in case power is removed and the disk > is analyzed off-line since most probably no fsck will ever be run over > the filesystem again. The data needs to be overwritten in a timely manner as well. Leaving the=20 disk in a partly erased state is the same as leaving it unerased. If you=20 don't want the processing delay needed to do the full erasure you=20 obviously don't really need full erasure. > It is meant to protect against a power failure (or reboot) with data > not being erased according to the specification, which might survive > for a long time after next start (not by an attacker but in normal > service). This is extra paranoia (compare to a crash while "obliterate" > is overwriting blocks, which will not be restarted after a crash ...) > > It seems that you are opposed to having "secure erase" support in the > kernel, and in fact, I'm not sure it is that useful, myself. No, at one time I had it on my todo list, but came to a more full=20 understanding of the expense and abadoned it for that reason. I may=20 someday do it in the simplest form just to prove it workable to myself,=20 but I doubt that is a solution of general interest to FreeBSD. > But in case it is considered useful and implemented (I'd try it myself, > if I was interested in using this feature), then we should discuss the > techical (and security) aspects of several designs and that's what I'm > trying to do. There is some merit in providing a mechanism that is 90% as secure at 10%=20 the computational cost. I basic infrastructure that provides a "secure=20 removal" flag at the file and/or filesystem layer and a choice of=20 patterns would be a nice solution. Those who just want to make sure the=20 contents of an email aren't inadvertantly disclosed to another user could=20 specify a simple pattern like overwrite with zeros once, those who want=20 to keep the FBI at bay could use the whole 37 passes and spend days=20 deleting files. Maybe I'll look into this again after all. The former=20 variant seems like it might even be useful for a mail server or similar=20 application. Have you seen any literature on secure overwrite patterns for flash? That= =20 would be an interesting option to provide. If nothing else, I'd like to=20 hack something like that into obliterate. =2D-=20 Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 13:03:57 2003 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 C17FD16A4CE for ; Sun, 23 Nov 2003 13:03:57 -0800 (PST) Received: from venus.vincentjardin.net (AVelizy-102-1-2-102.w217-128.abo.wanadoo.fr [217.128.206.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A7F643FBF for ; Sun, 23 Nov 2003 13:03:56 -0800 (PST) (envelope-from jardin@venus.vincentjardin.net) Received: from venus.vincentjardin.net (localhost [127.0.0.1]) hANL5rZM007954 for ; Sun, 23 Nov 2003 22:05:53 +0100 (CET) (envelope-from jardin@venus.vincentjardin.net) Received: from localhost (localhost [[UNIX: localhost]]) by venus.vincentjardin.net (8.12.9/8.12.9/Submit) id hANL5q6c007953 for hackers@freebsd.org; Sun, 23 Nov 2003 22:05:52 +0100 (CET) From: Vincent Jardin To: hackers@freebsd.org Date: Sun, 23 Nov 2003 22:05:52 +0100 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311232205.52489.vjardin@free.fr> Subject: XIP and Memory Device driver 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, 23 Nov 2003 21:03:57 -0000 Hi, When a program is stored by a filesystem that is on a MD, are the read-only sections of the binary file duplicated when it is executed ? It could help to save lot of memory ;-) Vincent From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 14:15:50 2003 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 B20C716A4CE for ; Sun, 23 Nov 2003 14:15:50 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA47943FAF for ; Sun, 23 Nov 2003 14:15:49 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) hANMFniF066838 for ; Sun, 23 Nov 2003 14:15:49 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id hANMFnx8066837; Sun, 23 Nov 2003 14:15:49 -0800 (PST) (envelope-from dillon) Date: Sun, 23 Nov 2003 14:15:49 -0800 (PST) From: Matthew Dillon Message-Id: <200311232215.hANMFnx8066837@apollo.backplane.com> To: freebsd-hackers@freebsd.org Subject: Minor bug in kern_sysctl.c on stable 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, 23 Nov 2003 22:15:50 -0000 In kern_sysctl.c I see you guys fixed the OID_AUTO collision with static OID's, but you still have to make the minimum OID_AUTO number 256, not 100 (around line 119 of kern_sysctl.c), or you may conflict with static OID's assigned from loadable modules. I don't know of any situations that can cause this, but the more complete fix still needs to be made to -stable. -current already sets the minimum to 256 (0x100) -Matt Matthew Dillon From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 17:50:47 2003 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 A93B316A4CE for ; Sun, 23 Nov 2003 17:50:47 -0800 (PST) Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DF1B43F93 for ; Sun, 23 Nov 2003 17:50:46 -0800 (PST) (envelope-from mmercer@nc.rr.com) Received: from [192.168.1.2] (rdu88-246-041.nc.rr.com [24.88.246.41]) hAO1ojNW006089 for ; Sun, 23 Nov 2003 20:50:45 -0500 (EST) From: "Michael E. Mercer" To: freebsd-hackers@freebsd.org Content-Type: text/plain Message-Id: <1069638644.355.9.camel@dual.mmercer.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 23 Nov 2003 20:50:45 -0500 Content-Transfer-Encoding: 7bit Subject: USB Question: unable to open /dev/ugen0 more than once 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, 24 Nov 2003 01:50:47 -0000 Hello peoples, I posted this to questions with no reply, I was hoping someone here may be able to give some insight. Question: Should I be able to open /dev/ugen0 more than once? I am using FreeBSD 4.9-Stable, libusb-0.1.7. >From reading the libusb docs, you must open the device for each interface you want to acquire. However, once it is opened once, it can't be opened again. Furthermore, calls to usb_find_devices() shows that /dev/ugen0 has disappeared. Investigation on how they(libusb) finds devices, shows they are trying to open the device read only... this is where it tries to open it the second time. This second try fails and therefore libusb thinks the device was removed. Question: Is this the correct behavior? Any help/insight would be greatly appreciated. Michael E Mercer From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 18:28:39 2003 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 75C9E16A4CE for ; Sun, 23 Nov 2003 18:28:39 -0800 (PST) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 786B643FDD for ; Sun, 23 Nov 2003 18:28:38 -0800 (PST) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id hAO2SbeC054363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 23 Nov 2003 21:28:38 -0500 (EST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id hAO2Sbf1054362 for freebsd-hackers@freebsd.org; Sun, 23 Nov 2003 21:28:37 -0500 (EST) Date: Sun, 23 Nov 2003 21:28:37 -0500 From: Leo Bicknell To: freebsd-hackers@freebsd.org Message-ID: <20031124022837.GA54284@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: Making a FreeBSD DVD 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, 24 Nov 2003 02:28:39 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'd like to make my own distribution DVD's. I know how to make CD's, but looking at release(7) I see lots of documentation for CD's, and none for DVD's. Googling turns up nothing of interest in the first three pages. Can anyone point me to the documentation on how to build DVD's, a-la what they sell on FreeBSD mall? --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/wWzVNh6mMG5yMTYRAocvAJ43//icaC8aTWvy4I8qMfq7PD5zFwCfSfca TvDnlWmH2hYD16XYXTr9QUE= =QXft -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc-- From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 18:37:01 2003 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 9FDDB16A4CE for ; Sun, 23 Nov 2003 18:37:01 -0800 (PST) Received: from tx2.oucs.ox.ac.uk (tx2.oucs.ox.ac.uk [163.1.2.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1D9543FD7 for ; Sun, 23 Nov 2003 18:36:59 -0800 (PST) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from scan2.oucs.ox.ac.uk ([163.1.2.162] helo=localhost) by tx2.oucs.ox.ac.uk with esmtp (Exim 4.20) id 1AO6aw-0008VQ-LY for freebsd-hackers@freebsd.org; Mon, 24 Nov 2003 02:36:58 +0000 Received: from rx2.oucs.ox.ac.uk ([163.1.2.161]) by localhost (scan2.oucs.ox.ac.uk [163.1.2.162]) (amavisd-new, port 25) with ESMTP id 32131-10 for ; Mon, 24 Nov 2003 02:36:58 +0000 (GMT) Received: from gateway.wadham.ox.ac.uk ([163.1.161.253]) by rx2.oucs.ox.ac.uk with smtp (Exim 4.20) id 1AO6aw-0008VI-88 for freebsd-hackers@freebsd.org; Mon, 24 Nov 2003 02:36:58 +0000 Received: (qmail 1290 invoked by uid 0); 24 Nov 2003 02:36:58 -0000 Received: from colin.percival@wadham.ox.ac.uk by gateway by uid 71 with qmail-scanner-1.16 (sweep: 2.14/3.71. spamassassin: 2.53. Clear:. Processed in 1.267279 secs); 24 Nov 2003 02:36:58 -0000 X-Qmail-Scanner-Mail-From: colin.percival@wadham.ox.ac.uk via gateway X-Qmail-Scanner: 1.16 (Clear:. Processed in 1.267279 secs) Received: from dhcp1131.wadham.ox.ac.uk (HELO piii600.wadham.ox.ac.uk) (163.1.161.131) by gateway.wadham.ox.ac.uk with SMTP; 24 Nov 2003 02:36:57 -0000 Message-Id: <5.0.2.1.1.20031124023346.01cb6608@popserver.sfu.ca> X-Sender: cperciva@popserver.sfu.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 24 Nov 2003 02:36:55 +0000 To: Leo Bicknell , freebsd-hackers@freebsd.org From: Colin Percival In-Reply-To: <20031124022837.GA54284@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: Making a FreeBSD DVD 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, 24 Nov 2003 02:37:01 -0000 At 21:28 23/11/2003 -0500, Leo Bicknell wrote: >I'd like to make my own distribution DVD's. I know how to make >CD's, but looking at release(7) I see lots of documentation for >CD's, and none for DVD's. Googling turns up nothing of interest >in the first three pages. > >Can anyone point me to the documentation on how to build DVD's, >a-la what they sell on FreeBSD mall? I can't help you with the CD vs. DVD distinction, but if you're going to ship -RELEASE disks, please distribute the binaries from the official release images. If you `make release` yourself, you'll break FreeBSD Update. (If you absolutely must build your own versions of the binaries, please contact me off-list.) Colin Percival From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 20:30:21 2003 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 2EA7A16A4CE for ; Sun, 23 Nov 2003 20:30:21 -0800 (PST) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 687A043FDD for ; Sun, 23 Nov 2003 20:30:19 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from localhost (localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.9/8.12.8) with ESMTP id hAO4UChk033686; Mon, 24 Nov 2003 15:00:14 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Leo Bicknell , freebsd-hackers@freebsd.org Date: Mon, 24 Nov 2003 15:00:12 +1030 User-Agent: KMail/1.5.3 References: <20031124022837.GA54284@ussenterprise.ufp.org> In-Reply-To: <20031124022837.GA54284@ussenterprise.ufp.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311241500.12216.doconnor@gsoft.com.au> X-Spam-Score: -4.4 () CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: Re: Making a FreeBSD DVD 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, 24 Nov 2003 04:30:21 -0000 On Monday 24 November 2003 12:58, Leo Bicknell wrote: > I'd like to make my own distribution DVD's. I know how to make > CD's, but looking at release(7) I see lots of documentation for > CD's, and none for DVD's. Googling turns up nothing of interest > in the first three pages. > > Can anyone point me to the documentation on how to build DVD's, > a-la what they sell on FreeBSD mall? I don't think the difference between the two is particularly relevant. make release will make an directory suitable to put on a CD or DVD. It's just that if you use a DVD you can fit a lot more packages/distfiles on the disk (which make release doesn't do for you anyway). Try it and see :) I'm not sure if sysinstall groks UDF either, so I think it would be wise to put at an ISO9660 compat FS on the disk. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 21:03:38 2003 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 B2B9516A4CE for ; Sun, 23 Nov 2003 21:03:38 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 820FB43FBF for ; Sun, 23 Nov 2003 21:03:35 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 1104565213 for ; Mon, 24 Nov 2003 02:54:20 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17608-05 for ; Mon, 24 Nov 2003 02:54:19 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 6ED1F651F7 for ; Mon, 24 Nov 2003 02:54:19 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 9D48C26; Mon, 24 Nov 2003 02:54:18 +0000 (GMT) Date: Mon, 24 Nov 2003 02:54:18 +0000 From: Bruce M Simpson To: freebsd-hackers@freebsd.org Message-ID: <20031124025418.GC669@saboteur.dek.spc.org> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20031124022837.GA54284@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031124022837.GA54284@ussenterprise.ufp.org> Subject: Re: Making a FreeBSD DVD 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, 24 Nov 2003 05:03:38 -0000 On Sun, Nov 23, 2003 at 09:28:37PM -0500, Leo Bicknell wrote: > I'd like to make my own distribution DVD's. I know how to make [snip] I'm intrigued by this. Is it possible to build DVDs which will boot on i386 and/or a variety of architectures? FAQ pointers welcome... BMS From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 23 21:37:26 2003 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 0545016A4CE for ; Sun, 23 Nov 2003 21:37:26 -0800 (PST) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B24743FF3 for ; Sun, 23 Nov 2003 21:37:24 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from localhost (localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.9/8.12.8) with ESMTP id hAO5bKhk035134; Mon, 24 Nov 2003 16:07:20 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Bruce M Simpson , freebsd-hackers@freebsd.org Date: Mon, 24 Nov 2003 16:07:19 +1030 User-Agent: KMail/1.5.3 References: <20031124022837.GA54284@ussenterprise.ufp.org> <20031124025418.GC669@saboteur.dek.spc.org> In-Reply-To: <20031124025418.GC669@saboteur.dek.spc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311241607.19437.doconnor@gsoft.com.au> X-Spam-Score: -4.4 () CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: Re: Making a FreeBSD DVD 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, 24 Nov 2003 05:37:26 -0000 On Monday 24 November 2003 13:24, Bruce M Simpson wrote: > I'm intrigued by this. Is it possible to build DVDs which will boot on > i386 and/or a variety of architectures? FAQ pointers welcome... I haven't seen one, but I assume the BIOS just reads the ISO9660 FS and does an El Torrito boot as per a CD. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 00:52:30 2003 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 933DA16A4CE; Mon, 24 Nov 2003 00:52:30 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id E155143FAF; Mon, 24 Nov 2003 00:52:28 -0800 (PST) (envelope-from se@freebsd.org) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng3.kundenserver.de with esmtp (Exim 3.35 #1) id 1AOCSJ-0004Vh-00; Mon, 24 Nov 2003 09:52:27 +0100 Received: from [80.132.232.172] (helo=Gatekeeper.FreeBSD.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AOCSJ-0005Zr-00; Mon, 24 Nov 2003 09:52:27 +0100 Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 6638F5F18; Mon, 24 Nov 2003 09:52:25 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id 350E41E9A; Mon, 24 Nov 2003 09:52:25 +0100 (CET) Date: Mon, 24 Nov 2003 09:52:25 +0100 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20031124085225.GA1168@StefanEsser.FreeBSD.org> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311211333.39520.wes@softweyr.com> <20031121235607.GB16700@StefanEsser.FreeBSD.org> <200311230016.31498.wes@softweyr.com> <20031123121501.GA1133@StefanEsser.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fa3fae9b6ca38d745862a668565919f6 cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 24 Nov 2003 08:52:30 -0000 On 2003-11-23 17:31 +0100, Dag-Erling Sm=F8rgrav wrote: > Stefan E=DFer writes: > > What I'm suggesting is to have the obliteration implemented as an > > add on to the dirty buffer flush, with the difference that the=20 > > buffer contents is prepared for the next step of the erasure process, > > written out, and then not declared free but again prepared for the > > next overwrite pass. >=20 > This next pass won't be until thirty seconds later, so it'll take > about half an hour to completely obliterate a file. Furthermore, These 30 seconds are not a universal constant and ISTR. I had in mind, that one obliteration pass is performed.=20 After each pass, a cache flush has to be performed, and the=20 next pass is performed immediately or only after a brief delay. I see, that this may cause too many CPU cycles spent traversing the buffer cache. > unmounting a file system less than half an hour after a file is > deleted or truncated will fail, and shutting down will most likely > leave the file system unclean due to repeated failures to flush the > dirty buffer list. Yes, that's why I meant that fsck might be used to trigger the restart of an erasure process that was not completed due to=20 shutdown or a crash. This does obviously no good in case that=20 somebody else got hold of your disk, menawhile, but it covers cases that are not dealt with by a user-land utility (which=20 would just be stopped halfway through when the system goes down). Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 01:16:27 2003 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 D952716A4CE; Mon, 24 Nov 2003 01:16:27 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id B64B543F93; Mon, 24 Nov 2003 01:16:26 -0800 (PST) (envelope-from se@freebsd.org) Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng2.kundenserver.de with esmtp (Exim 3.35 #1) id 1AOCpT-0005rK-00; Mon, 24 Nov 2003 10:16:23 +0100 Received: from [80.132.232.172] (helo=Gatekeeper.FreeBSD.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AOCpT-0000pv-00; Mon, 24 Nov 2003 10:16:23 +0100 Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 5C0A05F18; Mon, 24 Nov 2003 10:16:21 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id 15E6A1EBC; Mon, 24 Nov 2003 10:16:21 +0100 (CET) Date: Mon, 24 Nov 2003 10:16:21 +0100 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Poul-Henning Kamp Message-ID: <20031124091621.GB1168@StefanEsser.FreeBSD.org> References: <8799.1069607075@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8799.1069607075@critter.freebsd.dk> User-Agent: Mutt/1.5.5.1i X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fa3fae9b6ca38d745862a668565919f6 cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: freebsd-hackers@FreeBSD.org cc: Rayson Ho Subject: Re: "secure" file flag? 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, 24 Nov 2003 09:16:28 -0000 On 2003-11-23 18:04 +0100, Poul-Henning Kamp wrote: > 1. Look for BIO_DELETE in the kernel. Seems that BIO_DELETE isn't really supported anymore (according to a comment in your GEOM sources ;-) AFAICT, BIO_DELETE can't easily be made a long running operation (taking tens of revolutions of a disk media) without really hurting performance because of assumptions that it will take about the same time as BIO_WRITE ... > 2. Use GBDE or other encryption. Yes, probably. But encryption is only as good as key management and secure storage (and deletion) of keys. How do you implement unattended reboot, if you consider unauthorized (physical) access to your system as one of the attack scenarios to protect against ? (Not meaning, that secure erase would really solve that problem ...) Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 01:48:19 2003 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 430F116A4CE; Mon, 24 Nov 2003 01:48:19 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B329643F3F; Mon, 24 Nov 2003 01:48:15 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id hAO9mCDx017778; Mon, 24 Nov 2003 10:48:12 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Stefan =?iso-8859-1?Q?E=DFer?= From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 24 Nov 2003 10:16:21 +0100." <20031124091621.GB1168@StefanEsser.FreeBSD.org> Date: Mon, 24 Nov 2003 10:48:12 +0100 Message-ID: <17777.1069667292@critter.freebsd.dk> cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: Rayson Ho cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 24 Nov 2003 09:48:19 -0000 In message <20031124091621.GB1168@StefanEsser.FreeBSD.org>, Stefan =?iso-8859-1 ?Q?E=DFer?= writes: >Yes, probably. But encryption is only as good as key >management and secure storage (and deletion) of keys. >How do you implement unattended reboot, if you consider >unauthorized (physical) access to your system as one >of the attack scenarios to protect against ? >(Not meaning, that secure erase would really solve >that problem ...) See my paper for a suggestion about using weak-link/strong-link methods for that. -- 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 Mon Nov 24 01:50:34 2003 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 5412A16A4CE for ; Mon, 24 Nov 2003 01:50:34 -0800 (PST) Received: from hon.ai.univ-paris8.fr (hon.ai.univ-paris8.fr [192.33.156.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F2443F85 for ; Mon, 24 Nov 2003 01:50:30 -0800 (PST) (envelope-from mh@ai.univ-paris8.fr) Received: from hai.ai.univ-paris8.fr (hai.ai.univ-paris8.fr [192.33.156.104]) hAO9oSlH011301 for ; Mon, 24 Nov 2003 10:50:28 +0100 (CET) Received: from localhost (mh@localhost) by hai.ai.univ-paris8.fr (8.11.4/8.11.4) with ESMTP id hAOA0vP30364 for ; Mon, 24 Nov 2003 11:00:57 +0100 Date: Mon, 24 Nov 2003 11:00:57 +0100 (CET) From: Marc Hufschmitt To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: can't fsck_ext2fs on a non sliced disk on 5.1 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, 24 Nov 2003 09:50:34 -0000 I got this message : # fsck_ext2fs -d /dev/ad3 ** /dev/ad3 BAD SUPER BLOCK: MAGIC NUMBER WRONG ioctl (GCINFO): Inappropriate ioctl for device /dev/ad3: can't read disk label is this due to geom or to FreeBSD 5.1? It worked on a 4.6.2. Though /dev/ad3 could be mounted when it was clean. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 01:59:54 2003 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 603F416A4CE for ; Mon, 24 Nov 2003 01:59:54 -0800 (PST) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5219043FB1 for ; Mon, 24 Nov 2003 01:59:53 -0800 (PST) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 591733ABB2D; Mon, 24 Nov 2003 10:58:52 +0100 (CET) Date: Mon, 24 Nov 2003 10:58:52 +0100 From: Pawel Jakub Dawidek To: freebsd-hackers@freebsd.org Message-ID: <20031124095852.GZ511@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="jk/5KjyVsvxWSMIA" Content-Disposition: inline X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE-p13 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i Subject: Size-independent byte order swapping functions. 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, 24 Nov 2003 09:59:54 -0000 --jk/5KjyVsvxWSMIA Content-Type: multipart/mixed; boundary="McOwgVabxjWRBDh+" Content-Disposition: inline --McOwgVabxjWRBDh+ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello hackers... Macros in attached patch are designed for doing life a little easier. If one is using strictly defined types as uint8_t, uint16_t, int32_t, etc. those macros are helpful IMHO, because futher value size changes does not affects code for byte order managing. This also does not hit perfromance, because this should be resolved at compile-time. I'm not sure if dedicated epanic() is the best way to implement out-of-range errors prevention - the more handy solution should cause compile error. --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --McOwgVabxjWRBDh+ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: attachment; filename="endian.h.patch" Content-Transfer-Encoding: quoted-printable --- endian.h.orig Sat Nov 22 13:15:40 2003 +++ endian.h Mon Nov 24 10:57:02 2003 @@ -49,6 +49,46 @@ #endif =20 /* + * Size-independent byte order swapping functions. + */ +#ifdef _KERNEL +#define epanic(msg) _epanic(msg, __FILE__, __LINE__) +/* New function, because panic(9) type is void and this is not enough. */ +static __inline int +_epanic(const char *msg, const char *file, unsigned line) +{ + + panic("%s:%u: %s", file, line, msg); + /* NOTREACHED */ +} +#define bswap(x) (sizeof(x) =3D=3D 1 ? (x) =3D (x) : \ + (sizeof(x) =3D=3D 2 ? bswap16(x) : \ + (sizeof(x) =3D=3D 4 ? bswap32(x) : \ + (sizeof(x) =3D=3D 8 ? bswap64(x) : \ + epanic("out of range in bswap()"))))) +#define htobe(x) (sizeof(x) =3D=3D 1 ? (x) =3D (x) : \ + (sizeof(x) =3D=3D 2 ? htobe16(x) : \ + (sizeof(x) =3D=3D 4 ? htobe32(x) : \ + (sizeof(x) =3D=3D 8 ? htobe64(x) : \ + epanic("out of range in htobe()"))))) +#define htole(x) (sizeof(x) =3D=3D 1 ? (x) =3D (x) : \ + (sizeof(x) =3D=3D 2 ? htole16(x) : \ + (sizeof(x) =3D=3D 4 ? htole32(x) : \ + (sizeof(x) =3D=3D 8 ? htole64(x) : \ + epanic("out of range in htole()"))))) +#define betoh(x) (sizeof(x) =3D=3D 1 ? (x) =3D (x) : \ + (sizeof(x) =3D=3D 2 ? betoh16(x) : \ + (sizeof(x) =3D=3D 4 ? betoh32(x) : \ + (sizeof(x) =3D=3D 8 ? betoh64(x) : \ + epanic("out of range in betoh()"))))) +#define letoh(x) (sizeof(x) =3D=3D 1 ? (x) =3D (x) : \ + (sizeof(x) =3D=3D 2 ? letoh16(x) : \ + (sizeof(x) =3D=3D 4 ? letoh32(x) : \ + (sizeof(x) =3D=3D 8 ? letoh64(x) : \ + epanic("out of range in letoh()"))))) +#endif + +/* * General byte order swapping functions. */ #define bswap16(x) __bswap16(x) --McOwgVabxjWRBDh+-- --jk/5KjyVsvxWSMIA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBP8HWXD/PhmMH/Mf1AQHNVQP9E2e8VNOXaxznkW3flpMHRkwoQFgSPde1 Hc+xdhY2Vv2AIqyMEnaS4x2ocUk9npt/+/B+C7d6rqXrN6s89P7faKtjHzoWwmJC HOXn1n/3lUvXXXwf5Vl42DxA555RL7YbYI3+9hoOqFHwlHQvDDa4wh+YFf9CC+jx lRoQKVhhBxQ= =kSg1 -----END PGP SIGNATURE----- --jk/5KjyVsvxWSMIA-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 02:29:49 2003 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 5D00416A4CF; Mon, 24 Nov 2003 02:29:49 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2D4043F3F; Mon, 24 Nov 2003 02:29:46 -0800 (PST) (envelope-from se@freebsd.org) Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng6.kundenserver.de with esmtp (Exim 3.35 #1) id 1AODyT-0004NV-00; Mon, 24 Nov 2003 11:29:45 +0100 Received: from [80.132.232.172] (helo=Gatekeeper.FreeBSD.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AODyR-00081p-00; Mon, 24 Nov 2003 11:29:43 +0100 Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 5E25B5F18; Mon, 24 Nov 2003 11:29:41 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id E8B3C1EBC; Mon, 24 Nov 2003 11:29:40 +0100 (CET) Date: Mon, 24 Nov 2003 11:29:40 +0100 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Wes Peters Message-ID: <20031124102940.GC1168@StefanEsser.FreeBSD.org> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311230019.11310.wes@softweyr.com> <20031123124620.GB1133@StefanEsser.FreeBSD.org> <200311231011.32965.wes@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311231011.32965.wes@softweyr.com> User-Agent: Mutt/1.5.5.1i X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fa3fae9b6ca38d745862a668565919f6 cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 24 Nov 2003 10:29:49 -0000 On 2003-11-23 10:11 -0800, Wes Peters wrote: > > Encrypting data and secure removal of data are orthogonal and in case > > you need one, the other propbably won't be a good choice. > > Both are completely adequate to protect the data on the disk from > disclosure. Yes, if effective. Encryption protects as long as the keys are unknown to the attacker, secure removal protects as long as the data is overwritten before the attacker tries to get access. I'm sure you know that ... > > fsck could identify incompletely erased (in the sense of multipass > > overwrite with specific patterns) blocks, if that state was marked in > > the inode. > > But if someone is attempting to recover your deleted data, they're not > going to run tools that would potentially eliminate that data from the > disk. I'm designing to the idea of a disk that has been physically taken > to a data recovery lab, because the intermediate steps don't interest me. > But you see that: Thanks! I'm getting more convinced that there might a chance to communicate, now ;-) > > This is not meant as protection in case power is removed and the disk > > is analyzed off-line since most probably no fsck will ever be run over > > the filesystem again. > > The data needs to be overwritten in a timely manner as well. Leaving the > disk in a partly erased state is the same as leaving it unerased. If you > don't want the processing delay needed to do the full erasure you > obviously don't really need full erasure. Yes. That's why encryption can be required. It protects data from the instant the clear-text has vanished (from RAM or some media). Secure deletion can't provide that! But there may still be situations, where you want to securely erase data from a medium. Either because that medium contained sensitive plain text or because it contained key data, for example (which is just another kind of sensitive plain text, in a way ;-) In that case, a small window of wulnerability may be tolerable (at least in a commercial environment). Encryption promises to keep existing data secret, and that promise may be broken. But in case you still need that data, you don't have much choice. Deleting it will not be an option. Secure erase gets rid of that data, and you don't have to worry that anybody may get hold of some kind of access key, once it's gone (which may take some time and effort to achieve, and that's what started this thread). Again: Nothing new to you ... > > It is meant to protect against a power failure (or reboot) with data > > not being erased according to the specification, which might survive > > for a long time after next start (not by an attacker but in normal > > service). This is extra paranoia (compare to a crash while "obliterate" > > is overwriting blocks, which will not be restarted after a crash ...) > > > > It seems that you are opposed to having "secure erase" support in the > > kernel, and in fact, I'm not sure it is that useful, myself. > > No, at one time I had it on my todo list, but came to a more full > understanding of the expense and abadoned it for that reason. I may > someday do it in the simplest form just to prove it workable to myself, > but I doubt that is a solution of general interest to FreeBSD. Ok. I've also thought some about this, and I think that different media might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs. Flash media). High density disks (ATA more than SCSI, actually) seem to make it much harder to recover remains of overwritten data, and it may in fact be acceptable to perform just a few passes with random data (as suggested by Peter Gutmann, 7 years ago, when areal densities were one to two orders of magnitude lower than today ...) > > But in case it is considered useful and implemented (I'd try it myself, > > if I was interested in using this feature), then we should discuss the > > techical (and security) aspects of several designs and that's what I'm > > trying to do. > > There is some merit in providing a mechanism that is 90% as secure at 10% > the computational cost. I basic infrastructure that provides a "secure > removal" flag at the file and/or filesystem layer and a choice of > patterns would be a nice solution. Those who just want to make sure the > contents of an email aren't inadvertantly disclosed to another user could > specify a simple pattern like overwrite with zeros once, those who want > to keep the FBI at bay could use the whole 37 passes and spend days > deleting files. Maybe I'll look into this again after all. The former > variant seems like it might even be useful for a mail server or similar > application. The ability to specify different patterns seems useful. I'd consider a window of vulnerability of 10 seconds to one minute acceptable, and I guess this should be possible to acchive, even for nontrivial amounts of data that are to be deleted (40 passes at 1MB/s effective (including seeks) would impose a limit of 25KB/s per disk, while 8 passes at 4MB/s effective would result in 0.5MB/s, both cases assuming that small files taht are spread over a file system are to be erased, maximum rate could obviously be higher than 5MB/s for modern disks if 8 passes are considered sufficient). I have not seen any estimate of the number of passes required for current time PRML disks in the 40GB per surface class ... > Have you seen any literature on secure overwrite patterns for flash? That > would be an interesting option to provide. If nothing else, I'd like to > hack something like that into obliterate. No, not really. I think the points made by Gutmann relating to RAM are valid for Flash, too. Flash devices are capable of remapping bad blocks in hardware, AFAIK, and ISTR that this feature can be used to evenly spread writes over all cells. This might lead to some other region of memory being overwritten than the one which is holding the data to be obliterated. I'd guess that the effects that made data recovery from RAM possible are as valid for Flash. And since you can't follow the advice given for RAM (toggle bits every few seconds), I don't know what you might do to prevent this. Increased areal density does not help as much as it does in the case of magnetic media, I guess, since bits are stored in distinct cells (and not on tracks on a surface as in case of magnetic media, where head postioning accuracy and other mechanical effects play a role). Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 03:20:21 2003 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 E334E16A4CE; Mon, 24 Nov 2003 03:20:21 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25D2043FBF; Mon, 24 Nov 2003 03:20:20 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 963E2530A; Mon, 24 Nov 2003 12:20:18 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 400F75309; Mon, 24 Nov 2003 12:20:10 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id BB64033C86; Mon, 24 Nov 2003 12:20:09 +0100 (CET) To: Stefan =?iso-8859-1?q?E=DFer?= References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311230019.11310.wes@softweyr.com> <20031123124620.GB1133@StefanEsser.FreeBSD.org> <200311231011.32965.wes@softweyr.com> <20031124102940.GC1168@StefanEsser.FreeBSD.org> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Mon, 24 Nov 2003 12:20:09 +0100 In-Reply-To: <20031124102940.GC1168@StefanEsser.FreeBSD.org> (Stefan =?iso-8859-1?q?E=DFer's?= message of "Mon, 24 Nov 2003 11:29:40 +0100") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: ss X-Spam-Status: No, hits=2.5 required=5.0 tests=RCVD_IN_DYNABLOCK autolearn=no version=2.60 cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 24 Nov 2003 11:20:22 -0000 Stefan E=DFer writes: > Ok. I've also thought some about this, and I think that different media > might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs.=20 > Flash media). PRML is not an encoding scheme like MFM or RLL, it is an algorithm for recovering a bitstream from a weak analog signal. Modern disks mostly use RLL encoding. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 03:55:33 2003 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 6199016A4CE for ; Mon, 24 Nov 2003 03:55:33 -0800 (PST) Received: from mail.crypta.net (cryptobank.biz [217.160.183.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2925C43FDD for ; Mon, 24 Nov 2003 03:55:32 -0800 (PST) (envelope-from ah@cryptobank.de) Received: by mail.crypta.net (Postfix, from userid 1001) id 2B9F978D06; Mon, 24 Nov 2003 12:55:30 +0100 (CET) Date: Mon, 24 Nov 2003 12:55:30 +0100 From: Andy Hilker To: freebsd-hackers@freebsd.org Message-ID: <20031124115530.GA865@goodhope.crypta.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-PGP-Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xEC6E1071 X-PGP-Fingerprint: 9B2E 5892 AD93 D5C5 FB8E 3912 35D6 951B EC6E 1071 Organization: cryptobank - Andy Hilker Subject: 4GB memory issues in current 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, 24 Nov 2003 11:55:33 -0000 Hi, i have stability problems with a xeon dual (same problems with UP kernel) and 4 GB of memory. After about 1 day, one apache does not deliver content and no logins are performed (console, ssh, ftp, ...) anymore. Console shows only motd message and nothing more. I have tried to set the following at loader.conf, but uptime inceases only to 4 days: kern.maxusers="512" kern.vm.kmem.size="450000000" kern.maxvnodes="200000" There was a posting about 4GB (fixed?) issues: Von:Paul Saab (ps@mu.org) -- snip -- Betrifft:Re: High mem (4GB) support on FreeBSD 4.8 Newsgroups:mailing.freebsd.hackers Datum:2003-10-19 13:42:00 PST -- snip -- Could someone tell me more about this issue? bye, Andy -- Andy Hilker -- mailto:ah@cryptobank.de http://www.cryptobank.de -- PGP Key: https://ca.crypta.net From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 05:54:51 2003 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 640CE16A4CE for ; Mon, 24 Nov 2003 05:54:51 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6688243FD7 for ; Mon, 24 Nov 2003 05:54:49 -0800 (PST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) hAODsgvq012880 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 24 Nov 2003 14:54:45 +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 hAODsfER070878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2003 14:54: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.10/8.12.10) with ESMTP id hAODse2u026504; Mon, 24 Nov 2003 14:54:40 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id hAODsd0a026503; Mon, 24 Nov 2003 14:54:39 +0100 (CET) (envelope-from ticso) Date: Mon, 24 Nov 2003 14:54:39 +0100 From: Bernd Walter To: "Michael E. Mercer" Message-ID: <20031124135438.GP74178@cicely12.cicely.de> References: <1069638644.355.9.camel@dual.mmercer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1069638644.355.9.camel@dual.mmercer.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: USB Question: unable to open /dev/ugen0 more than once 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: Mon, 24 Nov 2003 13:54:51 -0000 On Sun, Nov 23, 2003 at 08:50:45PM -0500, Michael E. Mercer wrote: > Hello peoples, > > I posted this to questions with no reply, I was hoping > someone here may be able to give some insight. > > > Question: Should I be able to open /dev/ugen0 more than once? > > I am using FreeBSD 4.9-Stable, libusb-0.1.7. > >From reading the libusb docs, you must open the device for each > interface you want to acquire. However, once it is opened once, it can't > be opened again. > > Furthermore, calls to usb_find_devices() shows that /dev/ugen0 has > disappeared. Investigation on how they(libusb) finds devices, shows they > are trying to open the device read only... this is where it tries to > open it the second time. This second try fails and therefore libusb > thinks the device was removed. > > Question: Is this the correct behavior? Yes - this is correct. A client using ugen on a multiple interface only need to open /dev/ugen? for probing only - the work should be done using the interface specific endpoints /dev/ugen?.? Opening /dev/ugen? read-only makes no sense, because there is no read only access possible - /dev/ugen? is for the control endpoint which always means sending commands to the device. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 06:26:00 2003 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 256A716A4CE for ; Mon, 24 Nov 2003 06:26:00 -0800 (PST) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EB9643FA3 for ; Mon, 24 Nov 2003 06:25:59 -0800 (PST) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id 9A16A3D28 for ; Mon, 24 Nov 2003 09:25:52 -0500 (EST) From: "Dan Langille" To: hackers@freebsd.org Date: Mon, 24 Nov 2003 09:25:52 -0500 MIME-Version: 1.0 Message-ID: <3FC1CEA0.28542.14DD8CEF@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: using devel/libusb to access USB 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, 24 Nov 2003 14:26:00 -0000 Travis Campbell and I are looking at apcupsd to get it working with the APC RS/XS series of USB capable UPSs. We're concentrating on 4.x. Some work has been done in this area by Riccardo Torrini. See http://docs.freebsd.org/cgi/getmsg.cgi?fetch=57225+0+archive/2003/free bsd-hardware/20030608.freebsd-hardware We have been looking at the devel/libusb port and experimenting with testlibusb which is a part of that port. We have noticed that usb_find_devices() does not find any devices. Looking at the usb.c code within libusb, we found that usb_os_find_devices() does not return any devices, and therefore the while loop is never entered. We tracked the problem down to usb_os_find_devices() (within bsd.c) and found that various things were preventing the list from being created. We're wondering if anyone has had success with devel/libusb for similar things. -- Dan Langille : http://www.langille.org/ From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 07:06:49 2003 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 51FB516A4CE for ; Mon, 24 Nov 2003 07:06:49 -0800 (PST) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20B9443F93 for ; Mon, 24 Nov 2003 07:06:47 -0800 (PST) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id hAOF6keC080970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Nov 2003 10:06:46 -0500 (EST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id hAOF6k67080969 for freebsd-hackers@freebsd.org; Mon, 24 Nov 2003 10:06:46 -0500 (EST) Date: Mon, 24 Nov 2003 10:06:46 -0500 From: Leo Bicknell To: freebsd-hackers@freebsd.org Message-ID: <20031124150646.GA80718@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20031124022837.GA54284@ussenterprise.ufp.org> <200311241500.12216.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <200311241500.12216.doconnor@gsoft.com.au> Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: Re: Making a FreeBSD DVD 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, 24 Nov 2003 15:06:49 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In a message written on Mon, Nov 24, 2003 at 03:00:12PM +1030, Daniel O'Con= nor wrote: > make release will make an directory suitable to put on a CD or DVD. It's = just=20 > that if you use a DVD you can fit a lot more packages/distfiles on the di= sk=20 > (which make release doesn't do for you anyway). Well, what I'm really interested in is the install + live file system on a single DVD, which is how the DVD's at FreeBSD mall are advertised (I've never bought one, myself). So, I can build an install CD, I (think I) can build a live file system CD. How do you get them both on a DVD, and give the user a boot choice? --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/wh6GNh6mMG5yMTYRAu68AJ9A6pqTEQUfOjUN+3aa/LxjrbdqZgCeIlCc tbkm23kMYVCsm363hclouZs= =Xv4t -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 07:18:48 2003 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 1037F16A4CE for ; Mon, 24 Nov 2003 07:18:48 -0800 (PST) Received: from mother.ludd.luth.se (mother.ludd.luth.se [130.240.16.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 238ED43F85 for ; Mon, 24 Nov 2003 07:18:46 -0800 (PST) (envelope-from pb@ludd.luth.se) Received: from brother.ludd.luth.se (daemon@brother.ludd.luth.se [130.240.16.78])hAOFIiDY004532 for ; Mon, 24 Nov 2003 16:18:44 +0100 (MET) From: Peter B Received: (from pb@localhost) by brother.ludd.luth.se (8.11.6+Sun/8.9.3) id hAOFIEl13682 for freebsd-hackers@freebsd.org; Mon, 24 Nov 2003 16:18:14 +0100 (MET) Message-Id: <200311241518.hAOFIEl13682@brother.ludd.luth.se> To: freebsd-hackers@freebsd.org Date: Mon, 24 Nov 2003 16:18:14 +0100 (MET) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Going realmode in kernel drivers? 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, 24 Nov 2003 15:18:48 -0000 i386/FreeBSD-4.x/lkm. How does one get into 'realmode' inside a kernel driver? The reason for the need is a tight timeing loop that measures the lenght of pulses. And disableing interrupts is just not enough. Target cpu's are AMD K5 + AMD XP. Asfair when reading cycles per opcode. The number of cycles required increase about three times when useing protected mode or similar. Code excerpt: u_int32_t register cnt1; u_int32_t register cnt_max=0xFF; u_int32_t register *store_ptr; u_int32_t register *store_end; u_int8_t register last_val=0; store_ptr = ..; store_end = ..+ SIZ; disable_intr(); for(;;) { for(cnt1=0; cnt1=store_end ) break; last_val ^= 0x20; } enable_intr(); (Will start on a new count every signal flank). /P From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 11:04:43 2003 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 DD93016A4CE for ; Mon, 24 Nov 2003 11:04:43 -0800 (PST) Received: from ms-smtp-01.nyroc.rr.com (ms-smtp-01-qfe0.nyroc.rr.com [24.24.2.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 006CD44008 for ; Mon, 24 Nov 2003 11:02:01 -0800 (PST) (envelope-from martines@rochester.rr.com) Received: from domain.crafts4life.com (roc-66-66-65-30.rochester.rr.com [66.66.65.30])hAOJ1wQE029711 for ; Mon, 24 Nov 2003 14:01:59 -0500 (EST) Received: from localhost.crafts4life.com (localhost [127.0.0.1]) by domain.crafts4life.com (Postfix) with ESMTP id 50C303FEB for ; Mon, 24 Nov 2003 14:01:58 -0500 (EST) Received: from domain.crafts4life.com (localhost.crafts4life.com [127.0.0.1]) by localhost.crafts4life.com (AvMailGate-2.0.1.16) id 57237-4ACDF60E; Mon, 24 Nov 2003 14:01:57 -0500 Received: from firestorm.crafts4life.com (firestorm.crafts4life.com [192.168.1.53]) by domain.crafts4life.com (Postfix) with ESMTP id 918F43FBE for ; Mon, 24 Nov 2003 14:01:57 -0500 (EST) From: Eduard Martinescu To: freebsd-hackers@freebsd.org Message-Id: <1069700517.4505.0.camel@firestorm.crafts4life.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 24 Nov 2003 14:01:57 -0500 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.16; AVE: 6.22.0.1; VDF: 6.22.0.47; host: domain.crafts4life.com) X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: [Fwd: TWE driver IOCTL's] 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, 24 Nov 2003 19:04:44 -0000 Tried this on current, but no responses...maybe some one here has some ideas? Hello, I looking to extend the smartmontools support (/usr/ports/sysutils/smartmontools) to include support for drives behind a TWE device. I looked at the source for the TWE driver, and it seems to support what I need....not sure yet, as the linux version use the ATA Passthru IOCTL. At any rate, there does not appear to be any twe.h include files installed into /usr/include anywhere for my program to be able to pick the correct definitions. Is this just an oversight? Or did I miss something? Thanks, Ed -- Eduard Martinescu From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 15:57:43 2003 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 E416316A4CF; Mon, 24 Nov 2003 15:57:43 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A14E43FAF; Mon, 24 Nov 2003 15:57:42 -0800 (PST) (envelope-from se@freebsd.org) Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AOQaL-0001QB-00; Tue, 25 Nov 2003 00:57:41 +0100 Received: from [80.132.232.172] (helo=Gatekeeper.FreeBSD.org) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AOQaK-0004j3-00; Tue, 25 Nov 2003 00:57:41 +0100 Received: from StefanEsser.FreeBSD.org (StefanEsser [10.0.0.1]) by Gatekeeper.FreeBSD.org (Postfix) with ESMTP id 0A0B35F18; Tue, 25 Nov 2003 00:57:38 +0100 (CET) Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id 910621E95; Tue, 25 Nov 2003 00:57:38 +0100 (CET) Date: Tue, 25 Nov 2003 00:57:38 +0100 From: Stefan =?iso-8859-1?Q?E=DFer?= To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20031124235738.GA4107@StefanEsser.FreeBSD.org> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311230019.11310.wes@softweyr.com> <20031123124620.GB1133@StefanEsser.FreeBSD.org> <200311231011.32965.wes@softweyr.com> <20031124102940.GC1168@StefanEsser.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fa3fae9b6ca38d745862a668565919f6 cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 24 Nov 2003 23:57:44 -0000 On 2003-11-24 12:20 +0100, Dag-Erling Sm=F8rgrav wrote: > Stefan E=DFer writes: > > Ok. I've also thought some about this, and I think that different med= ia > > might need different methods (i.e. MFM vs. RLL vs. PRML, but also vs.= =20 > > Flash media). >=20 > PRML is not an encoding scheme like MFM or RLL, it is an algorithm for > recovering a bitstream from a weak analog signal. Modern disks mostly > use RLL encoding. So what? PRML is not complementary to RLL. RLL is typically used=20 to mean 1,7 RLL offering a 2/3 coding, while PRML starts at 8/9=20 and current devices use up to 24/25 (i.e. 24 bits in 25 channel bits).=20 MFM can be considered a special case of RLL encoding, too, BTW ... But it's utterly irrelevant, that PRML data is written to disk as=20 an RLL encoded data stream. What matters is what can be read back=20 from the disk media (and PRML is about reading, not writing ;-) You probably don't want to claim that 1,7 RLL and a modern PRML=20 encoding can be decoded with similar effort ... And that is what this thread is about: Secure removal of data from=20 storage media. There definitely is a difference between RLL (as in=20 1,7i RLL) and modern PRML drives under this aspect. Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 15:59:55 2003 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 BC0D516A4CE for ; Mon, 24 Nov 2003 15:59:55 -0800 (PST) Received: from shaft.techsupport.co.uk (shaft.techsupport.co.uk [212.250.77.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A5BE43FD7 for ; Mon, 24 Nov 2003 15:59:54 -0800 (PST) (envelope-from setantae@submonkey.net) Received: from cpc2-cdif3-6-0-cust204.cdif.cable.ntl.com ([81.103.67.204] helo=shrike.submonkey.net ident=mailnull) by shaft.techsupport.co.uk with esmtp (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.24; FreeBSD 4.9) id 1AOQcS-0004FQ-Uz; Mon, 24 Nov 2003 23:59:53 +0000 Received: from setantae by shrike.submonkey.net with local (Exim 4.24; FreeBSD 4.9) id 1AOQcQ-000CPx-JX; Mon, 24 Nov 2003 23:59:50 +0000 Date: Mon, 24 Nov 2003 23:59:50 +0000 From: Ceri Davies To: Rayson Ho Message-ID: <20031124235950.GH66785@submonkey.net> References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9uNR01GrImESOVvg" Content-Disposition: inline In-Reply-To: <20031119003133.18473.qmail@web11404.mail.yahoo.com> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.4i Sender: Ceri Davies cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 24 Nov 2003 23:59:55 -0000 --9uNR01GrImESOVvg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2003 at 04:31:32PM -0800, Rayson Ho wrote: > I am wondering if it is useful to have a "secure" file flag?? >=20 > The secure file flag will be set for files that contain sensitive data. > Then the OS will take special care when operating on those "secure" > files. >=20 > e.g. when deleting a "secure" file, the OS will overwrite the file with > random data. It would also be useful to have a "noexport" flag, which would have the NFS code refuse to send it over the network. I could personally use this for setting on my PGP and SSH keys, while exporting the rest of /home. I did look at implementing this, but couldn't find the "correct" place to do the check for the flag. Any pointers for a kernel newbie? Ceri --=20 --9uNR01GrImESOVvg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/wpt2ocfcwTS3JF8RAgA0AKCKsb7lXoMVUXuTYkmpMi+bLieCMQCfQhkK bAv5t7mx4wjwlDdy0dE2scA= =5x5g -----END PGP SIGNATURE----- --9uNR01GrImESOVvg-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 16:26:28 2003 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 5E5D716A4CE for ; Mon, 24 Nov 2003 16:26:28 -0800 (PST) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A680943FCB for ; Mon, 24 Nov 2003 16:26:24 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from localhost (localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.9/8.12.8) with ESMTP id hAP0QKhk052355; Tue, 25 Nov 2003 10:56:21 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Leo Bicknell , freebsd-hackers@freebsd.org Date: Tue, 25 Nov 2003 10:56:20 +1030 User-Agent: KMail/1.5.3 References: <20031124022837.GA54284@ussenterprise.ufp.org> <200311241500.12216.doconnor@gsoft.com.au> <20031124150646.GA80718@ussenterprise.ufp.org> In-Reply-To: <20031124150646.GA80718@ussenterprise.ufp.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311251056.20173.doconnor@gsoft.com.au> X-Spam-Score: -4.1 () CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: Re: Making a FreeBSD DVD 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, 25 Nov 2003 00:26:28 -0000 On Tuesday 25 November 2003 01:36, Leo Bicknell wrote: > In a message written on Mon, Nov 24, 2003 at 03:00:12PM +1030, Daniel O'Connor wrote: > > make release will make an directory suitable to put on a CD or DVD. It's > > just that if you use a DVD you can fit a lot more packages/distfiles on > > the disk (which make release doesn't do for you anyway). > > Well, what I'm really interested in is the install + live file > system on a single DVD, which is how the DVD's at FreeBSD mall are > advertised (I've never bought one, myself). So, I can build an > install CD, I (think I) can build a live file system CD. How do > you get them both on a DVD, and give the user a boot choice? Good question.. I suggest you buy one from FreeBSDMall and look at how they do it :) (Although be careful not to violate their copyright) Maybe even ask them how they did it. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 17:15:22 2003 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 31A6516A4CE for ; Mon, 24 Nov 2003 17:15:22 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-123-40-77.dsl.pltn13.pacbell.net [68.123.40.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4175943FE5 for ; Mon, 24 Nov 2003 17:15:19 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.9/8.12.9) with ESMTP id hAP1D9en098320; Mon, 24 Nov 2003 17:13:09 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.9/8.12.9/Submit) id hAP1D8FR098319; Mon, 24 Nov 2003 17:13:08 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Mon, 24 Nov 2003 17:13:08 -0800 From: David Schultz To: Pawel Jakub Dawidek Message-ID: <20031125011308.GA98148@VARK.homeunix.com> Mail-Followup-To: Pawel Jakub Dawidek , freebsd-hackers@FreeBSD.ORG References: <20031124095852.GZ511@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031124095852.GZ511@garage.freebsd.pl> cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Size-independent byte order swapping functions. 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, 25 Nov 2003 01:15:22 -0000 On Mon, Nov 24, 2003, Pawel Jakub Dawidek wrote: > If one is using strictly defined types as uint8_t, uint16_t, int32_t, etc. > those macros are helpful IMHO, because futher value size changes does not > affects code for byte order managing. This also does not hit perfromance, > because this should be resolved at compile-time. Cool, looks useful. > I'm not sure if dedicated epanic() is the best way to implement out-of-range > errors prevention - the more handy solution should cause compile error. See CTASSERT. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 24 22:24:10 2003 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 D3B0E16A4CE; Mon, 24 Nov 2003 22:24:10 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34E1343FE0; Mon, 24 Nov 2003 22:24:09 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id hAP6O3Dx032477; Tue, 25 Nov 2003 07:24:04 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Stefan =?iso-8859-1?Q?E=DFer?= From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 25 Nov 2003 00:57:38 +0100." <20031124235738.GA4107@StefanEsser.FreeBSD.org> Date: Tue, 25 Nov 2003 07:24:03 +0100 Message-ID: <32476.1069741443@critter.freebsd.dk> cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: Rayson Ho cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 25 Nov 2003 06:24:10 -0000 In message <20031124235738.GA4107@StefanEsser.FreeBSD.org>, Stefan =?iso-8859-1 >And that is what this thread is about: Secure removal of data from >storage media. There definitely is a difference between RLL (as in >1,7i RLL) and modern PRML drives under this aspect. No there isn't. It's been proven again and again that you cannot reliably overwrite data on a magnetic media. In particular the difference in read/write geometry and lack of fine control over head placement makes this impossible. The only reliable way to loose data is to encrypt them and throw the key away. Live with 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 Tue Nov 25 00:10:12 2003 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 E658D16A4CF; Tue, 25 Nov 2003 00:10:12 -0800 (PST) Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.157.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F79743FE0; Tue, 25 Nov 2003 00:10:10 -0800 (PST) (envelope-from mark@grondar.org) Received: from storm.FreeBSD.org.uk (Ugrondar@localhost [127.0.0.1]) hAP8A8eJ099414; Tue, 25 Nov 2003 08:10:08 GMT (envelope-from mark@grondar.org) Received: (from Ugrondar@localhost)hAP8A8ls099413; Tue, 25 Nov 2003 08:10:08 GMT (envelope-from mark@grondar.org) X-Authentication-Warning: storm.FreeBSD.org.uk: Ugrondar set sender to mark@grondar.org using -f Received: from grondar.org (localhost [127.0.0.1])hAP88ODw039675; Tue, 25 Nov 2003 08:08:24 GMT (envelope-from mark@grondar.org) From: Mark Murray Message-Id: <200311250808.hAP88ODw039675@grimreaper.grondar.org> To: David Schultz In-Reply-To: Your message of "Mon, 24 Nov 2003 17:13:08 PST." <20031125011308.GA98148@VARK.homeunix.com> Date: Tue, 25 Nov 2003 08:08:24 +0000 Sender: mark@grondar.org X-Spam-Status: No, hits=1.2 required=5.0 tests=EMAIL_ATTRIBUTION,FROM_NO_LOWER,IN_REP_TO version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-hackers@freebsd.org Subject: Re: Size-independent byte order swapping functions. 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, 25 Nov 2003 08:10:13 -0000 David Schultz writes: > > I'm not sure if dedicated epanic() is the best way to implement out-of-rang > e > > errors prevention - the more handy solution should cause compile error. > > See CTASSERT. There is an extremely limited number of sizes that are possible here, even with weird/theoretical architectures like 256-bit machines. Doesn't it make sense just to presume that out-of-range is impossible, and recode for default "if (sizeof(x) == 1) return x;" (ignore syntax) ? M -- Mark Murray iumop ap!sdn w,I idlaH From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 00:39:27 2003 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 C7FFE16A4CE for ; Tue, 25 Nov 2003 00:39:27 -0800 (PST) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3895B43F3F for ; Tue, 25 Nov 2003 00:39:25 -0800 (PST) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 2ECA13ABB2D; Tue, 25 Nov 2003 09:38:26 +0100 (CET) Date: Tue, 25 Nov 2003 09:38:26 +0100 From: Pawel Jakub Dawidek To: freebsd-hackers@FreeBSD.ORG Message-ID: <20031125083825.GB511@garage.freebsd.pl> References: <20031124095852.GZ511@garage.freebsd.pl> <20031125011308.GA98148@VARK.homeunix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="mMdCh5/a0q2ATNCM" Content-Disposition: inline In-Reply-To: <20031125011308.GA98148@VARK.homeunix.com> X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE-p13 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i Subject: Re: Size-independent byte order swapping functions. 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, 25 Nov 2003 08:39:27 -0000 --mMdCh5/a0q2ATNCM Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 24, 2003 at 05:13:08PM -0800, David Schultz wrote: +> On Mon, Nov 24, 2003, Pawel Jakub Dawidek wrote: +> > If one is using strictly defined types as uint8_t, uint16_t, int32_t, = etc. +> > those macros are helpful IMHO, because futher value size changes does = not +> > affects code for byte order managing. This also does not hit perfroman= ce, +> > because this should be resolved at compile-time. +>=20 +> Cool, looks useful. +>=20 +> > I'm not sure if dedicated epanic() is the best way to implement out-of= -range +> > errors prevention - the more handy solution should cause compile error. +>=20 +> See CTASSERT. I've tried, but you can't use CTASSERT() inside (?:). --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --mMdCh5/a0q2ATNCM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBP8MVAT/PhmMH/Mf1AQH7nAQAhgM1xRoWwwrno8RtcHwI0tANzHWW8vGE hKf63pMutVAyQ70q4URSMcB49WeMxXvw5q7xdCsdGVaNTP8WNhB7H6VKG0F0Z67g zdpTn3JZ+hR/89h1vsG7HpofoarrdXVrFvTHNSjaqK7zkUpkUf/vdZxSEqy4YhbK sGEnssVeRcw= =xTUS -----END PGP SIGNATURE----- --mMdCh5/a0q2ATNCM-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 01:53:33 2003 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 DF7CE16A4CE for ; Tue, 25 Nov 2003 01:53:33 -0800 (PST) Received: from acme.soth.at (door.soth.at [80.110.102.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 429BE4400B for ; Tue, 25 Nov 2003 01:53:32 -0800 (PST) (envelope-from toni@acme.soth.at) Received: from acme.soth.at (localhost [127.0.0.1]) by acme.soth.at (8.12.8/8.12.8) with ESMTP id hAP9rTtE002135; Tue, 25 Nov 2003 10:53:29 +0100 Received: (from toni@localhost) by acme.soth.at (8.12.8/8.12.8/Submit) id hAP9rT5Q002133; Tue, 25 Nov 2003 10:53:29 +0100 Date: Tue, 25 Nov 2003 10:53:29 +0100 From: Toni Andjelkovic To: Dan Langille Message-ID: <20031125095329.GB1975@acme.soth.at> References: <3FC1CEA0.28542.14DD8CEF@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FC1CEA0.28542.14DD8CEF@localhost> User-Agent: Mutt/1.4.1i cc: hackers@freebsd.org Subject: Re: using devel/libusb to access USB 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, 25 Nov 2003 09:53:34 -0000 On Mon, Nov 24 2003 (09:25:52 -0500), Dan Langille wrote: > We have been looking at the devel/libusb port and experimenting with > testlibusb which is a part of that port. We have noticed that > usb_find_devices() does not find any devices. Looking at the usb.c > code within libusb, we found that usb_os_find_devices() does not > return any devices, and therefore the while loop is never entered. > > We tracked the problem down to usb_os_find_devices() (within bsd.c) > and found that various things were preventing the list from being > created. I have experienced a similar problem a few months ago. I've tracked it to ugenopen() in sys/dev/usb/ugen.c, which returned EBUSY if the control endpoint /dev/ugen0 was already open. Consequently, usb_find_devices() failed to return anything useful. However, as Bernd Walter suggested in a recent posting to hackers@, this could be avoided by using interface specific endpoints (/dev/ugen?.?) instead of the control endpoint (/dev/ugen?) for communication. Cheers, Toni From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 03:57:20 2003 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 4DACD16A4CE for ; Tue, 25 Nov 2003 03:57:20 -0800 (PST) Received: from crf-consulting.co.uk (82-44-220-218.cable.ubr10.haye.blueyonder.co.uk [82.44.220.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id B627843FBD for ; Tue, 25 Nov 2003 03:57:16 -0800 (PST) (envelope-from nik@crf-consulting.co.uk) Received: from clan.nothing-going-on.org (clan.nothing-going-on.org [192.168.1.20])hAPBvF2B039609 for ; Tue, 25 Nov 2003 11:57:15 GMT (envelope-from nik@catkin) Received: from clan.nothing-going-on.org (localhost [127.0.0.1]) hAPBvFqO005972 for ; Tue, 25 Nov 2003 11:57:15 GMT (envelope-from nik@clan.nothing-going-on.org) Received: (from nik@localhost) by clan.nothing-going-on.org (8.12.8/8.12.8/Submit) id hAPBvELU005971 for freebsd-hackers@freebsd.org; Tue, 25 Nov 2003 11:57:14 GMT Date: Tue, 25 Nov 2003 11:57:14 +0000 From: Nik Clayton To: freebsd-hackers@freebsd.org Message-ID: <20031125115713.GB92304@clan.nothing-going-on.org> References: <20031124022837.GA54284@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/WwmFnJnmDyWGHa4" Content-Disposition: inline In-Reply-To: <20031124022837.GA54284@ussenterprise.ufp.org> User-Agent: Mutt/1.4.1i Organization: FreeBSD Project Subject: Re: Making a FreeBSD DVD 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, 25 Nov 2003 11:57:20 -0000 --/WwmFnJnmDyWGHa4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 23, 2003 at 09:28:37PM -0500, Leo Bicknell wrote: > I'd like to make my own distribution DVD's. I know how to make > CD's, but looking at release(7) I see lots of documentation for > CD's, and none for DVD's. Googling turns up nothing of interest > in the first three pages. >=20 > Can anyone point me to the documentation on how to build DVD's, > a-la what they sell on FreeBSD mall? Do you mean one offs, using a DVD burner, or do you mean in bulk, using a DVD replication house? If it's the former, ports/sysutils/dvd+rw-tools. If it's the latter, ports/sysutils/dvdtape. N --=20 FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Project http://www.freebsd.org/docproj/ \\\'',) \/ \= ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/= _) --/WwmFnJnmDyWGHa4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/w0OYk6gHZCw343URAlYmAJsH7yne/0E+xIQj3ZDzRXZmVF3WCwCgh4oM Gl8tfvMmcyRO56/C/wwBiVA= =FYon -----END PGP SIGNATURE----- --/WwmFnJnmDyWGHa4-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 07:33:31 2003 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 4619B16A4CE for ; Tue, 25 Nov 2003 07:33:31 -0800 (PST) Received: from gunjin.wccnet.org (gunjin.wccnet.org [198.111.176.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2ACC43FD7 for ; Tue, 25 Nov 2003 07:33:29 -0800 (PST) (envelope-from anthony@gunjin.wccnet.org) Received: from gunjin.wccnet.org (localhost.rexroof.com [127.0.0.1]) by gunjin.wccnet.org (8.12.3/8.12.2) with ESMTP id hAPFd3Pf078833 for ; Tue, 25 Nov 2003 10:39:04 -0500 (EST) Received: (from anthony@localhost) by gunjin.wccnet.org (8.12.3/8.12.3/Submit) id hAPFd3CP078832 for hackers@freebsd.org; Tue, 25 Nov 2003 10:39:03 -0500 (EST) Date: Tue, 25 Nov 2003 10:39:02 -0500 From: Anthony Schneider To: hackers@freebsd.org Message-ID: <20031125153901.GA78725@x-anthony.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: freebsd smp -> linux up 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, 25 Nov 2003 15:33:31 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline is there a way to have linux emulation report that its kernel is running on a UP system even though the freebsd box it's running on is SMP? i would like to get vmware running on my smp -current box, but vmmon_smp.ko is "broken", and with vmmon_up.ko loaded i get a message about needing to be running on an smp linux kernel version 2.0 (2.2) or higher, even though linux emulation reports a 2.4 kernel. my hope is that having vmware make no attempt at using smp resources i can get it to start. thanks for any help. -Anthony. from sysctl compat.linux: compat.linux.osname: Linux compat.linux.osrelease: 2.4.2 compat.linux.oss_version: 198144 --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE/w3eVKUeW47UGY2kRAoTHAJ9W7f7MwW89s3gluJfLvxDBxGXU6wCeNAWr MBSC1sFnxW1TdVfn/FsrkHk= =sgTC -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 09:48:29 2003 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 1F55216A4CE for ; Tue, 25 Nov 2003 09:48:29 -0800 (PST) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB0FD43FBF for ; Tue, 25 Nov 2003 09:48:27 -0800 (PST) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (p2ptxkj95md3c43n@thor.farley.org [IPv6:2002:4340:5fcd:1::5]) by mail.farley.org (8.12.9p2/8.12.9) with ESMTP id hAPHmQkd061685; Tue, 25 Nov 2003 11:48:26 -0600 (CST) (envelope-from sean-freebsd@farley.org) Received: from thor.farley.org (localhost [127.0.0.1]) by thor.farley.org (8.12.10/8.12.10) with ESMTP id hAPHmQtZ013296; Tue, 25 Nov 2003 11:48:26 -0600 (CST) (envelope-from sean-freebsd@farley.org) Received: from localhost (sean@localhost)hAPHmPdD013293; Tue, 25 Nov 2003 11:48:25 -0600 (CST) (envelope-from sean-freebsd@farley.org) X-Authentication-Warning: thor.farley.org: sean owned process doing -bs Date: Tue, 25 Nov 2003 11:48:25 -0600 (CST) From: Sean Farley X-X-Sender: sean@thor.farley.org To: "Duane H. Hesser" In-Reply-To: <200311220201.hAM21kC15224@mx1.monroe.net> Message-ID: <20031125114606.J12765@thor.farley.org> References: <200311220201.hAM21kC15224@mx1.monroe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Richard Coleman cc: Jay Sern Liew cc: freebsd-hackers@freebsd.org Subject: Re: integer and long max/min values 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, 25 Nov 2003 17:48:29 -0000 On Fri, 21 Nov 2003, Duane H. Hesser wrote: > On 21-Nov-2003 Richard Coleman wrote: > > Jay Sern Liew wrote: > > > >> how do I find out the maximum (and minimum) value a long and int will hold > >> in C? (before it overflows or underflows) > >> > >> if it's compiler-dependent, then does anyone know where I can find the GCC > >> documentation for stuff like that? > > > > It will be architecture dependent (32 or 64 bit machines?). I doubt the > > GCC docs talk about this. You might check Richard Steven's book on > > "Advanced Unix Programming". It covers lots of information about > > standard machine limits and how to discover them. > > As a point of interest, there is a file > > /usr/src/contrib/gcc/enquire.c > > in the distributed sources which, when compiled and run, will > report the max and min values of short, long, int, float, etc. > along with various sizes and alignments. To get the latest version (5.1a) of enquire: http://homepages.cwi.nl/~steven/enquire.html Sean ----------------------- sean-freebsd@farley.org From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 10:32:47 2003 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 AFCAE16A4CE for ; Tue, 25 Nov 2003 10:32:47 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BDB943F85 for ; Tue, 25 Nov 2003 10:32:44 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 7A6A9530A; Tue, 25 Nov 2003 19:32:43 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id AE3FE5309; Tue, 25 Nov 2003 19:32:35 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 5999B33C86; Tue, 25 Nov 2003 19:32:35 +0100 (CET) To: Anthony Schneider References: <20031125153901.GA78725@x-anthony.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Tue, 25 Nov 2003 19:32:35 +0100 In-Reply-To: <20031125153901.GA78725@x-anthony.com> (Anthony Schneider's message of "Tue, 25 Nov 2003 10:39:02 -0500") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: ss X-Spam-Status: No, hits=2.6 required=5.0 tests=RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.60 cc: hackers@freebsd.org Subject: Re: freebsd smp -> linux up 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, 25 Nov 2003 18:32:47 -0000 Anthony Schneider writes: > is there a way to have linux emulation report that its kernel is running > on a UP system even though the freebsd box it's running on is SMP? i > would like to get vmware running on my smp -current box, but vmmon_smp.ko > is "broken", and with vmmon_up.ko loaded i get a message about needing to > be running on an smp linux kernel version 2.0 (2.2) or higher, even though > linux emulation reports a 2.4 kernel. It would be interesting to know exactly what it needs that we don't provide. I suspect it's something really trivial... do you see any messages in syslog about unimplemented syscalls? Could you get a ktrace or something? DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 13:26:45 2003 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 6B00116A4CE for ; Tue, 25 Nov 2003 13:26:45 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A66243FDD for ; Tue, 25 Nov 2003 13:26:44 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) hAPLQiiF081443; Tue, 25 Nov 2003 13:26:44 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id hAPLQhXD081442; Tue, 25 Nov 2003 13:26:43 -0800 (PST) (envelope-from dillon) Date: Tue, 25 Nov 2003 13:26:43 -0800 (PST) From: Matthew Dillon Message-Id: <200311252126.hAPLQhXD081442@apollo.backplane.com> To: hackers@freebsd.org cc: kernel@dragonflybsd.org Subject: Pictures from the big BSD Party bash are up. 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, 25 Nov 2003 21:26:45 -0000 The pictures from the big BSD party bash last night are up. There were a lot of people there... at least 200. It was a lot of fun! But if you missed out you can console yourself with the pics: http://apollo.backplane.com/pics.bsdparty/ -Matt From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 17:10:00 2003 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 B356916A4CE for ; Tue, 25 Nov 2003 17:10:00 -0800 (PST) Received: from relay3.softcomca.com (relay3.softcomca.com [168.144.1.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B7D343FD7 for ; Tue, 25 Nov 2003 17:09:57 -0800 (PST) (envelope-from akanwar@digitarchy.com) Received: from M2W053.mail2web.com ([168.144.251.160]) by relay3.softcomca.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Nov 2003 20:09:56 -0500 Message-ID: <323910-22003113261956699@M2W053.mail2web.com> X-Priority: 3 X-Originating-IP: 68.111.37.3 X-URL: http://mail2web.com/ From: "akanwar@digitarchy.com" To: freebsd-hackers@freebsd.org Date: Tue, 25 Nov 2003 20:09:56 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 26 Nov 2003 01:09:56.0767 (UTC) FILETIME=[018AD2F0:01C3B3BA] Subject: patchlevels and FreeBSD source X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: akanwar@digitarchy.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 01:10:00 -0000 Hi all, Presently I install my servers using a automated pxeboot method=2E The NFS= image I choose is a copy of the freebsd 4=2E8-RELEASE cdrom=2E Post instal= l I cvsup the plain 4=2E8-RELEASE server to RELENG_4_8 (taking the patchlevel = to 4=2E8-RELEASE-p15 for example) and then build world=2E The cvsup/buildworl= d takes a long time=2E These steps are also difficult to automate=2E=20 My question is: Is it possible that I update my cdrom image to the to 4=2E8-RELEASE-p15 before install ? In other words, are the patches that released as source diffs also available as downloadable cd images? If the answer is no, then can I patch the cdrom image myself or create a new PATCHED cd image that I can then use for my NFS installs ? Thanks for your replies=2E Regards, -ansh -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web=2Ecom/ =2E From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 17:28:32 2003 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 84ED116A4CF for ; Tue, 25 Nov 2003 17:28:32 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E33B43FE3 for ; Tue, 25 Nov 2003 17:28:30 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfn2m.dialup.mindspring.com ([165.247.220.86] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AOoSl-0001aS-00; Tue, 25 Nov 2003 17:27:28 -0800 Message-ID: <3FC3FC0F.71CA1639@mindspring.com> Date: Tue, 25 Nov 2003 17:04:15 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Wes Peters References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311201327.29226.wes@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47d6774fe1b6c9ac26b33ff457d339202350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Rayson Ho Subject: Re: "secure" file flag? 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, 26 Nov 2003 01:28:32 -0000 Wes Peters wrote: > On Tuesday 18 November 2003 16:31, Rayson Ho wrote: > > e.g. when deleting a "secure" file, the OS will overwrite the file > > with random data. > > Better to overwrite it with a more "secure" pattern. See ports/ > sysutils/obliterate for references. It has been mentioned before that > this could be done on in the kernel, obliterating blocks in the VM > rather than zeroing them. I hadn't thought of applying at the file or > filesystem level. The DOD has a specific pattern it requirs, to consider the deletion to be secure. > The closest we have is the 'rm -P' command and the above-mentioned > obliterate command. The overwrite pattern used in 'rm -P' is not > likely to be effective against a dedicated inspection of the disk; the > one in obliterate somewhat more so. On most modern drives, nothing is likly to be ffective, without OS support all th way down to the driver and hardware flags level. The DOD specified pattern is only effective if you have separate control of the seek and the write. The reason for this is that you musttake head hysteresis into account since if you did a seek in for the initial write and a seek out for the erase, you will ens up with a small strip of bits that are readable, even if they are much smaller than a standard track width, since there is jitter in the head positioning that depends on the side of the track you are coming from. So in reality, you also need to control sector sparing and write caching, as well, to avoid track caching, if possible, and seeks for sector sparing which are hidden from the OS trying to invoke the write pattern: you need to turn both of these off, if you can. If you can't, you need to buy a different disk, and turn both of these off, if you can. If you can't, you are going to ned to write your own disk firmware. You also need to deal with not writing to tracks at one end or the other of the disk, since you can't seek to them from the opposite direction, which means you have no way to write the pattern you are expected to write. This generally means that the end tracks need to be treated as "scrath landing zones", and you only ever write pattern data to them, and then only because that's the way to get the disk head onto the track so you can seek back to the track that you really want to erase. In a track-caching world, this tends to be not useful, unless you can determine the physical geometry of the disk, and treat tracks as separate entities. Finally, if you have a track-caching disk, it's likely that the way it operates is to just seek in and start writing. That will mean that in order to avoid a thin stripe of your old bits, you have to trat tracks as singl entities, and that means that if you have a track that shares data with several files, and you want to scribble over one of them effectively, you have to scribble over everything effectively, and then put the data for the filec(s) you didn't want to erase back on the track. > This sounds like an interesting file flag. Would you expect the process > to block on the unlink(2) call while the overwrite takes place, or for > this to happen in a kernel thread? The former seems pretty straight- > forward, hacking at ffs_blkfree. The latter I really wouldn't know how > to begin without (a lot) more study. You would have to do the former, or you would not pass common criteria valuation, if that's what you are aiming for. The normal way this is handled in government secure facilities is a 2U rack unit containing thermite charges. The normal way this is handled in a commercial scure facility is mostly to put the disks in a crusher. If this is somthing other than that, I doubt anyone would be willing to spend US$60,000/MB to have someone recover your porn. You are likely safe enough with PHK's somewhat inscure disk encryption thingy. As an overall note, you might want to contact Michal Serrachio off list; he has a solution to this problem which h might be willing to license to you for a fee. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 17:30:29 2003 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 27CC216A4CE for ; Tue, 25 Nov 2003 17:30:29 -0800 (PST) Received: from dust.freshx.de (freshx.de [80.190.100.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 008B243FBF for ; Tue, 25 Nov 2003 17:30:27 -0800 (PST) (envelope-from kai@freshx.de) Received: from localhost (localhost.freshx.de [127.0.0.1]) by dust.freshx.de (Postfix) with ESMTP id A1DFF15E2C8 for ; Wed, 26 Nov 2003 02:30:11 +0100 (CET) Received: from localhost (localhost.freshx.de [127.0.0.1]) by dust.freshx.de (Postfix) with ESMTP id F062C15E2AE for ; Wed, 26 Nov 2003 02:30:10 +0100 (CET) Received: from 127.0.0.1 ( [127.0.0.1]) as user dust0005@localhost by localhost with HTTP; Wed, 26 Nov 2003 02:30:10 +0100 Message-ID: <1069810210.3fc40222e2bca@localhost> Date: Wed, 26 Nov 2003 02:30:10 +0100 From: "sapdb@komadev.de" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Virus-Scanned: by AMaViS 0.3.12 Subject: getpwnam with md5 encrypted passwds 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, 26 Nov 2003 01:30:29 -0000 Hi, i am trying to validate a given user password against my local passwd-file with this piece of code : if (!( pwd = getpwnam ( user ))) { log(ERROR,"User %s not known",user); stat=NOUSER; } if (!strcmp( crypt(pass,pwd->pw_name), pwd->pw_passwd) ) { log(DEBUG|MISC,"HURRAY : %s authenticated\n", user); stat = AUTHED; } The problem is, that my passwords are encrypted in md5-format, so the strcmp fails always. Now i did not find any usable information on how to work this out on FreeBSD, and how to be independent from the settings in the login-conf ? (that i dont have to check whether its using crypt,md5 or blowfish) The code should be running on 4.x and 5.x Any ideas ? Kind regards Kai From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 17:53:09 2003 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 663B216A4CE for ; Tue, 25 Nov 2003 17:53:09 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1B2643F93 for ; Tue, 25 Nov 2003 17:53:08 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfn2m.dialup.mindspring.com ([165.247.220.86] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AOoqh-00005M-00; Tue, 25 Nov 2003 17:52:12 -0800 Message-ID: <3FC400DF.6182727F@mindspring.com> Date: Tue, 25 Nov 2003 17:24:47 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jim.durham@nepinc.com References: <200311211635.10353.jimd@nepinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4e10678c2457905ee616b1f0c501b45b4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: Library libgcc_pic.a missing on 5.1? 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, 26 Nov 2003 01:53:09 -0000 Jim Durham wrote: > Is liibgcc_a not supposed to be on 5.1? Is the one in /usr/lib not good enough for you? 8-) 8-). -- Terry From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 18:11:50 2003 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 2B27216A4CE for ; Tue, 25 Nov 2003 18:11:50 -0800 (PST) Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C3F343FDF for ; Tue, 25 Nov 2003 18:11:48 -0800 (PST) (envelope-from bsd@bsdhome.com) Received: from neutrino.bsdhome.com (cpe-024-211-176-245.nc.rr.com [24.211.176.245])hAQ2BjPf006341 for ; Tue, 25 Nov 2003 21:11:46 -0500 (EST) Received: from neutrino.bsdhome.com (localhost [127.0.0.1]) hAQ2BjUO001398; Tue, 25 Nov 2003 21:11:45 -0500 (EST) (envelope-from bsd@neutrino.bsdhome.com) Received: (from bsd@localhost) by neutrino.bsdhome.com (8.12.10/8.12.10/Submit) id hAQ2Bjlo001397; Tue, 25 Nov 2003 21:11:45 -0500 (EST) (envelope-from bsd) Date: Tue, 25 Nov 2003 21:11:44 -0500 From: Brian Dean To: freebsd-hackers@freebsd.org Message-ID: <20031126021144.GB617@neutrino.bsdhome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1i X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: puc/sio driver - receives but doesn't send 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, 26 Nov 2003 02:11:50 -0000 Hi, I just got a Syba 2 port serial I/O card, from dmesg: puc0: port 0x7000-0x700f,0x7400-0x7407,0x7800-0x7807,0x8000-0x8007,0x8400-0x8407,0x8800-0x8807 irq 5 at device 15.0 on pci0 sio2: type 16550A sio3: type 16550A The above dmesg line is not 100% correct - the card does not have a parallel port, just 2 serial ports. Using either of the available 2 ports, I'm able to receive data, but it doesn't want to transmit. I've tried everything I can think of, which includes: * both with and without the PUC_FASTINTR kernel option * ensure flow control lines are correct / ignored * using a loopback handshake cable (just in case) If I hook one of the SIO ports on the PUC to one of the serial ports on the motherboard, and open 'tip' on each one, what I type on the motherboard serial gets displayed on the PUC serial port tip session. However, when I type in the PUC serial port tip window, no data comes though on the motherboard serial tip. But when I run systat, I can see the puc0 device getting interrupts on irq 5 when I'm typing characters, as if it is sending the characters. Also, I have verified with a seperate microcontroller serial device - the PUC port is receiving data fine from the microcontroller, but it is not sending to the microcontroller for some reason. Anybody have any ideas what might be wrong? And yes, the motherboard serial ports both work as expected using the same cables, etc. I'm running 4.9-STABLE from a few days ago. Thanks, -Brian -- Brian Dean bsd@bsdhome.com http://www.bsdhome.com/ From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 22:24:53 2003 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 85DB516A4CE for ; Tue, 25 Nov 2003 22:24:53 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8767243FEA for ; Tue, 25 Nov 2003 22:24:52 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id hAQ6Onlg045455; Tue, 25 Nov 2003 23:24:50 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 25 Nov 2003 23:24:29 -0700 (MST) Message-Id: <20031125.232429.11430485.imp@bsdimp.com> To: bsd@bsdhome.com From: "M. Warner Losh" In-Reply-To: <20031126021144.GB617@neutrino.bsdhome.com> References: <20031126021144.GB617@neutrino.bsdhome.com> X-Mailer: Mew version 2.1 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: puc/sio driver - receives but doesn't send 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, 26 Nov 2003 06:24:53 -0000 In message: <20031126021144.GB617@neutrino.bsdhome.com> Brian Dean writes: : Anybody have any ideas what might be wrong? : : And yes, the motherboard serial ports both work as expected using the : same cables, etc. I know this is a long shot.... But maybe there's a cold solder joint on the NetMOS dual UART board? /me happily using two PUC devices right now on his 4.9 box: puc0: port 0xa400-0xa40f,0xa800-0xa83f,0xb000-0xb07f irq 5 at device 9.0 on pci0 puc1: port 0x9800-0x981f,0xa000-0xa01f mem 0xe1000000-0xe1000fff,0xe1800000-0xe1800fff irq 12 at device 10.0 on pci0 The moxa is a 8 port monster, and the Titan is a 4 port monster (yes, I do need 12 serial ports for all the machines I act as serial console for, well maybe only 10). Maybe I have too many machines... Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 23:10:20 2003 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 D5FFE16A4CE for ; Tue, 25 Nov 2003 23:10:20 -0800 (PST) Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73AB043F93 for ; Tue, 25 Nov 2003 23:10:19 -0800 (PST) (envelope-from langd@informatik.tu-muenchen.de) Date: Wed, 26 Nov 2003 08:10:17 +0100 From: Daniel Lang To: "akanwar@digitarchy.com" Message-ID: <20031126071017.GA27981@atrbg11.informatik.tu-muenchen.de> References: <323910-22003113261956699@M2W053.mail2web.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <323910-22003113261956699@M2W053.mail2web.com> X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ User-Agent: Mutt/1.5.1i X-Virus-Scanned: by amavisd-new at informatik.tu-muenchen.de cc: freebsd-hackers@freebsd.org Subject: Re: patchlevels and FreeBSD source 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, 26 Nov 2003 07:10:20 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, akanwar@digitarchy.com wrote on Tue, Nov 25, 2003 at 08:09:56PM -0500: [..] > 4.8-RELEASE-p15 for example) and then build world. The cvsup/buildworld > takes a long time. These steps are also difficult to automate.=20 >=20 > My question is: Is it possible that I update my cdrom image to the to > 4.8-RELEASE-p15 before install ? In other words, are the patches that > released as source diffs also available as downloadable cd images? [..] I see two possibilities: 1. CVSup and build the world on your install-server (or any other NFS server) pre installation, NFS export /usr/src and /usr/obj to all your clients.=20 During post-install, mount these directories and call 'make installworld'. This should take much less time and effort. 2. If you really want a installable CD image, you need to build a release, cf. release(7). Beware, that make release is a complicated process, that consumes a lot of ressources and can take a long time. HTH, Daniel --=20 IRCnet: Mr-Spock - Der Schatten von Hasenfuss ist ziemlich dunkel - =20 Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ --5mCyUwZo2JvN/JJP Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIXgAYJKoZIhvcNAQcCoIIXcTCCF20CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FUAwggbMMIIFtKADAgECAgIVezANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCREUxETAP BgNVBAcTCE11ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBNdWVu Y2hlbjEiMCAGA1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEYMBYGA1UEAxMPUkJH LUJlbnV0emVyLUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGUwHhcNMDMwNTIwMTIz MTQyWhcNMDQwNTIxMDAwMDAwWjCBqzELMAkGA1UEBhMCREUxETAPBgNVBAcTCE11ZW5jaGVu MSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBNdWVuY2hlbjEiMCAGA1UECxMZ RmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEUMBIGA1UEAxMLRGFuaWVsIExhbmcxJDAiBgkq hkiG9w0BCQEWFWRhbmllbC5sYW5nQGluLnR1bS5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAk55VXazdhYUuEJAHmO439gJwKVfvcdF64VyP8tzhYwiIx/9FOsQj8r8Gw2g0MDCa X2mCNiSKz32sUI33SQFhBhwxoF6bpq7d6pfeJ7UL+2T/bkRVF/Y7zPuMMK/wMbiEwyfvdjxk 8XsVtpj500LjW7QYdAHlijHRAY2nFk4f8bcCAwEAAaOCA38wggN7MAwGA1UdEwEB/wQCMAAw HQYDVR0OBBYEFPMLcu3eegcL6m8ObwlveYDdoYOpMIHKBgNVHSMEgcIwgb+AFK81Ou8wbY/H n0tx1dgCig9IKGPUoYGjpIGgMIGdMQswCQYDVQQGEwJERTERMA8GA1UEBxMITXVlbmNoZW4x KTAnBgNVBAoTIFRlY2huaXNjaGUgVW5pdmVyc2l0YWV0IE11ZW5jaGVuMSIwIAYDVQQLExlG YWt1bHRhZXQgZnVlciBJbmZvcm1hdGlrMQ8wDQYDVQQDEwZSQkctQ0ExGzAZBgkqhkiG9w0B CQEWDGNhQGluLnR1bS5kZYIBAjAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMIGxBgNVHREEgakwgaaBD2xhbmdkQGluLnR1bS5kZYEVZGFuaWVsLmxh bmdAaW4udHVtLmRlgR9sYW5nZEBpbmZvcm1hdGlrLnR1LW11ZW5jaGVuLmRlgSVkYW5pZWwu bGFuZ0BpbmZvcm1hdGlrLnR1LW11ZW5jaGVuLmRlgRBsYW5nZEBjcy50dW0uZWR1gRZkYW5p ZWwubGFuZ0Bjcy50dW0uZWR1gQpkbEBsZW8ub3JnMAkGA1UdEgQCMAAwOAYDVR0fBDEwLzAt oCugKYYnaHR0cDovL2NhLmluLnR1bS5kZS9jcmxzL3VzZXJjYV9jcmwuY3JsMBEGCWCGSAGG +EIBAQQEAwIFoDCBnwYJYIZIAYb4QgENBIGRFoGORGllc2VzIFplcnRpZmlrYXQgd3VyZGUg YXVzZ2VzdGVsbHQgZnVlciBEYW5pZWwgTGFuZyB2b24gZGVyIFJCRy1CZW51dHplci1DQSwg RmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpayBkZXIgVGVjaG5pc2NoZW4gVW5pdmVyc2l0YWV0 IE11ZW5jaGVuLjA2BglghkgBhvhCAQMEKRYnaHR0cDovL2NhLmluLnR1bS5kZS9jZ2ktYmlu L3VzZXJjYS1yZXY/MDIGCWCGSAGG+EIBBAQlFiNodHRwOi8vY2EuaW4udHVtLmRlL2NnaS1i aW4vY2EtcmV2PzA2BglghkgBhvhCAQgEKRYnaHR0cDovL2NhLmluLnR1bS5kZS9wb2xpY2ll cy9yYmdjYS5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQAGrfB5rH9D6jl6Tx+hwXpv0a/TuV39 vIQWMCA1hi0V4pI+bMyGTW1k/Ve5C58wRZv7CSTnxTGoqZmqnV37GGQlZBmvsDE+u3FKL/T7 Tk/rlVajExCXGHwjgHp2FfCaVMawKSUrI60aDcUgLUtT2DKpEfKfr/MC7CDtCaYy6TW93cHc uv2oM+1PN+CIcR5PaqEySmeYoXBMXd6sktjyNUWLxsNhtFMVnOiwF3SZYbRbRobuEWM3o+W7 nijECUIKz8rvK3f/c8v9HlVitMbeaTs4J1nZUR9lsvGLik6vsfIgbmuP6MMkrKFYwq5XTR1x JtMcmvnqcWytpYFDVPGuGaj1MIIHKDCCBRCgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBnTEL MAkGA1UEBhMCREUxETAPBgNVBAcTCE11ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVu aXZlcnNpdGFldCBNdWVuY2hlbjEiMCAGA1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRp azEPMA0GA1UEAxMGUkJHLUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGUwHhcNMDIx MDA5MTY0MTAzWhcNMDQwNTIxMDAwMDAwWjCBpDELMAkGA1UEBhMCREUxETAPBgNVBAcTCE11 ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBNdWVuY2hlbjEiMCAG A1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEWMBQGA1UEAxMNUkJHLVNlcnZlci1D QTEbMBkGCSqGSIb3DQEJARYMY2FAaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAzAHBIFy4tKTvbMMg037hc9t2jR5MVpEUIPvrSWC4xpbr6Hw7abQW/lRfFpV8 enf9tSgfcl8kvGjAAD8AYeuDash6TQSUjBdZCe7V297oZ0dsuurZBkM5BwvLWF8vMiY+SD/+ XTqhnU6B/E9C+R5VXjXsXV2u9hDtKVC5hqVgnxRM5rT/LsUhcchgAXk2WuI8r9Llb+voPWwM FmHk2jxUwhvxZfGo15HDrvJUgzYsL36SmeYMI9Eo70uGmAQRPVVq2zn/3AC4z8X1cBd3ItnH YPbx0iUH5kEGq2KH5iCndwNq9oaFhKj+Y34wEv5BYl6sb5C9EBvtGyebNwuvmtC3tQIDAQAB o4ICaDCCAmQwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUH9QPe0VQVF1D2v8Su/itK/4O QMwwgcoGA1UdIwSBwjCBv4AU2WV+TUF/hD+1KtZ7E519yuW0XRqhgaOkgaAwgZ0xCzAJBgNV BAYTAkRFMREwDwYDVQQHEwhNdWVuY2hlbjEpMCcGA1UEChMgVGVjaG5pc2NoZSBVbml2ZXJz aXRhZXQgTXVlbmNoZW4xIjAgBgNVBAsTGUZha3VsdGFldCBmdWVyIEluZm9ybWF0aWsxDzAN BgNVBAMTBlJCRy1DQTEbMBkGCSqGSIb3DQEJARYMY2FAaW4udHVtLmRlggEAMA4GA1UdDwEB /wQEAwIBBjATBgNVHSUEDDAKBggrBgEFBQcDATA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8v Y2EuaW4udHVtLmRlL2NybHMvY2FfY3JsLmNybDARBglghkgBhvhCAQEEBAMCAgQwgYQGCWCG SAGG+EIBDQR3FnVaZXJ0aWZpa2F0IGZ1ZXIgUkJHLVNlcnZlci1DQSBhdXNnZXN0ZWxsdCB2 b24gUkJHLUNBLCBGYWt1bHRhZXQgZnVlciBJbmZvcm1hdGlrIGRlciBUZWNobmlzY2hlbiBV bml2ZXJzaXRhZXQgTXVlbmNoZW4wMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jYS5pbi50dW0u ZGUvY2dpLWJpbi9jYS1yZXY/MDwGCWCGSAGG+EIBCAQvFi1odHRwOi8vY2EuaW4udHVtLmRl L3BvbGljaWVzL3NlcnZlcmNhcG9sLmh0bWwwDQYJKoZIhvcNAQEFBQADggIBAMzKnULQb6Kd hPNmKKmPSJJUOtbHxGH7Qi8paskt7dzDja/X7wz3524LGN2f05c1uAfyAP9Ar0nFthWy0qeM ueOtrOcSCj8AYwYN5H4drMC8GglQwlkD0M/nhPJ5xtAj8JzNYHzG1DK5tVgoJnF+t4KmTpI6 QJ6Dh3XDoZXubWd0jkHxQIzOKhs9PPjEzydmerC7B3Zt8vh7457Sk6wwZFhXc+nkeIIplnlD sBioOSyF7hZOwx4I2Auxss1zsyUQHCX88sOuZC0kYB7yRd1TMRti8josznux8k13sZBezFMP S2yCuKRBEk5Nt57OyGbIF4O7Mhn01mTnol2BDpTKJek45bIpRvSLl/xRPpjnzxLO1rXtXgCs GtkmXj+Zwo5fnL6OvZIiFgMV4ASsFclZexceHxDjpia1IHSFB/4I5fAys8Bw03idI+rfsla1 mW0AJuw260QgoBz+b+LKGosJdNosMfOJmNl0vW3Kq6NfYpZLkG0YJF9Xo6vsATFk9kNq56ye ila80uE2wDO/BGAcBMWQ4uwfrWqVPoW5X/oHcPISApnCBeZ+LyWvnTkgxCUeyqyxNOvaA/j7 jUoBb9l+GWup8EGND16mR/wYWAxYLgis1pn5QmSTbbKSWKcqDo6HBo1Zx9XRf76CZc7RJRp9 EXqYrkmlL9eg7qcnnS1rJbqxMIIHQDCCBSigAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBnTEL MAkGA1UEBhMCREUxETAPBgNVBAcTCE11ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVu aXZlcnNpdGFldCBNdWVuY2hlbjEiMCAGA1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRp azEPMA0GA1UEAxMGUkJHLUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGUwHhcNMDIx MDA5MTcwMzUyWhcNMDQwNTIxMDAwMDAwWjCBpjELMAkGA1UEBhMCREUxETAPBgNVBAcTCE11 ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBNdWVuY2hlbjEiMCAG A1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEYMBYGA1UEAxMPUkJHLUJlbnV0emVy LUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCtYQ5ycRY6fyrlvJgpeQCNhPxQduU59Kpv6xWId9sHL8NyI7nlmlWzMroD ddIqeg7QvvtPS+xorbQJ9rxh94lXZtwlGPYg4LC/1PHGnDt+8RGiq8GLbHyeJZoQnEGSovyn uR4wZ9qnApFRsXcUZ5W/CSSwjKnQeN39oFj8EC4xtmUuudV65sxGuGToRVoSnjeULJKYBNnC RxVx2MU5exKGQAuvgaVd7Ozb7ziZyWxhVCNrUQOGrSKDgyKLguWTNnD7sSOiOpie3IX8H2DV DvbcKcmMQr8ojwWutNDPadOth+J6qd/modqxB1VbH8wu0lezbhPM5dh7yUFCEqZoXXh9AgMB AAGjggJ+MIICejAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSvNTrvMG2Px59LcdXYAooP SChj1DCBygYDVR0jBIHCMIG/gBTZZX5NQX+EP7Uq1nsTnX3K5bRdGqGBo6SBoDCBnTELMAkG A1UEBhMCREUxETAPBgNVBAcTCE11ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZl cnNpdGFldCBNdWVuY2hlbjEiMCAGA1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEP MA0GA1UEAxMGUkJHLUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGWCAQAwDgYDVR0P AQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDA0BgNVHR8ELTArMCmg J6AlhiNodHRwOi8vY2EuaW4udHVtLmRlL2NybHMvY2FfY3JsLmNybDAJBgNVHRIEAjAAMBEG CWCGSAGG+EIBAQQEAwIBBjCBhwYJYIZIAYb4QgENBHoWeFplcnRpZmlrYXQgZnVlciBSQkct QmVudXR6ZXItQ0EsIGF1c2dlc3RlbGx0IHZvbiBSQkctQ0EsIEZha3VsdGFldCBmdWVyIElu Zm9ybWF0aWsgZGVyIFRlY2huaXNjaGVuIFVuaXZlcnNpdGFldCBNdWVuY2hlbjAyBglghkgB hvhCAQQEJRYjaHR0cDovL2NhLmluLnR1bS5kZS9jZ2ktYmluL2NhLXJldj8wOgYJYIZIAYb4 QgEIBC0WK2h0dHA6Ly9jYS5pbi50dW0uZGUvcG9saWNpZXMvdXNlcmNhcG9sLmh0bWwwDQYJ KoZIhvcNAQEFBQADggIBAJapnE3b+p2nrryUkfTEl5iKTl7o8hLrB4FbLZsdBs16pIb0fIIq yGR0wlv0Qq5OLHm1hQzGkfhqEb2O+oBQJgaykxAB+6rKKOJdL12LSQrYXbDV8t/isyurwkFi fmcWDxVF4reDcz8F61KrVz46k2KtdY39CcuW+x1xQZRgier+jdBLLsbkM21XkufUrwnnO5Vr j0cD48XmcsVuWF0EkGo49jPHk8LG2cMyhQR/ZT4f1kegi9WmoV4NjKJnEU2QaTfbLUb2i509 RYf31oDnhq6oO1wCcRvVeDfyx5aj0y68sL1ySNmTQEELOmOFPqmVqa9BAR4wzuTXJi9UvOwF tQMsKq9AX4cFegDl4D4E5QQ7JladBMvJ0VALdGSGlGHARQGvO8SvapsOTVPC5n+UD6jwhTw0 pCPSypzIIrpT9vjxD7bDvudOfKguVRuX8poWID7yXcB0ApHdoNIMrGJx1Tc6SN6rGKWYre+W y/AsqMNNmR+YrJn/UOs6lKX9TtaHOFbxNPwo7RgdRg/srESEtIQ5IKkPA0Vt9Eh5H3VWBhrU b1gmvyNTwJFRqYmFhr7jFFdgnX3Jsbw81jl1z4jLdeeslLxs8vmnwQvWRz3BEPo+g0mrIuYt QjSdgGF8xHgyeRxfa8o3P/rncBysyNYe/AdWd6UGPmompEBZuFzSN+G8MYICCDCCAgQCAQEw ga0wgaYxCzAJBgNVBAYTAkRFMREwDwYDVQQHEwhNdWVuY2hlbjEpMCcGA1UEChMgVGVjaG5p c2NoZSBVbml2ZXJzaXRhZXQgTXVlbmNoZW4xIjAgBgNVBAsTGUZha3VsdGFldCBmdWVyIElu Zm9ybWF0aWsxGDAWBgNVBAMTD1JCRy1CZW51dHplci1DQTEbMBkGCSqGSIb3DQEJARYMY2FA aW4udHVtLmRlAgIVezAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTEyNjA3MTAxN1owIwYJKoZIhvcNAQkEMRYEFNqvZBMKNe2q 2Wq92mWVk7i1+0rLMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAWdvam8ZmKb1mYnHbv/DuVLFnZDRR8Ei4JF4JOLyvWZNERnhVX/grdNQ1YZi7Urnv ZNPQ1lAPeioR7amuI1/3PnuBx/DCpM6m7Jg1sqWe/ROyye48syo40MEbjzTse/O8RX3UAL4r oqZBkIIdk/fJ1MLj6QWjyUAy4E2XbJL/5yk= --5mCyUwZo2JvN/JJP-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 25 23:24:26 2003 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 72EA516A4CF for ; Tue, 25 Nov 2003 23:24:26 -0800 (PST) Received: from tx1.oucs.ox.ac.uk (tx1.oucs.ox.ac.uk [129.67.1.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0314E43F85 for ; Tue, 25 Nov 2003 23:24:25 -0800 (PST) (envelope-from colin.percival@wadham.ox.ac.uk) Received: from scan1.oucs.ox.ac.uk ([129.67.1.166] helo=localhost) by tx1.oucs.ox.ac.uk with esmtp (Exim 4.20) id 1AOu2B-0003SF-JI for freebsd-hackers@freebsd.org; Wed, 26 Nov 2003 07:24:24 +0000 Received: from rx1.oucs.ox.ac.uk ([129.67.1.165]) by localhost (scan1.oucs.ox.ac.uk [129.67.1.166]) (amavisd-new, port 25) with ESMTP id 13057-09 for ; Wed, 26 Nov 2003 07:24:23 +0000 (GMT) Received: from gateway.wadham.ox.ac.uk ([163.1.161.253]) by rx1.oucs.ox.ac.uk with smtp (Exim 4.20) id 1AOu2B-0003SA-5u for freebsd-hackers@freebsd.org; Wed, 26 Nov 2003 07:24:23 +0000 Received: (qmail 23830 invoked by uid 0); 26 Nov 2003 07:24:23 -0000 Received: from colin.percival@wadham.ox.ac.uk by gateway by uid 71 with qmail-scanner-1.16 (sweep: 2.14/3.71. spamassassin: 2.53. Clear:. Processed in 1.32797 secs); 26 Nov 2003 07:24:23 -0000 X-Qmail-Scanner-Mail-From: colin.percival@wadham.ox.ac.uk via gateway X-Qmail-Scanner: 1.16 (Clear:. Processed in 1.32797 secs) Received: from dhcp1131.wadham.ox.ac.uk (HELO piii600.wadham.ox.ac.uk) (163.1.161.131) by gateway.wadham.ox.ac.uk with SMTP; 26 Nov 2003 07:24:22 -0000 Message-Id: <5.0.2.1.1.20031126071427.01cb4ab0@popserver.sfu.ca> X-Sender: cperciva@popserver.sfu.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 26 Nov 2003 07:24:19 +0000 To: akanwar@digitarchy.com, freebsd-hackers@freebsd.org From: Colin Percival In-Reply-To: <323910-22003113261956699@M2W053.mail2web.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: patchlevels and FreeBSD source 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, 26 Nov 2003 07:24:26 -0000 At 20:09 25/11/2003 -0500, akanwar@digitarchy.com wrote: >Presently I install my servers using a automated pxeboot method. The NFS >image I choose is a copy of the freebsd 4.8-RELEASE cdrom. Post install I >cvsup the plain 4.8-RELEASE server to RELENG_4_8 (taking the patchlevel to >4.8-RELEASE-p15 for example) and then build world. The cvsup/buildworld >takes a long time. These steps are also difficult to automate. After installing the RELEASE, install FreeBSD Update (ports/security/freebsd-update), move its configuration file into the right place, and run `freebsd-update fetch && freebsd-update install`. Given a decent internet connection, this takes no more than a couple minutes, and is much easier than updating your install image every time security issues arise. Colin Percival From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 00:41:52 2003 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 8BADE16A4CE for ; Wed, 26 Nov 2003 00:41:52 -0800 (PST) Received: from dust.freshx.de (freshx.de [80.190.100.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B95A43F75 for ; Wed, 26 Nov 2003 00:41:51 -0800 (PST) (envelope-from kai@freshx.de) Received: from localhost (localhost.freshx.de [127.0.0.1]) by dust.freshx.de (Postfix) with ESMTP id 8B8C915E2AE; Wed, 26 Nov 2003 09:41:47 +0100 (CET) Received: from localhost (localhost.freshx.de [127.0.0.1]) by dust.freshx.de (Postfix) with ESMTP id CB94615E2E6; Wed, 26 Nov 2003 09:41:46 +0100 (CET) Received: from 127.0.0.1 ( [127.0.0.1]) as user dust0005@localhost by localhost with HTTP; Wed, 26 Nov 2003 09:41:46 +0100 Message-ID: <1069836106.3fc4674ab26f6@localhost> Date: Wed, 26 Nov 2003 09:41:46 +0100 From: "sapdb@komadev.de" To: Q References: <1069810210.3fc40222e2bca@localhost> <1069813848.99808.8.camel@boxster.onthenet.com.au> In-Reply-To: <1069813848.99808.8.camel@boxster.onthenet.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Virus-Scanned: by AMaViS 0.3.12 cc: freebsd-hackers@freebsd.org Subject: Re: getpwnam with md5 encrypted passwds 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, 26 Nov 2003 08:41:52 -0000 Zitat von Q : This was a stupid mistake ! Thanks > Change your crypt line to: > > if (!strcmp( crypt(pass,pwd->pw_passwd), pwd->pw_passwd) ) { > > Seeya...Q > > On Wed, 2003-11-26 at 11:30, sapdb@komadev.de wrote: > > > Hi, > > > > i am trying to validate a given user password against my local passwd-file > with > > this piece of code : > > > > if (!( pwd = getpwnam ( user ))) { > > log(ERROR,"User %s not known",user); > > stat=NOUSER; > > } > > if (!strcmp( crypt(pass,pwd->pw_name), pwd->pw_passwd) ) { > > log(DEBUG|MISC,"HURRAY : %s authenticated\n", user); > > stat = AUTHED; > > } > > > > The problem is, that my passwords are encrypted in md5-format, so the > strcmp > > fails always. Now i did not find any usable information on how to work this > out > > on FreeBSD, and how to be independent from the settings in the login-conf ? > > > (that i dont have to check whether its using crypt,md5 or blowfish) > > > > The code should be running on 4.x and 5.x > > > > Any ideas ? > > > > Kind regards > > > > Kai > > _______________________________________________ > > 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 Nov 26 03:25:54 2003 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 6FB3716A4CE for ; Wed, 26 Nov 2003 03:25:54 -0800 (PST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99F3D43FDF for ; Wed, 26 Nov 2003 03:25:52 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au (ppp56-94.lns1.adl2.internode.on.net [150.101.56.94])hAQBPlEq023254; Wed, 26 Nov 2003 21:55:47 +1030 (CST) Received: from localhost (root@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.12.9/8.12.9) with ESMTP id hAQBPjdw011343; Wed, 26 Nov 2003 21:55:46 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Daniel Lang , "akanwar@digitarchy.com" Date: Wed, 26 Nov 2003 21:55:44 +1030 User-Agent: KMail/1.5.3 References: <323910-22003113261956699@M2W053.mail2web.com> <20031126071017.GA27981@atrbg11.informatik.tu-muenchen.de> In-Reply-To: <20031126071017.GA27981@atrbg11.informatik.tu-muenchen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311262155.44975.doconnor@gsoft.com.au> X-Spam-Score: -5.3 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) cc: freebsd-hackers@freebsd.org Subject: Re: patchlevels and FreeBSD source 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, 26 Nov 2003 11:25:54 -0000 On Wednesday 26 November 2003 17:40, Daniel Lang wrote: > 1. CVSup and build the world on your install-server (or any > other NFS server) pre installation, NFS export > /usr/src and /usr/obj to all your clients. > During post-install, mount these directories and call > 'make installworld'. > This should take much less time and effort. This is probably the best solution for the problem (IMHO :) > 2. If you really want a installable CD image, you need to > build a release, cf. release(7). Beware, that make release > is a complicated process, that consumes a lot of ressources > and can take a long time. For "modern computers" this isn't really true any more. I have a 1Ghz K7 which does make release in 4 hours (after a buildworld) That doesn't include building ports which takes a fair amount longer, but that just depends what ports you actually want :) It takes up about 2.1Gb of space (including building about 300Mb worth of packages) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 04:35:51 2003 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 6C36316A4CE for ; Wed, 26 Nov 2003 04:35:51 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F00143FEC for ; Wed, 26 Nov 2003 04:35:50 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-38lc18e.dialup.mindspring.com ([209.86.5.14] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1AOysf-0002Mp-00; Wed, 26 Nov 2003 04:34:53 -0800 Message-ID: <3FC49DA6.54459AD6@mindspring.com> Date: Wed, 26 Nov 2003 04:33:42 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "sapdb@komadev.de" References: <1069810210.3fc40222e2bca@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a49569e19862215bed8ea1288cca802645a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: getpwnam with md5 encrypted passwds 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, 26 Nov 2003 12:35:51 -0000 "sapdb@komadev.de" wrote: > i am trying to validate a given user password against my local passwd-file with > this piece of code : > > if (!( pwd = getpwnam ( user ))) { > log(ERROR,"User %s not known",user); > stat=NOUSER; > } > if (!strcmp( crypt(pass,pwd->pw_name), pwd->pw_passwd) ) { > log(DEBUG|MISC,"HURRAY : %s authenticated\n", user); > stat = AUTHED; > } I know you have the fix for the crypt of the wrong field, but the proper thing to do is probably to use pan_authenticate() so that you are insensitive to the athentication method being used, rather than crypting and comparing it yourself. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 05:01:15 2003 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 C818216A4CE for ; Wed, 26 Nov 2003 05:01:15 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id C53E043FCB for ; Wed, 26 Nov 2003 05:01:14 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 4B3625489C; Wed, 26 Nov 2003 07:01:14 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id DFC6F6D455; Wed, 26 Nov 2003 07:01:13 -0600 (CST) Date: Wed, 26 Nov 2003 07:01:13 -0600 From: "Jacques A. Vidrine" To: "akanwar@digitarchy.com" Message-ID: <20031126130113.GA57523@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , "akanwar@digitarchy.com" , freebsd-hackers@freebsd.org References: <323910-22003113261956699@M2W053.mail2web.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <323910-22003113261956699@M2W053.mail2web.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i-ja.1 cc: freebsd-hackers@freebsd.org Subject: Re: patchlevels and FreeBSD source 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, 26 Nov 2003 13:01:15 -0000 On Tue, Nov 25, 2003 at 08:09:56PM -0500, akanwar@digitarchy.com wrote: > My question is: Is it possible that I update my cdrom image to the to > 4.8-RELEASE-p15 before install ? In other words, are the patches that > released as source diffs also available as downloadable cd images? Currently, no, but I hope this to change in the near future. -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal nectar@celabo.org jvidrine@verio.net nectar@freebsd.org nectar@kth.se From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 05:21:07 2003 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 0D49A16A4CE for ; Wed, 26 Nov 2003 05:21:07 -0800 (PST) Received: from dust.freshx.de (freshx.de [80.190.100.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3CA343F3F for ; Wed, 26 Nov 2003 05:21:05 -0800 (PST) (envelope-from kai@freshx.de) Received: from localhost (localhost.freshx.de [127.0.0.1]) by dust.freshx.de (Postfix) with ESMTP id E7A6915E196; Wed, 26 Nov 2003 14:20:59 +0100 (CET) Received: from alpha (p508B2CDC.dip.t-dialin.net [80.139.44.220]) by dust.freshx.de (Postfix) with ESMTP id A663915E12E; Wed, 26 Nov 2003 14:20:58 +0100 (CET) From: "Kai Mosebach" To: "'Terry Lambert'" Date: Wed, 26 Nov 2003 14:21:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <3FC49DA6.54459AD6@mindspring.com> Thread-Index: AcO0GdBlW3u594fMRdKzjRJOLq5GxwABiv8g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Message-Id: <20031126132058.A663915E12E@dust.freshx.de> X-Virus-Scanned: by AMaViS 0.3.12 cc: freebsd-hackers@freebsd.org Subject: AW: getpwnam with md5 encrypted passwds 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, 26 Nov 2003 13:21:07 -0000 > -----Urspr=FCngliche Nachricht----- > Von: Terry Lambert [mailto:tlambert2@mindspring.com] > Gesendet: Mittwoch, 26. November 2003 13:34 > An: sapdb@komadev.de > Cc: freebsd-hackers@freebsd.org > Betreff: Re: getpwnam with md5 encrypted passwds >=20 > "sapdb@komadev.de" wrote: > > i am trying to validate a given user password against my local = passwd- > file with > > this piece of code : > > > > if (!( pwd =3D getpwnam ( user ))) { > > log(ERROR,"User %s not known",user); > > stat=3DNOUSER; > > } > > if (!strcmp( crypt(pass,pwd->pw_name), pwd->pw_passwd) ) { > > log(DEBUG|MISC,"HURRAY : %s authenticated\n", user); > > stat =3D AUTHED; > > } >=20 > I know you have the fix for the crypt of the wrong field, but the > proper thing to do is probably to use pan_authenticate() so that > you are insensitive to the athentication method being used, rather > than crypting and comparing it yourself. >=20 Looks interesting ... is this method also usable, when i dropped my = privs ? cheers From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 06:03:51 2003 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 2367316A4CE for ; Wed, 26 Nov 2003 06:03:51 -0800 (PST) Received: from ns1.sanda.gr.jp (ns1.sanda.gr.jp [219.117.208.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32BAD43FE0 for ; Wed, 26 Nov 2003 06:03:49 -0800 (PST) (envelope-from non@ever.sanda.gr.jp) Received: from oliv.ever.sanda.gr.jp (oliv [10.93.63.4]) by ns1.sanda.gr.jp (8.11.6/3.7W) with ESMTP id hAQE3lr60142 for ; Wed, 26 Nov 2003 23:03:47 +0900 (JST) Received: from localhost (localhost.ever.sanda.gr.jp [127.0.0.1]) by oliv.ever.sanda.gr.jp (8.12.6/8.12.6) with ESMTP id hAQE3lYw025855 for ; Wed, 26 Nov 2003 23:03:47 +0900 (JST) (envelope-from non@ever.sanda.gr.jp) Date: Wed, 26 Nov 2003 23:03:47 +0900 (JST) Message-Id: <20031126.230347.44132984.non@ever.sanda.gr.jp> To: freebsd-hackers@freebsd.org From: non@ever.sanda.gr.jp In-Reply-To: <20031125.232429.11430485.imp@bsdimp.com> References: <20031126021144.GB617@neutrino.bsdhome.com> <20031125.232429.11430485.imp@bsdimp.com> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: puc/sio driver - receives but doesn't send 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, 26 Nov 2003 14:03:51 -0000 From: "M. Warner Losh" Date: Tue, 25 Nov 2003 23:24:29 -0700 (MST) > : Anybody have any ideas what might be wrong? > : > : And yes, the motherboard serial ports both work as expected using the > : same cables, etc. > > I know this is a long shot.... But maybe there's a cold solder joint > on the NetMOS dual UART board? Maybe broken driver IC. If you have a line checker gadget that can see line levels (TXD, RXD, etc.) with LED, you can check whether it really sending data on the cable. // Noriaki Mitsunaga // From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 06:05:36 2003 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 7DB0016A4CE for ; Wed, 26 Nov 2003 06:05:36 -0800 (PST) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 17A5E43F3F for ; Wed, 26 Nov 2003 06:05:34 -0800 (PST) (envelope-from roam@ringlet.net) Received: (qmail 18352 invoked from network); 26 Nov 2003 14:03:52 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 26 Nov 2003 14:03:52 -0000 Received: (qmail 1149 invoked by uid 1000); 26 Nov 2003 14:05:30 -0000 Date: Wed, 26 Nov 2003 16:05:30 +0200 From: Peter Pentchev To: Kai Mosebach Message-ID: <20031126140530.GB307@straylight.m.ringlet.net> Mail-Followup-To: Kai Mosebach , 'Terry Lambert' , freebsd-hackers@freebsd.org References: <3FC49DA6.54459AD6@mindspring.com> <20031126132058.A663915E12E@dust.freshx.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: <20031126132058.A663915E12E@dust.freshx.de> User-Agent: Mutt/1.5.5.1i cc: freebsd-hackers@freebsd.org Subject: Re: getpwnam with md5 encrypted passwds 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, 26 Nov 2003 14:05:36 -0000 --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 26, 2003 at 02:21:04PM +0100, Kai Mosebach wrote: > > -----Urspr?ngliche Nachricht----- > > Von: Terry Lambert [mailto:tlambert2@mindspring.com] > > Gesendet: Mittwoch, 26. November 2003 13:34 > > An: sapdb@komadev.de > > Cc: freebsd-hackers@freebsd.org > > Betreff: Re: getpwnam with md5 encrypted passwds > >=20 > > "sapdb@komadev.de" wrote: > > > i am trying to validate a given user password against my local passwd- > > file with > > > this piece of code : > > > > > > if (!( pwd =3D getpwnam ( user ))) { > > > log(ERROR,"User %s not known",user); > > > stat=3DNOUSER; > > > } > > > if (!strcmp( crypt(pass,pwd->pw_name), pwd->pw_passwd) ) { > > > log(DEBUG|MISC,"HURRAY : %s authenticated\n", user); > > > stat =3D AUTHED; > > > } > >=20 > > I know you have the fix for the crypt of the wrong field, but the > > proper thing to do is probably to use pan_authenticate() so that > > you are insensitive to the athentication method being used, rather > > than crypting and comparing it yourself. > >=20 >=20 > Looks interesting ... is this method also usable, when i dropped my privs= ? I think Terry meant pam_authenticate() (not pan), but to answer your question: no, when you drop your privileges, you do not have access to at least the system's password database (/etc/spwd.db, generated from /etc/passwd and /etc/master.passwd by pwd_mkdb(8)). If this will be any consolation, getpwnam() won't return a password field when you have dropped root privileges either. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net 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 This sentence contains exactly threee erors. --cvVnyQ+4j833TQvp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/xLMq7Ri2jRYZRVMRAmG9AKCpOHdERo0BUJMvmusDW2S92rjpNgCeP20V 68omqPI9792en7UbyxxGhIY= =6Lnj -----END PGP SIGNATURE----- --cvVnyQ+4j833TQvp-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 09:06:08 2003 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 BE1E316A4CE for ; Wed, 26 Nov 2003 09:06:08 -0800 (PST) Received: from gunjin.wccnet.org (gunjin.wccnet.org [198.111.176.99]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2920643FD7 for ; Wed, 26 Nov 2003 09:06:07 -0800 (PST) (envelope-from anthony@gunjin.wccnet.org) Received: from gunjin.wccnet.org (localhost.rexroof.com [127.0.0.1]) by gunjin.wccnet.org (8.12.3/8.12.2) with ESMTP id hAQHBhPf099697; Wed, 26 Nov 2003 12:11:44 -0500 (EST) Received: (from anthony@localhost) by gunjin.wccnet.org (8.12.3/8.12.3/Submit) id hAQHBh19099696; Wed, 26 Nov 2003 12:11:43 -0500 (EST) Date: Wed, 26 Nov 2003 12:11:42 -0500 From: Anthony Schneider To: Dag-Erling =?unknown-8bit?Q?Sm=F8rgrav?= Message-ID: <20031126171142.GA99641@x-anthony.com> References: <20031125153901.GA78725@x-anthony.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: hackers@freebsd.org Subject: Re: freebsd smp -> linux up 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, 26 Nov 2003 17:06:08 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: quoted-printable sadly, all ktrace shows is ktrace launching vmware (from 'ktrace vmware', shows sh reading and executing, and then ends with the vmware fork). is there a special way to ktrace linux binaries that i'm not aware of? -Anthony. On Tue, Nov 25, 2003 at 07:32:35PM +0100, Dag-Erling Sm=F8rgrav wrote: > Anthony Schneider writes: > > is there a way to have linux emulation report that its kernel is running > > on a UP system even though the freebsd box it's running on is SMP? i > > would like to get vmware running on my smp -current box, but vmmon_smp.= ko > > is "broken", and with vmmon_up.ko loaded i get a message about needing = to > > be running on an smp linux kernel version 2.0 (2.2) or higher, even tho= ugh > > linux emulation reports a 2.4 kernel. >=20 > It would be interesting to know exactly what it needs that we don't > provide. I suspect it's something really trivial... do you see any > messages in syslog about unimplemented syscalls? Could you get a > ktrace or something? >=20 > DES > --=20 > Dag-Erling Sm=F8rgrav - des@des.no --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE/xN7OKUeW47UGY2kRAgMqAJ9iC8IgXHCFDLG/bwAa1VaHH/xLkACeOJyn GRHOQ15Zmgn0fIsWDyFQbwI= =yNT/ -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 09:46:20 2003 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 868B716A4CE for ; Wed, 26 Nov 2003 09:46:20 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2804543FE0 for ; Wed, 26 Nov 2003 09:46:18 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 815FF530A; Wed, 26 Nov 2003 18:46:16 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id D53C65309; Wed, 26 Nov 2003 18:46:07 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 7FBAE33C86; Wed, 26 Nov 2003 18:46:07 +0100 (CET) To: Anthony Schneider References: <20031125153901.GA78725@x-anthony.com> <20031126171142.GA99641@x-anthony.com> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Wed, 26 Nov 2003 18:46:07 +0100 In-Reply-To: <20031126171142.GA99641@x-anthony.com> (Anthony Schneider's message of "Wed, 26 Nov 2003 12:11:42 -0500") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: ss X-Spam-Status: No, hits=2.6 required=5.0 tests=RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.60 cc: hackers@freebsd.org Subject: Re: freebsd smp -> linux up 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, 26 Nov 2003 17:46:20 -0000 Anthony Schneider writes: > sadly, all ktrace shows is ktrace launching vmware (from 'ktrace vmware', > shows sh reading and executing, and then ends with the vmware fork). > > is there a special way to ktrace linux binaries that i'm not aware of? None is required; you just have to use either -d or -i for ktrace to trace children processes as well. I can never remember which one it is, so I use both :) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 11:21:28 2003 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 BE7D716A4CE for ; Wed, 26 Nov 2003 11:21:28 -0800 (PST) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C96E843F75 for ; Wed, 26 Nov 2003 11:21:27 -0800 (PST) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id hAQJLQkX057761; Wed, 26 Nov 2003 11:21:27 -0800 (PST) (envelope-from kientzle@acm.org) Message-ID: <3FC4FD34.2060807@acm.org> Date: Wed, 26 Nov 2003 11:21:24 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sapdb@komadev.de" References: <1069810210.3fc40222e2bca@localhost> In-Reply-To: <1069810210.3fc40222e2bca@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: getpwnam with md5 encrypted passwds X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 19:21:28 -0000 sapdb@komadev.de wrote: > Hi, > > i am trying to validate a given user password against my local passwd-file with > this piece of code : > > if (!strcmp( crypt(pass,pwd->pw_name), pwd->pw_passwd) ) { The second argument to crypt here should be pwd->pw_passwd. Otherwise, this doesn't work even with DES-encrypted passwords. The first part of any encrypted password is the 'salt', which effectively indicates how that password is encrypted. You need to give the encrypted password to crypt so it knows which encryption to use for the plaintext. Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 13:20:19 2003 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 9E3E716A4CE for ; Wed, 26 Nov 2003 13:20:19 -0800 (PST) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9362A43F75 for ; Wed, 26 Nov 2003 13:20:18 -0800 (PST) (envelope-from cliftonr@lava.net) Received: by malasada.lava.net (Postfix, from userid 102) id 72BBE15410F; Wed, 26 Nov 2003 11:20:15 -1000 (HST) Date: Wed, 26 Nov 2003 11:20:14 -1000 From: Clifton Royston To: freebsd-hackers@freebsd.org Message-ID: <20031126112014.C8040@tikitechnologies.com> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20031126200101.8B45116A4D0@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031126200101.8B45116A4D0@hub.freebsd.org>; 12:01:01PM -0800 Subject: Re: getpwnam with md5 encrypted passwds 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, 26 Nov 2003 21:20:19 -0000 On Wed, Nov 26, 2003 at 12:01:01PM -0800, freebsd-hackers-request@freebsd.org wrote: > Date: Wed, 26 Nov 2003 16:05:30 +0200 > From: Peter Pentchev > Subject: Re: getpwnam with md5 encrypted passwds > To: Kai Mosebach > Cc: freebsd-hackers@freebsd.org > Message-ID: <20031126140530.GB307@straylight.m.ringlet.net> > Content-Type: text/plain; charset="windows-1251" > > On Wed, Nov 26, 2003 at 02:21:04PM +0100, Kai Mosebach wrote: > > > -----Urspr?ngliche Nachricht----- > > > Von: Terry Lambert [mailto:tlambert2@mindspring.com] > > > Gesendet: Mittwoch, 26. November 2003 13:34 > > > An: sapdb@komadev.de > > > Cc: freebsd-hackers@freebsd.org > > > Betreff: Re: getpwnam with md5 encrypted passwds > > > > > > "sapdb@komadev.de" wrote: > > > > i am trying to validate a given user password against my local passwd- > > > file with > > > > this piece of code : ... > > > I know you have the fix for the crypt of the wrong field, but the > > > proper thing to do is probably to use pan_authenticate() so that > > > you are insensitive to the athentication method being used, rather > > > than crypting and comparing it yourself. > > > > Looks interesting ... is this method also usable, when i dropped my privs ? > > I think Terry meant pam_authenticate() (not pan), but to answer your > question: no, when you drop your privileges, you do not have access to > at least the system's password database (/etc/spwd.db, generated from > /etc/passwd and /etc/master.passwd by pwd_mkdb(8)). If this will be any > consolation, getpwnam() won't return a password field when you have > dropped root privileges either. If you will need to do authentication after your program drops privileges, your best course is probably to go through PAM, to install a separate daemon which implements a PAM-supported protocol and which runs with privileges, and then to enable that protocol as a PAM authentication method for your application. For example, you can install a RADIUS server bound to localhost which runs as root and authenticates against the master password file. Configure the necessary /etc files for pam_radius as described in its man pages, and then add "pam_radius" as an authentication method in /etc/pam.conf for your application. Now you do need to make your application go through the PITA required to be a PAM client, but it can at least authenticate without needing root privileges itself. I implemented this pretty recently, so I know the approach works, even if it may seem rather roundabout. (LDAP would be another PAM-supported option, but RADIUS seemed simpler to set up in a hurry.) -- Clifton -- Clifton Royston -- cliftonr@tikitechnologies.com Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 15:30:49 2003 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 CF9F616A4CE for ; Wed, 26 Nov 2003 15:30:49 -0800 (PST) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F79443FA3 for ; Wed, 26 Nov 2003 15:30:48 -0800 (PST) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id hAQNUleC052267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Nov 2003 18:30:47 -0500 (EST) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id hAQNUluR052266 for freebsd-hackers@freebsd.org; Wed, 26 Nov 2003 18:30:47 -0500 (EST) Date: Wed, 26 Nov 2003 18:30:47 -0500 From: Leo Bicknell To: freebsd-hackers@freebsd.org Message-ID: <20031126233047.GA52107@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: healthd oddities 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, 26 Nov 2003 23:30:49 -0000 With my FreeBSD current system I decided to try healthd again, it didn't work with my previous motherboard. It seems to work with my new motherboard (Intel Serverworks of some sort, I can get a model number later if it matters), however all the numbers are just out of range. Pardon the HTML, but it's the easiest way to get them labeled: # healthdc -H 10.42.42.1 Content-type: text/html healthd

10.42.42.1

Chip Set Temperature255.0
CPU #0 Temperature 0.0
CPU #1 Temperature 0.0
CPU #0 Cooling Fan0000
CPU #1 Cooling Fan0000
Case Fan Cooling Fan0000
CPU #0 Core Voltage4.08
CPU #1 Core Voltage4.08
3.3 Volt4.08
5 Volt6.85
12 Volt15.50
-12 Volt-14.16
-5 Volt-6.12
Note 3.3 volt is 4.08, 5 volt is 6.85, etc. The system is not over clocking or doing anything else wierd. They are enough out of range healthd warns on them by default to syslog. Anyone seen this before? Do I have a problem I didn't know I had? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 17:57:49 2003 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 D500F16A4CE for ; Wed, 26 Nov 2003 17:57:49 -0800 (PST) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 094ED43F3F for ; Wed, 26 Nov 2003 17:57:48 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from localhost (localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.9/8.12.8) with ESMTP id hAR1vghk003802; Thu, 27 Nov 2003 12:27:43 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Leo Bicknell , freebsd-hackers@freebsd.org Date: Thu, 27 Nov 2003 12:27:41 +1030 User-Agent: KMail/1.5.3 References: <20031126233047.GA52107@ussenterprise.ufp.org> In-Reply-To: <20031126233047.GA52107@ussenterprise.ufp.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311271227.41164.doconnor@gsoft.com.au> X-Spam-Score: -4.4 () CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: Re: healthd oddities 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, 27 Nov 2003 01:57:49 -0000 On Thursday 27 November 2003 10:00, Leo Bicknell wrote: > Note 3.3 volt is 4.08, 5 volt is 6.85, etc. The system is not over > clocking or doing anything else wierd. They are enough out of range > healthd warns on them by default to syslog. > > Anyone seen this before? Do I have a problem I didn't know I had? It's probably healthd not processing the data it gets properly, and also possibly the data being used with the wrong label. Unfortunately it seems really really difficult to discover how a motherboard is wired up in this regard automatically :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 22:13:23 2003 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 23ED216A4CE for ; Wed, 26 Nov 2003 22:13:23 -0800 (PST) Received: from mail.uninterruptible.net (mail.uninterruptible.net [64.146.146.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B28843F75 for ; Wed, 26 Nov 2003 22:13:20 -0800 (PST) (envelope-from kris@catonic.net) Received: from Spaz.Catonic.NET (tnt6-216-180-4-94.dialup.hiwaay.net [216.180.4.94]) by mail.uninterruptible.net (Postfix) with ESMTP id 28A5050085 for ; Thu, 27 Nov 2003 06:13:20 +0000 (GMT) Received: by Spaz.Catonic.NET (Postfix, from userid 1002) id 5005A336B; Thu, 27 Nov 2003 06:13:17 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by Spaz.Catonic.NET (Postfix) with ESMTP id 4B9FD4C6C for ; Thu, 27 Nov 2003 06:13:17 +0000 (GMT) Date: Thu, 27 Nov 2003 06:13:17 +0000 (GMT) From: Kris Kirby To: freebsd-hackers@freebsd.org Message-ID: X-Mailer: !/bin/sh MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: NFS Flags Oddity 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, 27 Nov 2003 06:13:23 -0000 FreeBSD (4.9-RC) doesn't appear to "export" schg flags over NFS. You've got to shell in locally to the machine to move the schg flags; ls -lao doesn't report them over NFS, but does list them locally. -- Kris Kirby, KE4AHR TGIFreeBSD IM: 'KrisBSD' "BIG BROTHER IS WATCHING YOU!" This message brought to you by the US Department of Homeland Security From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 26 22:53:10 2003 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 3E32016A4CF for ; Wed, 26 Nov 2003 22:53:10 -0800 (PST) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEB2E43FA3 for ; Wed, 26 Nov 2003 22:53:07 -0800 (PST) (envelope-from doconnor@gsoft.com.au) Received: from localhost (localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.9/8.12.8) with ESMTP id hAR6qlhk027515; Thu, 27 Nov 2003 17:22:47 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Kris Kirby , freebsd-hackers@freebsd.org Date: Thu, 27 Nov 2003 17:22:45 +1030 User-Agent: KMail/1.5.3 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311271722.45961.doconnor@gsoft.com.au> X-Spam-Score: -4.4 () CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: Re: NFS Flags Oddity 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, 27 Nov 2003 06:53:10 -0000 On Thursday 27 November 2003 16:43, Kris Kirby wrote: > FreeBSD (4.9-RC) doesn't appear to "export" schg flags over NFS. You've > got to shell in locally to the machine to move the schg flags; ls -lao > doesn't report them over NFS, but does list them locally. I didn't think flags were a concept NFS understood.. (And hence why you should NFS mount /usr/src & /usr/obj to install kernels, not mount the dest machine on the server and use DESTDIR=) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 27 01:36:13 2003 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 C4D9A16A4CE for ; Thu, 27 Nov 2003 01:36:13 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05D1343FAF for ; Thu, 27 Nov 2003 01:36:13 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-38lc14c.dialup.mindspring.com ([209.86.4.140] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1APIZH-00069k-00; Thu, 27 Nov 2003 01:36:12 -0800 Message-ID: <3FC5A349.3FCA4DE9@mindspring.com> Date: Wed, 26 Nov 2003 23:10:01 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Clifton Royston References: <20031126200101.8B45116A4D0@hub.freebsd.org> <20031126112014.C8040@tikitechnologies.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47de339922189b2d1e181606913311aa5387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: getpwnam with md5 encrypted passwds 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, 27 Nov 2003 09:36:13 -0000 Clifton Royston wrote: > If you will need to do authentication after your program drops > privileges, your best course is probably to go through PAM, to install > a separate daemon which implements a PAM-supported protocol and which > runs with privileges, and then to enable that protocol as a PAM > authentication method for your application. [ ... RADIUS example with LDAP mention ... ] Sounds like a good approach, though I'll point out that had you tried LDP, you would have been hard-put to use LDAP as a proxy protocol to another authentication base (a PAM backend for an LDAP server, while not quite impossible, would be very hard). How did you avoid the recursion problem of the RADIUS server trying to authenticate via pam_radius to the RADIUS server tyring to authenticate ... -- Terry? From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 27 01:36:16 2003 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 21B4716A4CE for ; Thu, 27 Nov 2003 01:36:16 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55D3343FAF for ; Thu, 27 Nov 2003 01:36:15 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-38lc14c.dialup.mindspring.com ([209.86.4.140] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1APIZB-000697-00; Thu, 27 Nov 2003 01:36:06 -0800 Message-ID: <3FC59F4C.AE917AB8@mindspring.com> Date: Wed, 26 Nov 2003 22:53:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Pentchev References: <3FC49DA6.54459AD6@mindspring.com> <20031126132058.A663915E12E@dust.freshx.de> <20031126140530.GB307@straylight.m.ringlet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47de339922189b2d1b9797e07377d12da93caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Kai Mosebach Subject: Re: getpwnam with md5 encrypted passwds 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, 27 Nov 2003 09:36:16 -0000 Peter Pentchev wrote: > On Wed, Nov 26, 2003 at 02:21:04PM +0100, Kai Mosebach wrote: > > Looks interesting ... is this method also usable, when i dropped my privs ? > > I think Terry meant pam_authenticate() (not pan), but to answer your > question: no, when you drop your privileges, you do not have access to > at least the system's password database (/etc/spwd.db, generated from > /etc/passwd and /etc/master.passwd by pwd_mkdb(8)). If this will be any > consolation, getpwnam() won't return a password field when you have > dropped root privileges either. Peter is correct on both counts. If I had not sen his reply first, I would have made the same reply. You cannot crypt something you cannot read. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 27 01:36:33 2003 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 9ECA716A4CE for ; Thu, 27 Nov 2003 01:36:33 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id E05E543F3F for ; Thu, 27 Nov 2003 01:36:32 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-38lc14c.dialup.mindspring.com ([209.86.4.140] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1APIZV-0006AD-00; Thu, 27 Nov 2003 01:36:26 -0800 Message-ID: <3FC5A552.A0BF28F5@mindspring.com> Date: Wed, 26 Nov 2003 23:18:42 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kirby References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47de339922189b2d189b25917fcb3530ea7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: NFS Flags Oddity 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, 27 Nov 2003 09:36:33 -0000 Kris Kirby wrote: > FreeBSD (4.9-RC) doesn't appear to "export" schg flags over NFS. You've > got to shell in locally to the machine to move the schg flags; ls -lao > doesn't report them over NFS, but does list them locally. Non-local flags are not defined, so they are not permitted to be exported over NFS. You'll find the same thing with the number of bits in major and minor number, etc.. For a long time (until Julian added the first devfs to FreeBSD), it was not possible to NFS-boot a FreeBSD box off of e.g. an Alpha running TRU64 UNIX, for example. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 27 01:37:53 2003 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 4683B16A4D1 for ; Thu, 27 Nov 2003 01:37:53 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3218143FEA for ; Thu, 27 Nov 2003 01:37:50 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-38lc14c.dialup.mindspring.com ([209.86.4.140] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1APIan-0006IS-00; Thu, 27 Nov 2003 01:37:46 -0800 Message-ID: <3FC59F4C.AE917AB8@mindspring.com> Date: Wed, 26 Nov 2003 22:53:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Pentchev References: <3FC49DA6.54459AD6@mindspring.com> <20031126132058.A663915E12E@dust.freshx.de> <200311X-Mozilla-Status: 0009ght.m.ringlet.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47de339922189b2d1a325963caaa73e1f387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: Kai Mosebach Subject: Re: getpwnam with md5 encrypted passwds 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, 27 Nov 2003 09:37:53 -0000 Peter Pentchev wrote: > On Wed, Nov 26, 2003 at 02:21:04PM +0100, Kai Mosebach wrote: > > Looks interesting ... is this method also usable, when i dropped my privs ? > > I think Terry meant pam_authenticate() (not pan), but to answer your > question: no, when you drop your privileges, you do not have access to > at least the system's password database (/etc/spwd.db, generated from > /etc/passwd and /etc/master.passwd by pwd_mkdb(8)). If this will be any > consolation, getpwnam() won't return a password field when you have > dropped root privileges either. Peter is correct on both counts. If I had not sen his reply first, I would have made the same reply. You cannot crypt something you cannot read. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 27 01:37:55 2003 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 7895716A4CF for ; Thu, 27 Nov 2003 01:37:55 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id B925343FDD for ; Thu, 27 Nov 2003 01:37:54 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-38lc14c.dialup.mindspring.com ([209.86.4.140] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1APIav-0006Ii-00; Thu, 27 Nov 2003 01:37:53 -0800 Message-ID: <3FC5A349.3FCA4DE9@mindspring.com> Date: Wed, 26 Nov 2003 23:10:01 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Clifton Royston References: <20031126200101.8B45116A4D0@hub.freebsd.org> <20031126112014.C8040@tikitechnologies.com> ConteX-Mozilla-Status: 0009harset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47de339922189b2d1391a49eed8547b63a8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: getpwnam with md5 encrypted passwds 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, 27 Nov 2003 09:37:55 -0000 Clifton Royston wrote: > If you will need to do authentication after your program drops > privileges, your best course is probably to go through PAM, to install > a separate daemon which implements a PAM-supported protocol and which > runs with privileges, and then to enable that protocol as a PAM > authentication method for your application. [ ... RADIUS example with LDAP mention ... ] Sounds like a good approach, though I'll point out that had you tried LDP, you would have been hard-put to use LDAP as a proxy protocol to another authentication base (a PAM backend for an LDAP server, while not quite impossible, would be very hard). How did you avoid the recursion problem of the RADIUS server trying to authenticate via pam_radius to the RADIUS server tyring to authenticate ... -- Terry? From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 27 01:37:59 2003 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 C3F9D16A4CF for ; Thu, 27 Nov 2003 01:37:59 -0800 (PST) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 956B443FDF for ; Thu, 27 Nov 2003 01:37:58 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-38lc14c.dialup.mindspring.com ([209.86.4.140] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1APIaz-0006J8-00; Thu, 27 Nov 2003 01:37:58 -0800 Message-ID: <3FC5A552.A0BF28F5@mindspring.com> Date: Wed, 26 Nov 2003 23:18:42 -0800 From: Terry Lambert X-Accept-Language: en MIME-Version: 1.0 To: Kris Kirby References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47de339922189b2d114331bdca042545c3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: NFS Flags Oddity 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, 27 Nov 2003 09:37:59 -0000 Kris Kirby wrote: > FreeBSD (4.9-RC) doesn't appear to "export" schg flags over NFS. You've > got to shell in locally to the machine to move the schg flags; ls -lao > doesn't report them over NFS, but does list them locally. Non-local flags are not defined, so they are not permitted to be exported over NFS. You'll find the same thing with the number of bits in major and minor number, etc.. For a long time (until Julian added the first devfs to FreeBSD), it was not possible to NFS-boot a FreeBSD box off of e.g. an Alpha running TRU64 UNIX, for example. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 27 03:25:41 2003 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 0ED1616A4CE for ; Thu, 27 Nov 2003 03:25:41 -0800 (PST) Received: from peedub.jennejohn.org (p213.54.229.155.tisdip.tiscali.de [213.54.229.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AE9843FE5 for ; Thu, 27 Nov 2003 03:25:39 -0800 (PST) (envelope-from garyj@jennejohn.org) Received: from peedub.jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.12.10/8.11.6) with ESMTP id hARBPTaF001704; Thu, 27 Nov 2003 12:25:30 +0100 (CET) (envelope-from garyj@peedub.jennejohn.org) Message-Id: <200311271125.hARBPTaF001704@peedub.jennejohn.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Eduard Martinescu In-Reply-To: Message from Eduard Martinescu <1069700517.4505.0.camel@firestorm.crafts4life.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Nov 2003 12:25:29 +0100 From: Gary Jennejohn cc: freebsd-hackers@freebsd.org Subject: Re: [Fwd: TWE driver IOCTL's] 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, 27 Nov 2003 11:25:41 -0000 Eduard Martinescu writes: > Tried this on current, but no responses...maybe some one here has some ideas? > > Hello, > > I looking to extend the smartmontools support > (/usr/ports/sysutils/smartmontools) to include support for drives behind > a TWE device. > > I looked at the source for the TWE driver, and it seems to support what > I need....not sure yet, as the linux version use the ATA Passthru > IOCTL. At any rate, there does not appear to be any twe.h include files > installed into /usr/include anywhere for my program to be able to pick > the correct definitions. Is this just an oversight? Or did I miss > something? > Looks like an oversight. It seems that /sys/dev/twe/tweio.h should get installed into /usr/include/sys. Maybe /sys/dev/twe/twereg.h too, since that's where TWE_Command is defined, although not everything in there seems like it should be visible to the user. --- Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org gj[at]denx.de From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 27 07:47:41 2003 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 C171516A4CE for ; Thu, 27 Nov 2003 07:47:41 -0800 (PST) Received: from dot.freshdot.net (dot.freshdot.net [195.64.80.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43D8C43FE5 for ; Thu, 27 Nov 2003 07:47:40 -0800 (PST) (envelope-from ssm+fbsd-hack@freshdot.net) Received: from ssmeenk by dot.freshdot.net with local (Exim 4.24) id 1APOMl-0003Ma-EN for freebsd-hackers@freebsd.org; Thu, 27 Nov 2003 16:47:39 +0100 Date: Thu, 27 Nov 2003 16:47:39 +0100 From: Sander Smeenk To: freebsd-hackers@freebsd.org Message-ID: <20031127154739.GD24772@freshdot.net> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: ahd driver & Adaptec 39320D Ultra320 SCSI adapter 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, 27 Nov 2003 15:47:42 -0000 Hi, I mailed to fbsd-questions about a weird problem i was experiencing with RAID10 on vinum, with 4 SCSI disks connected to an Adaptec 39320D U320 SCSI adapter, and stated that it had boot problems, but they seemed to occur only at boot, not during usage. I was wrong. The card is unstable in FreeBSD 4.9-release. Not only does the SCSI interface timeout on occasion, vinum also seems to crash the entire system with a kernel panic. I googled on "pci error interrupt" "card was paused", but no helpful results turned up. Is anyone aware of this problem? Who should I contact to report this, or does anyone know what the solution for this problem is? I'd really like to get it fixed. Let me know if you need more information regarding this matter. Below are some relevant parts from dmesg, during boot: | ahd0: port 0x7000-0x70ff,0x7400-0x74ff mem 0xfc200000-0xfc201fff irq 10 at device 1.0 on pci3 | aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs | ahd1: port 0x7800-0x78ff,0x7c00-0x7cff mem 0xfc202000-0xfc203fff irq 10 at device 1.1 on pci3 | aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs [ .. later on in the boot process .. ] | ahd1: PCI error Interrupt | >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< | ahd1: Dumping Card State at program address 0x94 Mode 0x22 | Card was paused | HS_MAILBOX[0x0] INTCTL[0x0] SEQINTSTAT[0x0] SAVED_MODE[0x0] | DFFSTAT[0x30]:(CURRFIFO_0|FIFO0FREE|FIFO1FREE) SCSISIGI[0x0]:(P_DATAOUT) | SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) | SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) | SEQCTL0[0x10]:(FASTMODE) SEQINTCTL[0x80]:(INTVEC1DSL) | SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] SSTAT0[0x0] SSTAT1[0x8]:(BUSFREE) | SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) | LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] | LQOSTAT1[0x0] LQOSTAT2[0x0] | | SCB Count = 16 CMDS_PENDING = 0 LASTSCB 0xffff CURRSCB 0x0 NEXTSCB 0x0 | qinstart = 0 qinfifonext = 0 | QINFIFO: | WAITING_TID_QUEUES: | Pending list: | Total 0 | Kernel Free SCB list: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 | Sequencer Complete DMA-inprog list: | Sequencer Complete list: | Sequencer DMA-Up and Complete list: | | ahd1: FIFO0 Free, LONGJMP == 0x80ff, SCB 0x0 | SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) | SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) | SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] | SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 | HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) | ahd1: FIFO1 Free, LONGJMP == 0x80ff, SCB 0x0 | SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) | SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) | SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] | SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 | HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) | LQIN: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 | ahd1: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 | ahd1: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x0 | | SIMODE0[0x6c]:(ENOVERRUN|ENIOERR|ENSELDI|ENSELDO) | CCSCBCTL[0x0] | ahd1: REG0 == 0x3533, SINDEX = 0x33, DINDEX = 0x0 | ahd1: SCBPTR == 0x0, SCB_NEXT == 0xff00, SCB_NEXT2 == 0x0 | CDB 0 0 0 0 0 0 | STACK: 0x1 0x8 0x7 0x6 0x5 0x4 0x3 0x29 | >>>>>>>>>>>>>>>>> | ahd1: Signaled Target Abort Thanks in advance, Sander. -- | A box withouth hinges, key, or lid, yet golden treasure inside is hid. | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 27 09:26:02 2003 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 5796B16A4CE for ; Thu, 27 Nov 2003 09:26:02 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19D9B43FB1 for ; Thu, 27 Nov 2003 09:26:01 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id hARHNQMg032824; Thu, 27 Nov 2003 12:23:26 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)hARHNPBJ032821; Thu, 27 Nov 2003 12:23:26 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 27 Nov 2003 12:23:25 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Anthony Schneider In-Reply-To: <20031126171142.GA99641@x-anthony.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: Dag-Erling =?unknown-8bit?Q?Sm=F8rgrav?= cc: hackers@freebsd.org Subject: Re: freebsd smp -> linux up 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, 27 Nov 2003 17:26:02 -0000 On Wed, 26 Nov 2003, Anthony Schneider wrote: > sadly, all ktrace shows is ktrace launching vmware (from 'ktrace > vmware', shows sh reading and executing, and then ends with the vmware > fork).=20 >=20 > is there a special way to ktrace linux binaries that i'm not aware of?=20 ktrace should work fine, but you need to make sure you use the linux_kdump port so that the system call trace is interpreted correctly when converted to text. As DES points out, make sure you have the right flags to the ktrace command so tracing is inheritted across fork and exec. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories >=20 > -Anthony. >=20 > On Tue, Nov 25, 2003 at 07:32:35PM +0100, Dag-Erling Sm=F8rgrav wrote: > > Anthony Schneider writes: > > > is there a way to have linux emulation report that its kernel is runn= ing > > > on a UP system even though the freebsd box it's running on is SMP? i > > > would like to get vmware running on my smp -current box, but vmmon_sm= p.ko > > > is "broken", and with vmmon_up.ko loaded i get a message about needin= g to > > > be running on an smp linux kernel version 2.0 (2.2) or higher, even t= hough > > > linux emulation reports a 2.4 kernel. > >=20 > > It would be interesting to know exactly what it needs that we don't > > provide. I suspect it's something really trivial... do you see any > > messages in syslog about unimplemented syscalls? Could you get a > > ktrace or something? > >=20 > > DES > > --=20 > > Dag-Erling Sm=F8rgrav - des@des.no >=20 From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 27 10:26:35 2003 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 5430016A4CE for ; Thu, 27 Nov 2003 10:26:35 -0800 (PST) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id F153643FE3 for ; Thu, 27 Nov 2003 10:26:32 -0800 (PST) (envelope-from cliftonr@lava.net) Received: by malasada.lava.net (Postfix, from userid 102) id 597D1153985; Thu, 27 Nov 2003 08:26:32 -1000 (HST) Date: Thu, 27 Nov 2003 08:26:32 -1000 From: Clifton Royston To: Terry Lambert Message-ID: <20031127082632.A27927@tikitechnologies.com> Mail-Followup-To: Terry Lambert , freebsd-hackers@freebsd.org References: <20031126200101.8B45116A4D0@hub.freebsd.org> <20031126112014.C8040@tikitechnologies.com> <3FC5A349.3FCA4DE9@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3FC5A349.3FCA4DE9@mindspring.com>; from tlambert2@mindspring.com on Wed, Nov 26, 2003 at 11:10:01PM -0800 cc: freebsd-hackers@freebsd.org Subject: Re: getpwnam with md5 encrypted passwds 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, 27 Nov 2003 18:26:35 -0000 On Wed, Nov 26, 2003 at 11:10:01PM -0800, Terry Lambert wrote: > Clifton Royston wrote: > > If you will need to do authentication after your program drops > > privileges, your best course is probably to go through PAM, to install > > a separate daemon which implements a PAM-supported protocol and which > > runs with privileges, and then to enable that protocol as a PAM > > authentication method for your application. > > [ ... RADIUS example with LDAP mention ... ] > > Sounds like a good approach, though I'll point out that had > you tried LDP, you would have been hard-put to use LDAP as a > proxy protocol to another authentication base (a PAM backend > for an LDAP server, while not quite impossible, would be very > hard). Glad I went with my gut feeling rather than wasting a lot of time looking into it then... > How did you avoid the recursion problem of the RADIUS server > trying to authenticate via pam_radius to the RADIUS server > tyring to authenticate ... That is avoided two ways, either of which would do to prevent the deadly recursion. First the RADIUS server (FreeRadius) is currently set up to implement "Unix auth" directly against spwd.db, not via PAM. Second, it's not enabled as the default PAM authentication method for all applications, only for some specific application tokens. We have an intention to add to the application auth against some separate non-password db files, followed by OTP support down the road. Hopefully as it uses PAM both should now be relatively easy. -- Clifton -- Clifton Royston -- cliftonr@tikitechnologies.com Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 27 11:23:01 2003 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 685D516A4CE for ; Thu, 27 Nov 2003 11:23:01 -0800 (PST) Received: from mwinf0302.wanadoo.fr (smtp3.wanadoo.fr [193.252.22.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8798E43FA3 for ; Thu, 27 Nov 2003 11:23:00 -0800 (PST) (envelope-from rmkml@wanadoo.fr) Received: from [192.168.1.2] (AVelizy-109-1-3-170.w217-128.abo.wanadoo.fr [217.128.40.170]) by mwinf0302.wanadoo.fr (SMTP Server) with ESMTP id 2A026C00034F for ; Thu, 27 Nov 2003 20:22:59 +0100 (CET) Date: Thu, 27 Nov 2003 20:20:04 +0100 (CET) From: rmkml X-X-Sender: rmkml@hp.mgn.net To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: question about _exit() function 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, 27 Nov 2003 19:23:01 -0000 Hi, is the _exit() function safe for a thread ? my program use vfork() and then execve in a thread context. The documentation mentions that the process has to call _exit() in case of failure. But this _exit() is really safe for the parent thread ? Thanks in advance for the reply. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 27 11:29:41 2003 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 8DD9816A4CE for ; Thu, 27 Nov 2003 11:29:41 -0800 (PST) Received: from mwinf0401.wanadoo.fr (smtp4.wanadoo.fr [193.252.22.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 767A543F3F for ; Thu, 27 Nov 2003 11:29:40 -0800 (PST) (envelope-from rmkml@wanadoo.fr) Received: from [192.168.1.2] (AVelizy-109-1-3-170.w217-128.abo.wanadoo.fr [217.128.40.170]) by mwinf0401.wanadoo.fr (SMTP Server) with ESMTP id 0966C580031E for ; Thu, 27 Nov 2003 20:29:39 +0100 (CET) Date: Thu, 27 Nov 2003 20:26:44 +0100 (CET) From: rmkml X-X-Sender: rmkml@hp.mgn.net To: freebsd-hackers@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: question about _exit() function 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, 27 Nov 2003 19:29:41 -0000 and I use freebsd v4.8. On Thu, 27 Nov 2003, rmkml wrote: > Date: Thu, 27 Nov 2003 20:20:04 +0100 (CET) > From: rmkml > To: freebsd-hackers@freebsd.org > Subject: question about _exit() function > > Hi, > > is the _exit() function safe for a thread ? > my program use vfork() and then execve in a thread context. > The documentation mentions that the process has to call _exit() in case > of failure. > But this _exit() is really safe for the parent thread ? > > Thanks in advance for the reply. > _______________________________________________ > 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 Nov 28 00:14:51 2003 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 A809716A4CE; Fri, 28 Nov 2003 00:14:51 -0800 (PST) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8E6643FAF; Fri, 28 Nov 2003 00:14:50 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 596F55B6D4; Fri, 28 Nov 2003 00:14:49 -0800 (PST) From: Wes Peters Organization: Softweyr To: "Poul-Henning Kamp" , Stefan =?iso-8859-1?q?E=DFer?= Date: Fri, 28 Nov 2003 00:14:49 -0800 User-Agent: KMail/1.5.4 References: <32476.1069741443@critter.freebsd.dk> In-Reply-To: <32476.1069741443@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311280014.49356.wes@softweyr.com> cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 28 Nov 2003 08:14:51 -0000 On Monday 24 November 2003 10:24 pm, Poul-Henning Kamp wrote: > In message <20031124235738.GA4107@StefanEsser.FreeBSD.org>, Stefan > =?iso-8859-1 > > >And that is what this thread is about: Secure removal of data from > >storage media. There definitely is a difference between RLL (as in > >1,7i RLL) and modern PRML drives under this aspect. > > No there isn't. > > It's been proven again and again that you cannot reliably overwrite > data on a magnetic media. In particular the difference in read/write > geometry and lack of fine control over head placement makes this > impossible. > > The only reliable way to loose data is to encrypt them and throw the > key away. This is the conclusion I came to after pushing the idea around for months. If you want an interesting problem to work on, come up with a solution to the keying problem for disk encryption. It somehow needs to allow automated, unattended reboots during "normal" operations but prevent attackers from compromising the system. Maybe you could have the system send an SMS message when it needs a key, you reply with a one-time key from your mobile phone? While you're in there, paint that bikeshed blue. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 28 03:43:35 2003 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 8C65316A4CE; Fri, 28 Nov 2003 03:43:35 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1436F43F93; Fri, 28 Nov 2003 03:43:34 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id hASBhUgS007305; Fri, 28 Nov 2003 12:43:31 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Wes Peters From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 28 Nov 2003 00:14:49 PST." <200311280014.49356.wes@softweyr.com> Date: Fri, 28 Nov 2003 12:43:30 +0100 Message-ID: <7304.1070019810@critter.freebsd.dk> cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 28 Nov 2003 11:43:35 -0000 In message <200311280014.49356.wes@softweyr.com>, Wes Peters writes: >If you want an interesting problem to work on, come up with a solution to >the keying problem for disk encryption. It somehow needs to allow >automated, unattended reboots during "normal" operations but prevent >attackers from compromising the system. Maybe you could have the system >send an SMS message when it needs a key, you reply with a one-time key >from your mobile phone? I have already described one solution to this in my GBDE paper at BSDcon. You use weak-link/strong-link setups for that: Put the computer and a small UPS (5 minutes) in a good quality safe, drill a tiny hole in it, through which you run the power cord and a fiberoptic network connection. Put serious violation sensors *inside* the safe: corner integrity, door opening, tilt, humidity, mositure, temperature, pressure, gas, smoke, vibration. In addition put serious sensors on the network connection: packet filters, monitor the media state, wrong password attempts, significant changes in trafic level etc etc. As long as the violation sensors don't trigger (the weak link) the safe protects the keys (the strong link). If any of these sensors trip, if the safe is rocked, gets warmer, if the external power disappears, if the network connection looses connection, if somebody attempts to enter with a wrong sshd password, the computer *immediately* nukes its keys and other sensitive material and turns itself off, after which a breach of the strong link is no longer a risk to the data. Now *that* is a DIY project for the dedicated hobbyist :-) The terminology and principle, is from atomic weapons which have a similar security profile: http://nuclearweaponarchive.org/Usa/Weapons/Pal.html enjoy -- 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 Nov 28 04:46:53 2003 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 92ECA16A4CE for ; Fri, 28 Nov 2003 04:46:53 -0800 (PST) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03E1343F85 for ; Fri, 28 Nov 2003 04:46:52 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfjun.dialup.mindspring.com ([165.247.207.215] helo=mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1APi1K-0001vV-00; Fri, 28 Nov 2003 04:46:50 -0800 Message-ID: <3FC743A7.DC5461EA@mindspring.com> Date: Fri, 28 Nov 2003 04:46:31 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rmkml References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4f630b6773801f956d0912bf49314f0e0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: question about _exit() function 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, 28 Nov 2003 12:46:53 -0000 rmkml wrote: > is the _exit() function safe for a thread ? > my program use vfork() and then execve in a thread context. > The documentation mentions that the process has to call _exit() in case > of failure. > But this _exit() is really safe for the parent thread ? The behaviour is undefined in the failure case, but only if you have stablishd a pthread_atfork() handler that does anything in the child. In general, the more correct approach is to use posix_spawn(), but FreeBSD doesn't support posix_spawn() (funny; this has come up now twice in within 60 messages of each other, while ther was a very long time when it was not pertinent at all...). POSIX also sriously discourages the use of vfork(), and recommends fork() instead, for threaded programs. Note that the fork() only *ever* creates a single thread, so it will only replicate the currently running thread and its address space, rather than all currently running threads in the parent. You said in another message that this is on 4.8. I think that the behaviour will not be quite what you expect, in that case, and that it'll be better in -current, but might still not be what you expect there, either (depends on what you are expecting). See also: http://www.opengroup.org/onlinepubs/007904975/functions/fork.html -- Terry From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 28 06:51:44 2003 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 D7AAB16A4CE for ; Fri, 28 Nov 2003 06:51:44 -0800 (PST) Received: from mwinf0801.wanadoo.fr (smtp8.wanadoo.fr [193.252.22.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id B79C043FA3 for ; Fri, 28 Nov 2003 06:51:43 -0800 (PST) (envelope-from rmkml@wanadoo.fr) Received: from [192.168.1.2] (AVelizy-109-1-2-209.w80-14.abo.wanadoo.fr [80.14.9.209]) by mwinf0801.wanadoo.fr (SMTP Server) with ESMTP id 35FF018000B0; Fri, 28 Nov 2003 15:51:42 +0100 (CET) Date: Fri, 28 Nov 2003 15:48:46 +0100 (CET) From: rmkml X-X-Sender: rmkml@hp.mgn.net To: Terry Lambert In-Reply-To: <3FC743A7.DC5461EA@mindspring.com> Message-ID: References: <3FC743A7.DC5461EA@mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: question about _exit() function 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, 28 Nov 2003 14:51:45 -0000 Thanks a lot for the answer. I will change vfork() with fork(). An another question: in the man page of vfork() it is mentionned that the fork() function has to use _exit(0) too when something wrong with the execve() happens! but in a thread context of my program, the use of _exit() may not be best practice. Is the child a real process or because of the thread context a part of the parent process, so a new thread. In this case a pthread_exit() may be a better solution. Is that point a view complety wrong ? Currently, is some indeterminate case, a part of my program freeze just after the vfork(). So, I try to understand what may cause the calling thread of vfork() to freeze ... Thanks a lot! On Fri, 28 Nov 2003, Terry Lambert wrote: > Date: Fri, 28 Nov 2003 04:46:31 -0800 > From: Terry Lambert > To: rmkml > Cc: freebsd-hackers@freebsd.org > Subject: Re: question about _exit() function > > rmkml wrote: > > is the _exit() function safe for a thread ? > > my program use vfork() and then execve in a thread context. > > The documentation mentions that the process has to call _exit() in case > > of failure. > > But this _exit() is really safe for the parent thread ? > > The behaviour is undefined in the failure case, but only if you > have stablishd a pthread_atfork() handler that does anything in > the child. > > In general, the more correct approach is to use posix_spawn(), but > FreeBSD doesn't support posix_spawn() (funny; this has come up now > twice in within 60 messages of each other, while ther was a very > long time when it was not pertinent at all...). > > POSIX also sriously discourages the use of vfork(), and recommends > fork() instead, for threaded programs. > > Note that the fork() only *ever* creates a single thread, so it > will only replicate the currently running thread and its address > space, rather than all currently running threads in the parent. > > You said in another message that this is on 4.8. I think that the > behaviour will not be quite what you expect, in that case, and that > it'll be better in -current, but might still not be what you expect > there, either (depends on what you are expecting). See also: > > http://www.opengroup.org/onlinepubs/007904975/functions/fork.html > > -- Terry > From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 28 11:01:46 2003 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 BE50816A4CF for ; Fri, 28 Nov 2003 11:01:46 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4378343FAF for ; Fri, 28 Nov 2003 11:01:45 -0800 (PST) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtpzilla3.xs4all.nl (8.12.9/8.12.9) with ESMTP id hASJ1h87083661; Fri, 28 Nov 2003 20:01:43 +0100 (CET) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.9p2/8.12.9) with ESMTP id hASJ1hIY031718; Fri, 28 Nov 2003 20:01:43 +0100 (CET) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.9p2/8.12.9/Submit) id hASJ1hYY031717; Fri, 28 Nov 2003 20:01:43 +0100 (CET) (envelope-from wkb) Date: Fri, 28 Nov 2003 20:01:43 +0100 From: Wilko Bulte To: Poul-Henning Kamp Message-ID: <20031128190143.GA31702@freebie.xs4all.nl> References: <200311280014.49356.wes@softweyr.com> <7304.1070019810@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7304.1070019810@critter.freebsd.dk> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.9-STABLE X-PGP: finger wilko@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 28 Nov 2003 19:01:46 -0000 On Fri, Nov 28, 2003 at 12:43:30PM +0100, Poul-Henning Kamp wrote: > In message <200311280014.49356.wes@softweyr.com>, Wes Peters writes: > > >If you want an interesting problem to work on, come up with a solution to > >the keying problem for disk encryption. It somehow needs to allow > >automated, unattended reboots during "normal" operations but prevent > >attackers from compromising the system. Maybe you could have the system > >send an SMS message when it needs a key, you reply with a one-time key > >from your mobile phone? > > I have already described one solution to this in my GBDE paper at > BSDcon. ... > Now *that* is a DIY project for the dedicated hobbyist :-) > > The terminology and principle, is from atomic weapons which have a > similar security profile: > http://nuclearweaponarchive.org/Usa/Weapons/Pal.html Your interests sometimes worry me... ;-) -- | / o / /_ _ |/|/ / / /( (_) Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 28 12:16:47 2003 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 8120316A4CE for ; Fri, 28 Nov 2003 12:16:47 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F8DD43F85 for ; Fri, 28 Nov 2003 12:16:46 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id hASKGhgS010552; Fri, 28 Nov 2003 21:16:43 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Wilko Bulte From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 28 Nov 2003 20:01:43 +0100." <20031128190143.GA31702@freebie.xs4all.nl> Date: Fri, 28 Nov 2003 21:16:43 +0100 Message-ID: <10551.1070050603@critter.freebsd.dk> cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? 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, 28 Nov 2003 20:16:47 -0000 In message <20031128190143.GA31702@freebie.xs4all.nl>, Wilko Bulte writes: >On Fri, Nov 28, 2003 at 12:43:30PM +0100, Poul-Henning Kamp wrote: >> I have already described one solution to this in my GBDE paper at >> BSDcon. > >... > >> Now *that* is a DIY project for the dedicated hobbyist :-) >> >> The terminology and principle, is from atomic weapons which have a >> similar security profile: >> http://nuclearweaponarchive.org/Usa/Weapons/Pal.html > >Your interests sometimes worry me... My interest in the cold war comes from having grown up in a place that had one of the highest ratios of nuclear bulls-eyes to human beings in Europe. "The Great Belt" is a deep (75m) narrow strait (20km) which would have been the soviets only chance of getting their baltic fleet out, the other two straits are small enough that they could be efficiently mined/blocked. Already then, we knew that both sides would have the strait in their atomic target lists, only later did we find out how very very certain they wanted to be. The trick is to be able to apply what you learn from one interest to productive uses in other interests. Poul-Henning PS: Interesting historical tidbit: The observation that missiles were on their way to Cuba came from the island Langeland in The Great Belt. If they hadn't noticed, the US blocade would have been too late and the world probably quite different. (http://www.rudkom.dk/museum/lm/frames/uk/menu/udstilling/fort01.html) -- 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 Nov 28 12:57:33 2003 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 07BE316A4CE for ; Fri, 28 Nov 2003 12:57:33 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B5C643FA3 for ; Fri, 28 Nov 2003 12:57:32 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) hASKvViF002737; Fri, 28 Nov 2003 12:57:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id hASKvUOM002734; Fri, 28 Nov 2003 12:57:30 -0800 (PST) (envelope-from dillon) Date: Fri, 28 Nov 2003 12:57:30 -0800 (PST) From: Matthew Dillon Message-Id: <200311282057.hASKvUOM002734@apollo.backplane.com> To: Soren Schmidt References: <200311262104.hAQL4ICN024652@spider.deepcore.dk> cc: hackers@freebsd.org Subject: Problems with use of M_NOWWAIT in ATA 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, 28 Nov 2003 20:57:33 -0000 Soren, while fixing some issues in DFly related to the ATA driver I found a serious problem in your driver... actually, it appears to be in ata-ng -stable and -current as well. The problem is that you are using M_NOWAIT all over the place. M_NOWAIT allows malloc() to fail if/when resources are temporarily exhausted. In DFly this can occur more often because it causes malloc() to return NULL if cannot lock the kernel_map, but I believe malloc() can return NULL in -current and -stable as well (e.g. if the VM page free list is empty). Also, at least in the 4.8 ATA driver, the driver tries to revert to PIO mode if it cannot allocate a DMA buffer. This is bad because PIO might not necessarily work. It just isn't appropriate to revert to PIO mode under any circumstances other then a hardware DMA failure. In -current you are using bus dma tags and I don't know whether that solves the issue, but even in -CURRENT you are allocating request structures with M_NOWAIT (in ata_alloc_request()) and that is just plain not right. You are virtually guarenteed to corrupt any filesystem trying to issue a write for which ata_alloc_request() fails. It *CANNOT* fail. I know the problem is complicated somewhat by the fact that you cannot simply replace that code with a blocking wait without creating a deadlock situation. What you really need to do is create a request pipeline and block up-front to wait for an I/O operation to complete which frees up an existing request (e.g. before getting the tag). If you do not want to block in ad_start() you can place the original io buffer on a queue and reissue when requests/DMA memory are freed up by completing I/O's. I am going to be hacking this up in DFly and I'll email you a patch set when I'm done. This is just a head's up that there are some serious issues in the ATA driver code related to memory allocation. -Matt From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 28 15:25:30 2003 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 30F7416A4CE for ; Fri, 28 Nov 2003 15:25:30 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C9EE43FBF for ; Fri, 28 Nov 2003 15:25:27 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-38lc0ef.dialup.mindspring.com ([209.86.1.207] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1APryQ-00037Z-00; Fri, 28 Nov 2003 15:24:31 -0800 Message-ID: <3FC7D905.D244EF2C@mindspring.com> Date: Fri, 28 Nov 2003 15:23:49 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rmkml References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a401989662b1858b129202e10628c4cfe9548b785378294e88350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: question about _exit() function 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, 28 Nov 2003 23:25:30 -0000 rmkml wrote: > Thanks a lot for the answer. I will change vfork() with fork(). > > An another question: in the man page of vfork() it is mentionned that > the fork() function has to use _exit(0) too when something wrong with the > execve() happens! I can see how you might read it this way, but that's not really correct. The purpose of _exit() instead of exit() is to avoid calling the atexit() handler, the per thread data cleanup handlers, and the cancellation routines. In the case of a vfork(), it's undefined as to whether you will be operating against resources currently allocated and appropriately reference counted to the child, or whether you are operating against that of the parent. In the case of fork(), you are guaranteed to operate in the context of the child. Which you should use is dependent on your application. The normal operation of a fork() in a threaded program is to duplicate only the calling thread. If you have registered atexit(), per thread data cleanup handlers, or cancellation routines (or, in some cases, signal handlers), then when you call exit(), these things will be invoked. Consider that the thread forking has perhaps the responsibility of cleaning up a shared memory segment created by a task. You do *not* want to do this cleanup (which happens on an interface that you are manually resource tracking) in the child process in this case, since it could rip the shared memory segment out from under other processes which are using it. Rather than calling _exit() to avoid this, you probably want to call exit()... however, you must deal with detaching your registered handlers and avoiding your manual cleanup process. The correct way to do this is to disable them in the child by utilizing the function pthread_atfork() to disentangle them at fork time. See: http://www.opengroup.org/onlinepubs/007904975/functions/pthread_atfork.html > Is the child a real process or because of the thread context a part of > the parent process, so a new thread. It is a real process; the only thread running in this real process is a copy of the thread that was running at the time of the fork(). This is the primary reason that vfork() cautions against its use in POSIX documentation, and why it only permits either an _exit() or an execve(), and why you should avoid vfork(). > In this case a pthread_exit() may be a better solution. > Is that point a view complety wrong ? You likely do not want to use pthread_exit() in this case, since you are the only thread in a process. If you were to use this with vfork(), the combination would likely cause a program malfunction. If you were to use it with fork(), the combination may or may not be a problem. In the second case, the reason for this is that there exists the possibility that when you create the new process, it will link with object files with statically declared instances whose .init routines create worker threads. For example, the Netscape LDAP library is not threads-safe, so at one point I wrote a wrapper library that queued requests to a single worker thread that was created at the time the library reference was instanced via a .init section. Calls into the library queued requests, which were then serialized to the Netscape library, and responses were sent back out. The result looked like an LDAP client library that could be reentered, but which would serialize work to the non-thread-reentrant library under the covers. So the reason pthread_exit() should not be used is that you may not be the only thread running, and if so, there will be no pthread_join() called to reap your thread, and the other threads will continue indefinitely: you can't depend on not creating threads as a side effect of using various libraries or shared objects. > Currently, is some indeterminate case, a part of my program freeze just > after the vfork(). > So, I try to understand what may cause the calling thread of vfork() to > freeze ... Without more detail, this is hard to pinpoint, since I don't really know what you mean by "freeze", and there appears to be a language barrier to a precise explanation. Most likely, this is an interaction between the user space scheduler and the vfork(). Realize that in the 4.x series of FreeBSD, the pthreads are implemented with a user space scheduler. This means that following a vfork(), since there is only one schedulable entity, the process, all threads are suspended until your _exit(0 or execve() call (assuming that these do the right thing in the vfork() case interacting with threads, and POSIX says that it's undefined if this will happen). If you want other threads in your main applicaion to run concurrently with the child, you *must* use fork() instead of vfork(). -- Terry From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 28 16:03:38 2003 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 2E74416A4CE for ; Fri, 28 Nov 2003 16:03:38 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id A24E943FAF for ; Fri, 28 Nov 2003 16:03:36 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id D30C15309; Sat, 29 Nov 2003 01:03:34 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 317BA5308; Sat, 29 Nov 2003 01:03:23 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 13EC033C8C; Sat, 29 Nov 2003 01:03:23 +0100 (CET) To: Kris Kirby References: From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sat, 29 Nov 2003 01:03:22 +0100 In-Reply-To: (Kris Kirby's message of "Thu, 27 Nov 2003 06:13:17 +0000 (GMT)") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: ss X-Spam-Status: No, hits=2.6 required=5.0 tests=RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.60 cc: freebsd-hackers@freebsd.org Subject: Re: NFS Flags Oddity 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, 29 Nov 2003 00:03:38 -0000 Kris Kirby writes: > FreeBSD (4.9-RC) doesn't appear to "export" schg flags over NFS. File flags are BSD-specific and are not supported in the NFS protocol. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 28 19:31:42 2003 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 0E96516A4CE for ; Fri, 28 Nov 2003 19:31:42 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9399B43FAF for ; Fri, 28 Nov 2003 19:31:37 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) hAT3UciF004350; Fri, 28 Nov 2003 19:31:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id hAT3UbNL004349; Fri, 28 Nov 2003 19:30:37 -0800 (PST) (envelope-from dillon) Date: Fri, 28 Nov 2003 19:30:37 -0800 (PST) From: Matthew Dillon Message-Id: <200311290330.hAT3UbNL004349@apollo.backplane.com> To: Soren Schmidt cc: hackers@freebsd.org Subject: Re: Problems with use of M_NOWWAIT in ATA (w/ demonstration patch) 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, 29 Nov 2003 03:31:42 -0000 All right, here's an example patch. This patch is against the old ATA code in DragonFly but most of the issues are the same with the ATA code in -STABLE and -CURRENT. It does not fix all the problems (which would be a waste since we are about to import ATAng and do not want to apply the same changes twice). What this patch does is demonstrate a solution to some of the issues. Basically this patch introduces guarentees by pipelining requests via the MPIPE code (see patch sys/mpipe.h and kern_mpipe.c). Take for example the ad_start() code in both FreeBSD-STABLE and FreeBSD-CURRENT (that is, in ATAng). ad_start() calls ata_alloc_request(). ata_alloc_request() calls malloc(... M_NOWAIT), which can fail. In ATAng if this malloc fails the I/O request will fail with an error for absolutely no good reason. Remember, high level code *DEPENDS* on being able to issue I/Os, especially in heavily memory loaded situations when the system is undergoing paging. It is *NOT* acceptable for low level ATA code to fail due to not being able to allocate memory for a request structure. --------------------------------- example #1 ---------------------------- In ATAold if ad_start() fails to allocate memory it leaves the request queued, which is the correct operation but only avoids a deadlock if there is already at least one outstanding request (so ad_start() gets called again when that request completes). In ATAng if ad_start() fails to allocate memory it fails the I/O request, which is much worse then the deadlock that ATAold had because higher layers are not robust enough to retry the request in all situations or make sufficient guarentees that the failed request will not result in, for example, filesystem corruption. In the MPIPE patch below I use the ATAold ad_start() model in that I leave the request queued, but I use MPIPE to allocate the request which *GUARENTEES* that there will be at least 4 I/O's in progress on this particular channel, which means that ad_start() will be called again when one of those I/O's completes which guarentees that (A) no deadlock will occur and (B) that the request will be processed later on as the I/O queue clears. --------------------------------- example #2 ---------------------------- DMA code. There are two issues. The first issue is only in ATAold, the second issue is only in ATAng. In ATAold if a DMA buffer could not be allocated the ATA driver silently fell back into PIO mode, which is bad. This is removed in the patch... it is not necessary to fall back to PIO mode if a memory request fails. In ATAng the bus dma code is used and M_NOWAIT is not used. However, this means that M_WAITOK is used which can deadlock the system when severe memory shortages exist because, again, the VM paging code assumse that the I/O's it issues at the device level will complete at some point. In otherwords, you cannot safely hang waiting for a DMA allocation if there isn't already at least one I/O request in progress. --------------------------------- example #3 ---------------------------- Not addressed by this patch. While purusing the code I noticed a huge number of cases where malloc(... M_NOWAIT) is called and the result is either assumed to be non-NULL or the error, if any, is completely ignored. I checked the code in FREEBSD-CURRENT to make sure that these cases were still an issue. Just search all the instances of M_NOWAIT and check (A) whether the return value is checked for NULL and (B) whether the caller of the parent procedure checks the error code. For example, ata_set_name() fails silently if the allocation fails. Various initialization and ioctl code, while it may not crash, and even if it does return an error code, also does not perform its function if an allocation fails and there are instances where calls are made to these functions which assume success. For example, if ata_dmainit() fails ch->dma is silently left NULL. The RAID code seems especially vulnerable to allocation failures, there are instances where buffers are allocated (for example, line 714 of ata-raid.c in CURRENT) and the result is assumed assuming a non-NULL result. These malloc's are being called M_NOWAIT, which means that NULL can be returned. In anycase, David Rhodus has been testing the ATAng from -STABLE and we will be importing that into DragonFly in the next week or so, but we will have to make the same MPIPE changes to that code that I am making to the original code. In fact, the changes will wind up being quite a bit more extensive then the hack I put together in the patch set below in order to cover the ATAPI code as well as the unconditional struct buf allocation code. Once we get the new ATAng code into DragonFly and make the appropriate changes to deal with the malloc() issues, I will post the patch for FreeBSD to take or ignore as it sees fit. -Matt Index: conf/files =================================================================== RCS file: /cvs/src/sys/conf/files,v retrieving revision 1.30 diff -u -r1.30 files --- conf/files 21 Nov 2003 05:29:05 -0000 1.30 +++ conf/files 28 Nov 2003 22:49:30 -0000 @@ -627,6 +627,7 @@ kern/kern_random.c standard kern/kern_resource.c standard kern/kern_slaballoc.c standard +kern/kern_mpipe.c standard kern/kern_shutdown.c standard kern/kern_sig.c standard kern/kern_upcall.c standard Index: dev/disk/ata/ata-all.c =================================================================== RCS file: /cvs/src/sys/dev/disk/ata/ata-all.c,v retrieving revision 1.8 diff -u -r1.8 ata-all.c --- dev/disk/ata/ata-all.c 9 Nov 2003 02:22:34 -0000 1.8 +++ dev/disk/ata/ata-all.c 29 Nov 2003 00:19:46 -0000 @@ -61,6 +61,11 @@ #include "ata-raid.h" #include "atapi-all.h" +union ata_request { + struct ad_request ad; + struct atapi_request atapi; +}; + /* device structures */ static d_ioctl_t ataioctl; static struct cdevsw ata_cdevsw = { @@ -97,6 +102,12 @@ /* sysctl vars */ SYSCTL_NODE(_hw, OID_AUTO, ata, CTLFLAG_RD, 0, "ATA driver parameters"); +int ata_mpipe_size = 4; +TUNABLE_INT("hw.ata.mpipe_size", &ata_mpipe_size); +SYSCTL_INT(_hw_ata, OID_AUTO, mpipe_size, CTLFLAG_RW, &ata_mpipe_size, 0, + "ATA global I/O pipeline max size"); + + /* global vars */ devclass_t ata_devclass; @@ -155,6 +166,10 @@ ch->device[SLAVE].mode = ATA_PIO; TAILQ_INIT(&ch->ata_queue); TAILQ_INIT(&ch->atapi_queue); + + mpipe_init(&ch->req_mpipe, M_ATA, sizeof(union ata_request), 4, ata_mpipe_size); + mpipe_init(&ch->dma_mpipe, M_DEVBUF, PAGE_SIZE, 4, ata_mpipe_size); + return 0; failure: @@ -286,6 +301,9 @@ ch->r_altio = NULL; ch->r_bmio = NULL; ch->r_irq = NULL; + mpipe_done(&ch->req_mpipe); + mpipe_done(&ch->dma_mpipe); + ATA_UNLOCK_CH(ch); return 0; } @@ -435,7 +453,7 @@ ATA_ATAPI_MASTER : ATA_ATAPI_SLAVE))) return ENODEV; - if (!(buf = malloc(iocmd->u.atapi.count, M_ATA, M_NOWAIT))) + if (!(buf = malloc(iocmd->u.atapi.count, M_ATA, M_WAITOK))) return ENOMEM; if (iocmd->u.atapi.flags & ATAPI_CMD_WRITE) { @@ -473,7 +491,7 @@ struct ata_params *ata_parm; int retry = 0; - if (!(ata_parm = malloc(sizeof(struct ata_params), M_ATA, M_NOWAIT))) { + if (!(ata_parm = malloc(sizeof(struct ata_params), M_ATA, M_WAITOK))) { ata_prtdev(atadev, "malloc for identify data failed\n"); return -1; } @@ -1400,7 +1418,7 @@ void ata_set_name(struct ata_device *atadev, char *name, int lun) { - atadev->name = malloc(strlen(name) + 4, M_ATA, M_NOWAIT); + atadev->name = malloc(strlen(name) + 4, M_ATA, M_WAITOK); if (atadev->name) sprintf(atadev->name, "%s%d", name, lun); } @@ -1559,7 +1577,7 @@ /* register boot attach to be run when interrupts are enabled */ if (!(ata_delayed_attach = (struct intr_config_hook *) malloc(sizeof(struct intr_config_hook), - M_TEMP, M_NOWAIT | M_ZERO))) { + M_TEMP, M_WAITOK | M_ZERO))) { printf("ata: malloc of delayed attach hook failed\n"); return; } Index: dev/disk/ata/ata-all.h =================================================================== RCS file: /cvs/src/sys/dev/disk/ata/ata-all.h,v retrieving revision 1.3 diff -u -r1.3 ata-all.h --- dev/disk/ata/ata-all.h 19 Jul 2003 21:14:18 -0000 1.3 +++ dev/disk/ata/ata-all.h 29 Nov 2003 00:13:36 -0000 @@ -29,6 +29,10 @@ * $DragonFly: src/sys/dev/disk/ata/ata-all.h,v 1.3 2003/07/19 21:14:18 dillon Exp $ */ +#ifndef _SYS_MPIPE_H_ +#include +#endif + /* ATA register defines */ #define ATA_DATA 0x00 /* data register */ #define ATA_ERROR 0x01 /* (R) error register */ @@ -225,6 +229,8 @@ TAILQ_HEAD(, ad_request) ata_queue; /* head of ATA queue */ TAILQ_HEAD(, atapi_request) atapi_queue; /* head of ATAPI queue */ void *running; /* currently running request */ + struct malloc_pipe req_mpipe; /* request allocations */ + struct malloc_pipe dma_mpipe; /* dma allocations */ }; /* disk bay/enclosure related */ @@ -236,6 +242,7 @@ /* externs */ extern devclass_t ata_devclass; +extern int ata_mpipe_size; /* public prototypes */ int ata_probe(device_t); @@ -263,7 +270,8 @@ int ata_umode(struct ata_params *); int ata_find_dev(device_t, u_int32_t, u_int32_t); -void *ata_dmaalloc(struct ata_channel *, int); +void *ata_dmaalloc(struct ata_channel *, int, int); +void ata_dmafree(struct ata_channel *, void *buf); void ata_dmainit(struct ata_channel *, int, int, int, int); int ata_dmasetup(struct ata_channel *, int, struct ata_dmaentry *, caddr_t, int); void ata_dmastart(struct ata_channel *, int, struct ata_dmaentry *, int); Index: dev/disk/ata/ata-disk.c =================================================================== RCS file: /cvs/src/sys/dev/disk/ata/ata-disk.c,v retrieving revision 1.7 diff -u -r1.7 ata-disk.c --- dev/disk/ata/ata-disk.c 7 Aug 2003 21:16:51 -0000 1.7 +++ dev/disk/ata/ata-disk.c 29 Nov 2003 00:17:28 -0000 @@ -115,10 +115,13 @@ struct ad_softc *adp; dev_t dev; - if (!(adp = malloc(sizeof(struct ad_softc), M_AD, M_NOWAIT | M_ZERO))) { + if (!(adp = malloc(sizeof(struct ad_softc), M_AD, M_WAITOK | M_ZERO))) { ata_prtdev(atadev, "failed to allocate driver storage\n"); return; } + + KKASSERT(atadev->channel->req_mpipe.max_count != 0); + adp->device = atadev; #ifdef ATA_STATIC_ID adp->lun = (device_get_unit(atadev->channel->dev)<<1)+ATA_DEV(atadev->unit); @@ -397,8 +400,14 @@ return; } - if (!(request = malloc(sizeof(struct ad_request), M_AD, M_NOWAIT|M_ZERO))) { - ata_prtdev(atadev, "out of memory in start\n"); + /* + * Allocate a request. The allocation can only fail if the pipeline + * is full, in which case the request will be picked up later when + * ad_start() is called after another request completes. + */ + request = mpipe_alloc(&atadev->channel->req_mpipe, M_NOWAIT|M_ZERO); + if (request == NULL) { + ata_prtdev(atadev, "pipeline full allocating request in ad_start\n"); return; } @@ -412,8 +421,13 @@ if (bp->b_flags & B_READ) request->flags |= ADR_F_READ; if (adp->device->mode >= ATA_DMA) { - if (!(request->dmatab = ata_dmaalloc(atadev->channel, atadev->unit))) - adp->device->mode = ATA_PIO; + request->dmatab = ata_dmaalloc(atadev->channel, atadev->unit, M_NOWAIT); + if (request->dmatab == NULL) { + mpipe_free(&atadev->channel->req_mpipe, request); + ata_prtdev(atadev, "pipeline full allocated dmabuf in ad_start\n"); + /* do not revert to PIO, wait for ad_start after I/O completion */ + return; + } } /* insert in tag array */ @@ -804,9 +818,9 @@ int s = splbio(); if (request->dmatab) - free(request->dmatab, M_DEVBUF); + ata_dmafree(request->softc->device->channel, request->dmatab); request->softc->tags[request->tag] = NULL; - free(request, M_AD); + mpipe_free(&request->softc->device->channel->req_mpipe, request); splx(s); } Index: dev/disk/ata/ata-dma.c =================================================================== RCS file: /cvs/src/sys/dev/disk/ata/ata-dma.c,v retrieving revision 1.5 diff -u -r1.5 ata-dma.c --- dev/disk/ata/ata-dma.c 26 Nov 2003 14:24:46 -0000 1.5 +++ dev/disk/ata/ata-dma.c 29 Nov 2003 00:13:01 -0000 @@ -34,6 +34,7 @@ #include #include #include +#include #include #include #include @@ -60,19 +61,21 @@ (device == ATA_SLAVE && ch->devices & ATA_ATAPI_SLAVE)) void * -ata_dmaalloc(struct ata_channel *ch, int device) +ata_dmaalloc(struct ata_channel *ch, int device, int flags) { void *dmatab; - if ((dmatab = malloc(PAGE_SIZE, M_DEVBUF, M_NOWAIT))) { - if (((uintptr_t)dmatab >> PAGE_SHIFT) ^ - (((uintptr_t)dmatab + PAGE_SIZE - 1) >> PAGE_SHIFT)) { - ata_printf(ch, device, "dmatab crosses page boundary, no DMA\n"); - free(dmatab, M_DEVBUF); - dmatab = NULL; - } - } - return dmatab; + KKASSERT(ch->dma_mpipe.max_count != 0); + dmatab = mpipe_alloc(&ch->dma_mpipe, flags); + KKASSERT(((uintptr_t)dmatab & PAGE_MASK) == 0); + return (dmatab); +} + +void +ata_dmafree(struct ata_channel *ch, void *dmatab) +{ + if (dmatab) + mpipe_free(&ch->dma_mpipe, dmatab); } void Index: dev/disk/ata/ata-isa.c =================================================================== RCS file: /cvs/src/sys/dev/disk/ata/ata-isa.c,v retrieving revision 1.3 diff -u -r1.3 ata-isa.c --- dev/disk/ata/ata-isa.c 7 Aug 2003 21:16:51 -0000 1.3 +++ dev/disk/ata/ata-isa.c 29 Nov 2003 00:13:48 -0000 @@ -109,9 +109,14 @@ #include "use_pci.h" #if NPCI == 0 void * -ata_dmaalloc(struct ata_channel *ch, int device) +ata_dmaalloc(struct ata_channel *ch, int device, int flags) { return 0; +} + +void +ata_dmafree(struct ata_channel *ch, void *dmatab) +{ } void Index: dev/disk/ata/ata-raid.c =================================================================== RCS file: /cvs/src/sys/dev/disk/ata/ata-raid.c,v retrieving revision 1.8 diff -u -r1.8 ata-raid.c --- dev/disk/ata/ata-raid.c 7 Aug 2003 21:16:51 -0000 1.8 +++ dev/disk/ata/ata-raid.c 28 Nov 2003 23:36:19 -0000 @@ -116,7 +116,7 @@ if (!ar_table) ar_table = malloc(sizeof(struct ar_soft *) * MAX_ARRAYS, - M_AR, M_NOWAIT | M_ZERO); + M_AR, M_WAITOK | M_ZERO); if (!ar_table) { ata_prtdev(adp->device, "no memory for ATA raid array\n"); return 0; @@ -250,7 +250,7 @@ if (!ar_table) ar_table = malloc(sizeof(struct ar_soft *) * MAX_ARRAYS, - M_AR, M_NOWAIT | M_ZERO); + M_AR, M_WAITOK | M_ZERO); if (!ar_table) { printf("ar: no memory for ATA raid array\n"); return 0; @@ -263,7 +263,7 @@ return ENOSPC; if (!(rdp = (struct ar_softc*)malloc(sizeof(struct ar_softc), M_AR, - M_NOWAIT | M_ZERO))) { + M_WAITOK | M_ZERO))) { printf("ar%d: failed to allocate raid config storage\n", array); return ENOMEM; } @@ -550,7 +550,7 @@ return; } - buf1 = malloc(sizeof(struct ar_buf), M_AR, M_NOWAIT | M_ZERO); + buf1 = malloc(sizeof(struct ar_buf), M_AR, M_WAITOK | M_ZERO); BUF_LOCKINIT(&buf1->bp); BUF_LOCK(&buf1->bp, LK_EXCLUSIVE); buf1->bp.b_pblkno = lba; @@ -631,7 +631,7 @@ ((rdp->flags & AR_F_REBUILDING) && (rdp->disks[buf1->drive].flags & AR_DF_SPARE) && buf1->bp.b_pblkno < rdp->lock_start)) { - buf2 = malloc(sizeof(struct ar_buf), M_AR, M_NOWAIT); + buf2 = malloc(sizeof(struct ar_buf), M_AR, M_WAITOK); bcopy(buf1, buf2, sizeof(struct ar_buf)); BUF_LOCKINIT(&buf2->bp); BUF_LOCK(&buf2->bp, LK_EXCLUSIVE); @@ -827,7 +827,7 @@ rdp->lock_end = rdp->lock_start + 256; rdp->flags |= AR_F_REBUILDING; splx(s); - buffer = malloc(256 * DEV_BSIZE, M_AR, M_NOWAIT | M_ZERO); + buffer = malloc(256 * DEV_BSIZE, M_AR, M_WAITOK | M_ZERO); /* now go copy entire disk(s) */ while (rdp->lock_end < (rdp->total_sectors / rdp->width)) { @@ -896,7 +896,7 @@ int array, disk_number = 0, retval = 0; if (!(info = (struct highpoint_raid_conf *) - malloc(sizeof(struct highpoint_raid_conf), M_AR, M_NOWAIT | M_ZERO))) + malloc(sizeof(struct highpoint_raid_conf), M_AR, M_WAITOK | M_ZERO))) return retval; if (ar_rw(adp, HPT_LBA, sizeof(struct highpoint_raid_conf), @@ -925,7 +925,7 @@ if (!raidp[array]) { raidp[array] = (struct ar_softc*)malloc(sizeof(struct ar_softc), M_AR, - M_NOWAIT | M_ZERO); + M_WAITOK | M_ZERO); if (!raidp[array]) { printf("ar%d: failed to allocate raid config storage\n", array); goto highpoint_out; @@ -1045,7 +1045,7 @@ for (disk = 0; disk < rdp->total_disks; disk++) { if (!(config = (struct highpoint_raid_conf *) malloc(sizeof(struct highpoint_raid_conf), - M_AR, M_NOWAIT | M_ZERO))) { + M_AR, M_WAITOK | M_ZERO))) { printf("ar%d: Highpoint write conf failed\n", rdp->lun); return -1; } @@ -1125,7 +1125,7 @@ int array, count, disk, disksum = 0, retval = 0; if (!(info = (struct promise_raid_conf *) - malloc(sizeof(struct promise_raid_conf), M_AR, M_NOWAIT | M_ZERO))) + malloc(sizeof(struct promise_raid_conf), M_AR, M_WAITOK | M_ZERO))) return retval; if (ar_rw(adp, PR_LBA(adp), sizeof(struct promise_raid_conf), @@ -1171,7 +1171,7 @@ if (!raidp[array]) { raidp[array] = (struct ar_softc*)malloc(sizeof(struct ar_softc), M_AR, - M_NOWAIT | M_ZERO); + M_WAITOK | M_ZERO); if (!raidp[array]) { printf("ar%d: failed to allocate raid config storage\n", array); goto promise_out; @@ -1286,7 +1286,7 @@ for (disk = 0; disk < rdp->total_disks; disk++) { if (!(config = (struct promise_raid_conf *) - malloc(sizeof(struct promise_raid_conf), M_AR, M_NOWAIT))) { + malloc(sizeof(struct promise_raid_conf), M_AR, M_WAITOK))) { printf("ar%d: %s write conf failed\n", rdp->lun, local ? "FreeBSD" : "Promise"); return -1; @@ -1411,7 +1411,7 @@ struct buf *bp; int retry = 0, error = 0; - if (!(bp = (struct buf *)malloc(sizeof(struct buf), M_AR, M_NOWAIT|M_ZERO))) + if (!(bp = (struct buf *)malloc(sizeof(struct buf), M_AR, M_WAITOK|M_ZERO))) return ENOMEM; BUF_LOCKINIT(bp); BUF_LOCK(bp, LK_EXCLUSIVE); Index: dev/disk/ata/atapi-all.c =================================================================== RCS file: /cvs/src/sys/dev/disk/ata/atapi-all.c,v retrieving revision 1.4 diff -u -r1.4 atapi-all.c --- dev/disk/ata/atapi-all.c 7 Aug 2003 21:16:51 -0000 1.4 +++ dev/disk/ata/atapi-all.c 29 Nov 2003 00:15:17 -0000 @@ -94,7 +94,7 @@ ATA_UNLOCK_CH(atadev->channel); if (!(atadev->result = malloc(sizeof(struct atapi_reqsense), M_ATAPI, - M_NOWAIT | M_ZERO))) + M_WAITOK | M_ZERO))) ata_prtdev(atadev, "no memory for sense data\n"); switch (atadev->param->type) { @@ -162,7 +162,7 @@ biodone(bp); } if (request->dmatab) - free(request->dmatab, M_DEVBUF); + ata_dmafree(atadev->channel, request->dmatab); free(request, M_ATAPI); } free(atadev->result, M_ATAPI); @@ -178,10 +178,12 @@ { struct atapi_request *request; int error, s; - - if (!(request = malloc(sizeof(struct atapi_request), M_ATAPI, - M_NOWAIT | M_ZERO))) - return ENOMEM; + + request = malloc(sizeof(struct atapi_request), M_ATAPI, M_NOWAIT|M_ZERO); + if (request == NULL) { + printf("WARNNIG: atapi_queue_cmd: malloc() would block\n"); + request = malloc(sizeof(struct atapi_request), M_ATAPI, M_WAITOK|M_ZERO); + } request->device = atadev; request->data = data; @@ -196,8 +198,12 @@ request->driver = driver; } if (atadev->mode >= ATA_DMA) { - if (!(request->dmatab = ata_dmaalloc(atadev->channel, atadev->unit))) - atadev->mode = ATA_PIO; + request->dmatab = ata_dmaalloc(atadev->channel, atadev->unit, M_NOWAIT); + if (request->dmatab == NULL) { + printf("WARNING: atapi_queue_cmd: ata_dmaalloc() would block\n"); + request->dmatab = ata_dmaalloc(atadev->channel, + atadev->unit, M_WAITOK); + } } #ifdef ATAPI_DEBUG @@ -226,7 +232,7 @@ if (error) bcopy(&request->sense, atadev->result, sizeof(struct atapi_reqsense)); if (request->dmatab) - free(request->dmatab, M_DEVBUF); + ata_dmafree(atadev->channel, request->dmatab); free(request, M_ATAPI); return error; } @@ -606,7 +612,7 @@ if (request->callback) { if (!((request->callback)(request))) { if (request->dmatab) - free(request->dmatab, M_DEVBUF); + ata_dmafree(request->device->channel, request->dmatab); free(request, M_ATAPI); } } Index: dev/disk/ata/atapi-cam.c =================================================================== RCS file: /cvs/src/sys/dev/disk/ata/atapi-cam.c,v retrieving revision 1.3 diff -u -r1.3 atapi-cam.c --- dev/disk/ata/atapi-cam.c 7 Aug 2003 21:16:51 -0000 1.3 +++ dev/disk/ata/atapi-cam.c 28 Nov 2003 23:37:24 -0000 @@ -119,7 +119,7 @@ } if ((scp = malloc(sizeof(struct atapi_xpt_softc), - M_ATACAM, M_NOWAIT | M_ZERO)) == NULL) + M_ATACAM, M_WAITOK | M_ZERO)) == NULL) goto error; scp->ata_ch = ata_ch; @@ -481,7 +481,7 @@ if ((ccb_h->flags & CAM_DIR_MASK) == CAM_DIR_IN && (len & 1)) { /* ATA always transfers an even number of bytes */ if (!(buf = hcb->dxfer_alloc = malloc(++len, M_ATACAM, - M_NOWAIT | M_ZERO))) + M_WAITOK | M_ZERO))) goto action_oom; } s = splbio(); @@ -652,7 +652,7 @@ allocate_hcb(struct atapi_xpt_softc *softc, int unit, int bus, union ccb *ccb) { struct atapi_hcb *hcb = (struct atapi_hcb *) - malloc(sizeof(struct atapi_hcb), M_ATACAM, M_NOWAIT | M_ZERO); + malloc(sizeof(struct atapi_hcb), M_ATACAM, M_WAITOK | M_ZERO); if (hcb != NULL) { hcb->softc = softc; Index: dev/disk/ata/atapi-cd.c =================================================================== RCS file: /cvs/src/sys/dev/disk/ata/atapi-cd.c,v retrieving revision 1.8 diff -u -r1.8 atapi-cd.c --- dev/disk/ata/atapi-cd.c 7 Aug 2003 21:16:51 -0000 1.8 +++ dev/disk/ata/atapi-cd.c 28 Nov 2003 23:38:17 -0000 @@ -132,7 +132,7 @@ sizeof(struct changer)>>8, sizeof(struct changer), 0, 0, 0, 0, 0, 0 }; - chp = malloc(sizeof(struct changer), M_ACD, M_NOWAIT | M_ZERO); + chp = malloc(sizeof(struct changer), M_ACD, M_WAITOK | M_ZERO); if (chp == NULL) { ata_prtdev(atadev, "out of memory\n"); free(cdp, M_ACD); @@ -148,7 +148,7 @@ chp->table_length = htons(chp->table_length); if (!(cdparr = malloc(sizeof(struct acd_softc) * chp->slots, - M_ACD, M_NOWAIT))) { + M_ACD, M_WAITOK))) { ata_prtdev(atadev, "out of memory\n"); free(chp, M_ACD); free(cdp, M_ACD); @@ -172,7 +172,7 @@ DEVSTAT_TYPE_CDROM | DEVSTAT_TYPE_IF_IDE, DEVSTAT_PRIORITY_CD); } - name = malloc(strlen(atadev->name) + 2, M_ACD, M_NOWAIT); + name = malloc(strlen(atadev->name) + 2, M_ACD, M_WAITOK); strcpy(name, atadev->name); strcat(name, "-"); ata_free_name(atadev); @@ -248,7 +248,7 @@ { struct acd_softc *cdp; - if (!(cdp = malloc(sizeof(struct acd_softc), M_ACD, M_NOWAIT | M_ZERO))) + if (!(cdp = malloc(sizeof(struct acd_softc), M_ACD, M_WAITOK | M_ZERO))) return NULL; TAILQ_INIT(&cdp->dev_list); bufq_init(&cdp->queue); @@ -258,7 +258,7 @@ cdp->slot = -1; cdp->changer_info = NULL; if (!(cdp->stats = malloc(sizeof(struct devstat), M_ACD, - M_NOWAIT | M_ZERO))) { + M_WAITOK | M_ZERO))) { free(cdp, M_ACD); return NULL; } @@ -673,7 +673,7 @@ if (te->address_format == CD_MSF_FORMAT) { struct cd_toc_entry *entry; - toc = malloc(sizeof(struct toc), M_ACD, M_NOWAIT | M_ZERO); + toc = malloc(sizeof(struct toc), M_ACD, M_WAITOK | M_ZERO); bcopy(&cdp->toc, toc, sizeof(struct toc)); entry = toc->tab + (toc->hdr.ending_track + 1 - toc->hdr.starting_track) + 1; @@ -718,7 +718,7 @@ if (te->address_format == CD_MSF_FORMAT) { struct cd_toc_entry *entry; - toc = malloc(sizeof(struct toc), M_ACD, M_NOWAIT | M_ZERO); + toc = malloc(sizeof(struct toc), M_ACD, M_WAITOK | M_ZERO); bcopy(&cdp->toc, toc, sizeof(struct toc)); entry = toc->tab + (track - toc->hdr.starting_track); @@ -858,7 +858,7 @@ #ifndef CD_BUFFER_BLOCKS #define CD_BUFFER_BLOCKS 13 #endif - if (!(buffer = malloc(CD_BUFFER_BLOCKS * 2352, M_ACD, M_NOWAIT))){ + if (!(buffer = malloc(CD_BUFFER_BLOCKS * 2352, M_ACD, M_WAITOK))){ error = ENOMEM; break; } @@ -1340,7 +1340,7 @@ char name[16]; sprintf(name, "acd%dt%d", cdp->lun, track); - entry = malloc(sizeof(struct acd_devlist), M_ACD, M_NOWAIT | M_ZERO); + entry = malloc(sizeof(struct acd_devlist), M_ACD, M_WAITOK | M_ZERO); entry->dev = make_dev(&acd_cdevsw, (cdp->lun << 3) | (track << 16), 0, 0, 0644, name, NULL); entry->dev->si_drv1 = cdp->dev->si_drv1; @@ -1649,7 +1649,7 @@ if ((error = acd_mode_select(cdp, (caddr_t)¶m, param.page_length + 10))) return error; - buffer = malloc(cuesheet->len, M_ACD, M_NOWAIT); + buffer = malloc(cuesheet->len, M_ACD, M_WAITOK); if (!buffer) return ENOMEM; if ((error = copyin(cuesheet->entries, buffer, cuesheet->len))) @@ -1711,7 +1711,7 @@ ccb[9] = length & 0xff; ccb[10] = (ai->agid << 6) | ai->format; - d = malloc(length, M_ACD, M_NOWAIT | M_ZERO); + d = malloc(length, M_ACD, M_WAITOK | M_ZERO); d->length = htons(length - 2); error = atapi_queue_cmd(cdp->device, ccb, (caddr_t)d, length, @@ -1775,19 +1775,19 @@ switch (ai->format) { case DVD_SEND_CHALLENGE: length = 16; - d = malloc(length, M_ACD, M_NOWAIT | M_ZERO); + d = malloc(length, M_ACD, M_WAITOK | M_ZERO); bcopy(ai->keychal, &d->data[0], 10); break; case DVD_SEND_KEY2: length = 12; - d = malloc(length, M_ACD, M_NOWAIT | M_ZERO); + d = malloc(length, M_ACD, M_WAITOK | M_ZERO); bcopy(&ai->keychal[0], &d->data[0], 5); break; case DVD_SEND_RPC: length = 8; - d = malloc(length, M_ACD, M_NOWAIT | M_ZERO); + d = malloc(length, M_ACD, M_WAITOK | M_ZERO); d->data[0] = ai->region; break; @@ -1850,7 +1850,7 @@ return EINVAL; } - d = malloc(length, M_ACD, M_NOWAIT | M_ZERO); + d = malloc(length, M_ACD, M_WAITOK | M_ZERO); d->length = htons(length - 2); bzero(ccb, sizeof(ccb)); Index: dev/disk/ata/atapi-fd.c =================================================================== RCS file: /cvs/src/sys/dev/disk/ata/atapi-fd.c,v retrieving revision 1.8 diff -u -r1.8 atapi-fd.c --- dev/disk/ata/atapi-fd.c 15 Nov 2003 21:05:41 -0000 1.8 +++ dev/disk/ata/atapi-fd.c 28 Nov 2003 23:38:22 -0000 @@ -89,7 +89,7 @@ struct afd_softc *fdp; dev_t dev; - fdp = malloc(sizeof(struct afd_softc), M_AFD, M_NOWAIT | M_ZERO); + fdp = malloc(sizeof(struct afd_softc), M_AFD, M_WAITOK | M_ZERO); if (!fdp) { ata_prtdev(atadev, "out of memory\n"); return 0; Index: dev/disk/ata/atapi-tape.c =================================================================== RCS file: /cvs/src/sys/dev/disk/ata/atapi-tape.c,v retrieving revision 1.7 diff -u -r1.7 atapi-tape.c --- dev/disk/ata/atapi-tape.c 7 Aug 2003 21:16:51 -0000 1.7 +++ dev/disk/ata/atapi-tape.c 28 Nov 2003 23:38:25 -0000 @@ -99,7 +99,7 @@ struct ast_readposition position; dev_t dev; - stp = malloc(sizeof(struct ast_softc), M_AST, M_NOWAIT | M_ZERO); + stp = malloc(sizeof(struct ast_softc), M_AST, M_WAITOK | M_ZERO); if (!stp) { ata_prtdev(atadev, "out of memory\n"); return 0; Index: kern/kern_mpipe.c =================================================================== RCS file: kern/kern_mpipe.c diff -N kern/kern_mpipe.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ kern/kern_mpipe.c 29 Nov 2003 00:11:31 -0000 @@ -0,0 +1,167 @@ +/* + * Copyright (c) 2003 Matthew Dillon + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $DragonFly$ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define arysize(ary) (sizeof(ary)/sizeof((ary)[0])) + +typedef struct mpipe_buf { + TAILQ_ENTRY(mpipe_buf) entry; +} *mpipe_buf_t; + +/* + * Initialize a malloc pipeline for the specified malloc type and allocation + * size, and immediately allocate nnow buffers and set the nominal maximum + * to nmax. + */ +void +mpipe_init(malloc_pipe_t mpipe, malloc_type_t type, int bytes, + int nnow, int nmax) +{ + if (bytes < sizeof(struct mpipe_buf)) + bytes = sizeof(struct mpipe_buf); + bzero(mpipe, sizeof(struct malloc_pipe)); + TAILQ_INIT(&mpipe->queue); + mpipe->type = type; + mpipe->bytes = bytes; + mpipe->max_count = nmax; + if (nnow > 0) { + void *buf; + + buf = malloc(bytes, mpipe->type, M_WAITOK); + KKASSERT(buf != NULL); + ++mpipe->total_count; + mpipe_free(mpipe, buf); + while (--nnow > 0) { + buf = malloc(bytes, mpipe->type, M_NOWAIT); + if (buf == NULL) + break; + ++mpipe->total_count; + mpipe_free(mpipe, buf); + } + } + if (mpipe->max_count < mpipe->total_count) + mpipe->max_count = mpipe->total_count; +} + +void +mpipe_done(malloc_pipe_t mpipe) +{ + struct mpipe_buf *buf; + + KKASSERT(mpipe->free_count == mpipe->total_count); + while (mpipe->free_count) { + buf = TAILQ_FIRST(&mpipe->queue); + KKASSERT(buf != NULL); + TAILQ_REMOVE(&mpipe->queue, buf, entry); + --mpipe->free_count; + --mpipe->total_count; + free(buf, mpipe->type); + } + KKASSERT(TAILQ_EMPTY(&mpipe->queue)); +} + +/* + * Allocate an entry. flags can be M_NOWAIT which tells us not to block. + * Unlike a normal malloc, if we block in mpipe_alloc() no deadlock will occur + * because it will unblock the moment an existing in-use buffer is freed. + */ +void * +mpipe_alloc(malloc_pipe_t mpipe, int flags) +{ + mpipe_buf_t buf; + + crit_enter(); + while (mpipe->free_count == 0) { + if (mpipe->total_count < mpipe->max_count) { + ++mpipe->total_count; + if ((buf = malloc(mpipe->bytes, mpipe->type, flags)) != NULL) { + crit_exit(); + return(buf); + } + --mpipe->total_count; + } else if (flags & M_NOWAIT) { + crit_exit(); + return(NULL); + } else { + mpipe->pending = 1; + tsleep(mpipe, 0, "mpipe", 0); + } + } + buf = TAILQ_FIRST(&mpipe->queue); + KKASSERT(buf != NULL); + TAILQ_REMOVE(&mpipe->queue, buf, entry); + --mpipe->free_count; + crit_exit(); + if (flags & M_ZERO) + bzero(buf, mpipe->bytes); + return(buf); +} + +/* + * Free an entry, unblock any waiters. + */ +void +mpipe_free(malloc_pipe_t mpipe, void *vbuf) +{ + struct mpipe_buf *buf; + + if ((buf = vbuf) != NULL) { + crit_enter(); + if (mpipe->total_count > mpipe->max_count) { + --mpipe->total_count; + crit_exit(); + free(buf, mpipe->type); + } else { + TAILQ_INSERT_TAIL(&mpipe->queue, buf, entry); + ++mpipe->free_count; + crit_exit(); + if (mpipe->free_count >= (mpipe->total_count >> 2) + 1) { + if (mpipe->trigger) { + mpipe->trigger(mpipe->trigger_data); + } + if (mpipe->pending) { + mpipe->pending = 0; + wakeup(mpipe); + } + } + } + } +} + Index: sys/malloc.h =================================================================== RCS file: /cvs/src/sys/sys/malloc.h,v retrieving revision 1.15 diff -u -r1.15 malloc.h --- sys/malloc.h 21 Nov 2003 22:46:13 -0000 1.15 +++ sys/malloc.h 28 Nov 2003 22:07:05 -0000 @@ -93,6 +93,8 @@ long ks_reserved[4]; /* future use (module compatibility) */ }; +typedef struct malloc_type *malloc_type_t; + #if defined(_KERNEL) || defined(_KERNEL_STRUCTURES) #define MALLOC_DEFINE(type, shortdesc, longdesc) \ Index: sys/mpipe.h =================================================================== RCS file: sys/mpipe.h diff -N sys/mpipe.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sys/mpipe.h 28 Nov 2003 22:52:18 -0000 @@ -0,0 +1,68 @@ +/* + * Copyright (c) 2003 Matthew Dillon + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $DragonFly$ + */ + +#ifndef _SYS_MPIPE_H_ +#define _SYS_MPIPE_H_ + +#ifndef _SYS_MALLOC_H_ +#include +#endif + +/* + * Pipeline memory allocations. This implements a pipeline for allocations + * of a particular size. It is used in order to allow memory allocations + * to block while at the same time guarenteeing that no deadlocks will occur. + */ +struct mpipe_buf; + +struct malloc_pipe { + TAILQ_HEAD(, mpipe_buf) queue; + malloc_type_t type; /* malloc bucket */ + int bytes; /* allocation size */ + int pending; /* there is a request pending */ + int free_count; /* entries in free list */ + int total_count; /* total free + outstanding */ + int max_count; /* maximum cache size */ + void (*trigger)(void *data); /* trigger function on free */ + void *trigger_data; +}; + +typedef struct malloc_pipe *malloc_pipe_t; + +#ifdef _KERNEL + +void mpipe_init(malloc_pipe_t mpipe, malloc_type_t type, + int bytes, int nnow, int nmax); +void mpipe_done(malloc_pipe_t mpipe); +void *mpipe_alloc(malloc_pipe_t mpipe, int flags); +void mpipe_free(malloc_pipe_t mpipe, void *vbuf); + +#endif + +#endif + From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 28 22:02:42 2003 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 3DA2D16A4CE for ; Fri, 28 Nov 2003 22:02:42 -0800 (PST) Received: from cydem.org (h24-66-230-151.ed.shawcable.net [24.66.230.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DF7943FBF for ; Fri, 28 Nov 2003 22:02:41 -0800 (PST) (envelope-from soralx@cydem.org) Received: by cydem.org (Postfix, from userid 426) id 21F99391DF; Fri, 28 Nov 2003 23:02:39 -0700 (MST) Received: from h24-66-229-2.ed.shawcable.net (h24-66-229-2.ed.shawcable.net [24.66.229.2]) by cydem.org (Postfix) with ESMTP id 8ED48385D5; Fri, 28 Nov 2003 23:02:38 -0700 (MST) From: To: anthony@x-anthony.com Date: Fri, 28 Nov 2003 23:02:38 -0700 User-Agent: KMail/1.5 References: <20031125153901.GA78725@x-anthony.com> <20031126171142.GA99641@x-anthony.com> In-Reply-To: <20031126171142.GA99641@x-anthony.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200311282302.38003.soralx@cydem.org> cc: hackers@freebsd.org Subject: Re: freebsd smp -> linux up 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, 29 Nov 2003 06:02:42 -0000 > sadly, all ktrace shows is ktrace launching vmware (from 'ktrace vmware', > shows sh reading and executing, and then ends with the vmware fork). why not to `ktrace` vmware binary '/usr/local/lib/vmware/bin/vmware' instead of the shell-script 'vmware'? 28.11.2003; 23:00:47 [SorAlx] http://cydem.org.ua/ From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 29 11:32:37 2003 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 D920716A4CE for ; Sat, 29 Nov 2003 11:32:37 -0800 (PST) Received: from fep03-mail.bloor.is.net.cable.rogers.com (fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id A08A043FDF for ; Sat, 29 Nov 2003 11:32:36 -0800 (PST) (envelope-from genew@rogers.com) Received: from GUEST ([24.43.163.180]) by fep03-mail.bloor.is.net.cable.rogers.comESMTP <20031129193158.ONBD389421.fep03-mail.bloor.is.net.cable.rogers.com@GUEST> for ; Sat, 29 Nov 2003 14:31:58 -0500 From: genew@rogers.com To: freebsd-hackers@freebsd.org Date: Sat, 29 Nov 2003 14:32:37 -0500 MIME-Version: 1.0 Message-ID: <3FC8AE05.6532.51765AD@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.11) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.43.163.180] using ID at Sat, 29 Nov 2003 14:31:58 -0500 Subject: HPT302 UDMA/ATA133 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, 29 Nov 2003 19:32:38 -0000 Is there or will there be support for HighPoint chipset hpt302? HighPoints precompiled drivers for this chipset stop at FBSD 4.4 I am currently running FBSD 4.9 I have seen a few posts in freebsd-hardware but not many replies. pciconf -v -l is: none1@pci0:17:0; class=0x010400 card=0x00011103 chip=0x00061103 rev=0x01 hdr=0x00 vendor = 'HighPoint Technologies Inc.' device = 'HPT302N UDMA/ATA133 RAID Controller' class = mass storage subclass = raid Please respond directly as well since I am not on the mailing list but merely browsing the archives. Gene From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 29 21:22:39 2003 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 BA7B016A4CE; Sat, 29 Nov 2003 21:22:39 -0800 (PST) Received: from monster.schulte.org (monster.schulte.org [209.134.156.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4374443FE0; Sat, 29 Nov 2003 21:22:36 -0800 (PST) (envelope-from jay.liew@ml.freebsd.jaysern.org) Received: from localhost (localhost [127.0.0.1]) by monster.schulte.org (Postfix) with ESMTP id A10661FB2F; Sat, 29 Nov 2003 23:22:32 -0600 (CST) Received: from pinnacle.schulte.org (pinnacle.schulte.org [209.134.156.220]) by monster.schulte.org (Postfix) with ESMTP id C04101FB2B; Sat, 29 Nov 2003 23:22:31 -0600 (CST) Received: from localhost (dude@localhost)hAU5MVGM091728; Sat, 29 Nov 2003 23:22:31 -0600 (CST) (envelope-from jay.liew@ml.freebsd.jaysern.org) X-Authentication-Warning: pinnacle.schulte.org: dude owned process doing -bs Date: Sat, 29 Nov 2003 23:22:31 -0600 (CST) From: Jay Sern Liew X-X-Sender: dude@pinnacle.schulte.org To: freebsd-arch@freebsd.org, freebsd-threads@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20031129183810.M90959@pinnacle.schulte.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12pre8 on monster.schulte.org Subject: thread/process & memory management source code 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, 30 Nov 2003 05:22:40 -0000 Can someone point to me the specific location in the FreeBSD kernel source where the code for FreeBSD's thread/process & memory management are? Specifically, where the dispatcher and scheduler is implemented, what kind of scheduling algorithms(short term, long term) are used, where the dynamic storage allocation algorithm is implemented(I'll try to figure the algorithm used from the code), etc. Any help'd be appreciated! ________________________________________________________________________ Jay Sern Liew jaysern@{acm,ieee}.org gpg --keyserver pgp.mit.edu --recv-keys 0xA115A33F From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 29 22:53:14 2003 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 5CAB716A4CE for ; Sat, 29 Nov 2003 22:53:14 -0800 (PST) Received: from alo.louko.com (x1.louko.com [195.218.71.106]) by mx1.FreeBSD.org (Postfix) with SMTP id 66C3943F85 for ; Sat, 29 Nov 2003 22:53:12 -0800 (PST) (envelope-from alo@x1.louko.com) Received: (qmail 29352 invoked by uid 406); 30 Nov 2003 06:53:10 -0000 Date: 30 Nov 2003 06:53:10 -0000 Message-ID: <20031130065310.29349.qmail@alo.louko.com> To: freebsd-hackers@freebsd.org From: alo@iki.fi.invalid (Antti Louko) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?UTF-8?B?VW5lYmlnb3J58m1h?= =?UTF-8?B?ZQ==?=) APEL/10.3 Emacs/21.2 (i386--freebsd) (with unibyte mode) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Subject: ipfw/ipf IP filtering thoughts 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, 30 Nov 2003 06:53:14 -0000 Generally, I like the (Free)BSD way of doing things. But the IP filtering modules available for FreeBSD lack one feature when compared to Linux way (ipchains and iptables). In ipchains and iptables you have a sequential list of rules, very much like in ipfw and ipf, but you can have several different lists which have symbolic names and you can make calls from lists to other lists based on normal packet criteria. If the list is exchausted, the scan returns to the previous list. This makes it possible to make filtering decisions much more efficient in complex situation. You can for example scan a certain list only for eg. packets going to for example port 25 and so on. In FreeBSD, you don't have this "subroutine call" feature at all and you are limited to only one sequential list with a "goto". Any ideas how to proceed. I think this would be really needed and widely used if available.