From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 12 16:59:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83D1616A4CE for ; Sun, 12 Sep 2004 16:59:09 +0000 (GMT) Received: from f29.mail.ru (f29.mail.ru [194.67.57.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D72343D2F for ; Sun, 12 Sep 2004 16:59:09 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f29.mail.ru with local id 1C6Xgx-0004ZH-00; Sun, 12 Sep 2004 20:59:07 +0400 Received: from [24.184.136.70] by msg.mail.ru with HTTP; Sun, 12 Sep 2004 20:59:07 +0400 From: Igor Shmukler To: David Leimbach Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.184.136.70] Date: Sun, 12 Sep 2004 20:59:07 +0400 In-Reply-To: <2B4221DF-04CD-11D9-8975-000A95AFBEB4@mac.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: freebsd-hackers@freebsd.org Subject: Re[2]: FreeBSD on Xserve? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Shmukler List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 16:59:09 -0000 Why do you think that 970 does not have BAT registers? There are 16 special purpose registers specifically to implement Block Address Translation. I don't know what's a story with fan-drivers. Personally, I was under impression that G5 has liquid cooling system. Not that should be a major show stopper for FreeBSD support of G5 boxes. AFAIK, PPC port of FreeBSD is incomplete, but moving ahead quite fast. If original author wants to mature OS with MAC and SMP support SELinux might be a good candidate. However, Linux does not have jails. Only other OS that has them is Solaris 10 which does not run on PPC. I am not sure what kind of stack protection was referred in the original email. OpenBSD has propolis, but I was under impression there is no such option in FreeBSD. I recall that it was decided that security by obscurity will not make it into the kernel. > I don't think we have G5 support yet. G5's are significantly different > from G4s in a few ways that really matter to operating systems. > Missing BAT registers and other "fun stuff" like fan-drivers have meant > that even platforms that support 64bit PPC don't necessarily support G5 > [like the L4 microkernels I've been playing with] > > Dave > On Sep 12, 2004, at 2:30 AM, jade@oxymail.org wrote: > > > Hello, > > > > I'm planning on buying an Apple Xserve G5 bi-processor. I know mac os > > X (server) > > is running on it and that's a modified version of freebsd. > > So here are my questions : > > > > - I've been using freebsd for a while now and if I buy the Xserve I'd > > very much > > like to replace mac os X by a freebsd 5.2 / 5.3 if this is possible. My > > motivations are that I want to make intensive use of Jails and > > Mandatory Access > > Control (MAC). I'd also like to recompile the whole thing with stack > > protection > > (if possible). > > > > Yet I have no idea if Mac os X can run jails, and MAC (anyone an idea > > here ?), > > but if not, I'd switch to Freebie. > > > > So in general : > > - has anyone experienced the change > > - would it be difficult to replace OS X by FreeBSD ? > > - would it be possible to run these options (Jails,MAC,stack > > protection) on this > > hardware ? > > > > Thanks for the hints, because I'm a little lost. > > > > By, > > Jade. From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 12 18:34:42 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FE5916A4CE for ; Sun, 12 Sep 2004 18:34:42 +0000 (GMT) Received: from mongers.org (miracle.mongers.org [193.162.142.71]) by mx1.FreeBSD.org (Postfix) with SMTP id 1C6F943D4C for ; Sun, 12 Sep 2004 18:34:41 +0000 (GMT) (envelope-from m@mongers.org) Received: (qmail 15042 invoked by uid 1021); 12 Sep 2004 18:34:38 -0000 Date: Sun, 12 Sep 2004 20:34:15 +0200 From: Morten Liebach To: freebsd-hackers@freebsd.org Message-ID: <20040912183437.GF20097@mongers.org> References: <2B4221DF-04CD-11D9-8975-000A95AFBEB4@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Accept-Language: dansk, english X-Organisation: Hollow Chocolate Bunnies of Death, Inc. X-PGP-Key-ID: F1360CA9 X-PGP-Key-URL: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF1360CA9 X-PGP-Key-Fingerprint: 8CF5 32EE A5EC 36B2 4E3F ACDF 6D86 BEB3 F136 0CA9 Subject: Re: FreeBSD on Xserve? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Sep 2004 18:34:42 -0000 On 2004-09-12 20:59:07 +0400, Igor Shmukler wrote: > If original author wants to mature OS with MAC and SMP support SELinux > might be a good candidate. > However, Linux does not have jails. Only other OS that has them is > Solaris 10 which does not run on PPC. There's something named User Mode Linux which seems to be a little like jails. I haven't got the faintest idea how well it works. > I am not sure what kind of stack protection was referred in the > original email. OpenBSD has propolis, but I was under impression there > is no such option in FreeBSD. I recall that it was decided that > security by obscurity will not make it into the kernel. It's "propolice". Maybe http://www.trl.ibm.com/projects/security/ssp/buildfreebsd.html would be of interest. There's more than just obscurity to it, but it is obviously better to have correct code to begin with, then things like Propolice isn't needed... Have a nice day Morten -- http://m.mongers.org/ -- http://gallery.zentience.org/ __END__ From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 12 19:38:03 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 444AB16A4CE; Sun, 12 Sep 2004 19:38:03 +0000 (GMT) Received: from f20.mail.ru (f20.mail.ru [194.67.57.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0114B43D46; Sun, 12 Sep 2004 19:38:03 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f20.mail.ru with local id 1C6aAj-000O6U-00; Sun, 12 Sep 2004 23:38:01 +0400 Received: from [24.184.136.70] by msg.mail.ru with HTTP; Sun, 12 Sep 2004 23:38:01 +0400 From: Igor Shmukler To: David Leimbach Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.184.136.70] Date: Sun, 12 Sep 2004 23:38:01 +0400 In-Reply-To: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: freebsd-hackers@freebsd.org Subject: Re[4]: FreeBSD on Xserve? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Shmukler List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 19:38:03 -0000 > > Why do you think that 970 does not have BAT registers? > > There are 16 special purpose registers specifically to implement Block > > Address Translation. > > > > Because Peter already told us that they have no BAT registers: > > http://lists.freebsd.org/pipermail/freebsd-ppc/2004-February/000359.html I don't know what Peter said, but I do have documentation in front of me. In 7.4 of Programming Environments Manual we have an overview of BAT including BAT array organization. This comes as a shock to me. I am sending carbon copy to Peter Grehan, perhaps he could tell us where he got his information. I am not trying to suggest that you and/or him are wrong, but I cannot find (in manual) anything that would support your position that 970 has no block address translation. Regarding 16MB superpages, I believe manual explicitly says that 970 has no superpages, but I did not go through the doc again. Therefore, I could be mistaken. Regarding fans, it's not a big deal to support this kind of equipment. IMO, SMP support and other low-level stuff is order[s] of magnitude more complex. Igor. From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 12 19:54:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07FFE16A4CE for ; Sun, 12 Sep 2004 19:54:39 +0000 (GMT) Received: from f26.mail.ru (f26.mail.ru [194.67.57.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC8FF43D48 for ; Sun, 12 Sep 2004 19:54:38 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f26.mail.ru with local id 1C6aQi-000KyU-00; Sun, 12 Sep 2004 23:54:32 +0400 Received: from [24.184.136.70] by msg.mail.ru with HTTP; Sun, 12 Sep 2004 23:54:32 +0400 From: Igor Shmukler To: Morten Liebach Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.184.136.70] Date: Sun, 12 Sep 2004 23:54:32 +0400 In-Reply-To: <20040912183437.GF20097@mongers.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: freebsd-hackers@freebsd.org Subject: Re[2]: FreeBSD on Xserve? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Shmukler List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2004 19:54:39 -0000 > > If original author wants to mature OS with MAC and SMP support SELinux > > might be a good candidate. > > However, Linux does not have jails. Only other OS that has them is > > Solaris 10 which does not run on PPC. > > There's something named User Mode Linux which seems to be a little like > jails. I haven't got the faintest idea how well it works. I could be wrong, but AFAIK UML is not same thing as jail. AFAIK, UML has a serious performance penalty. It used to work pretty well for 2.4.x kernels. However, there are associated issues with keeping UML up to date. I don't think UML ever made it into mainline. Jail is part of kernel. Personally, I think that if jail was available on Apple hardware it would be a serious argument for using FreeBSD instead of Linux. IBM boxes support virtualization, but Apple machines don't have that feature. The flip side is that probably most people who buy G5 machines are more concerned about FP performance. > > I am not sure what kind of stack protection was referred in the > > original email. OpenBSD has propolis, but I was under impression there > > is no such option in FreeBSD. I recall that it was decided that > > security by obscurity will not make it into the kernel. > > It's "propolice". Thank you for correcting me. Indeed I did not spell propolice correctly. > Maybe http://www.trl.ibm.com/projects/security/ssp/buildfreebsd.html > would be of interest. > > There's more than just obscurity to it, but it is obviously better to > have correct code to begin with, then things like Propolice isn't > needed... That's a choice of terminilogy. The word obscurity has no mathematical style definition. From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 05:39:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEC8F16A4CE for ; Mon, 13 Sep 2004 05:39:41 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA8FF43D4C for ; Mon, 13 Sep 2004 05:39:40 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8D5d9rm021491 for ; Sun, 12 Sep 2004 23:39:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 12 Sep 2004 23:39:46 -0600 (MDT) Message-Id: <20040912.233946.30892794.imp@bsdimp.com> To: hackers@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Sep_12_23:39:46_2004_595)--" Content-Transfer-Encoding: 7bit Subject: Preliminary fdc patches X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2004 05:39:42 -0000 ----Next_Part(Sun_Sep_12_23:39:46_2004_595)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Can people test these? I seem to have only good, well behaved fdc devices :-) These patches should be considered experimental. I've tried them on one machine only. Warner ----Next_Part(Sun_Sep_12_23:39:46_2004_595)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=fdc-patch Index: fdc.c =================================================================== RCS file: /cache/ncvs/src/sys/dev/fdc/fdc.c,v retrieving revision 1.286 diff -u -r1.286 fdc.c --- fdc.c 27 Aug 2004 17:08:24 -0000 1.286 +++ fdc.c 13 Sep 2004 05:24:10 -0000 @@ -306,28 +306,28 @@ fdout_wr(struct fdc_data *fdc, u_int8_t v) { - bus_space_write_1(fdc->portt, fdc->porth, FDOUT+fdc->port_off, v); + bus_space_write_1(fdc->portt, fdc->porth, FDOUT + fdc->port_off, v); } static u_int8_t fdsts_rd(struct fdc_data *fdc) { - return bus_space_read_1(fdc->portt, fdc->porth, FDSTS+fdc->port_off); + return (bus_space_read_1(fdc->stst, fdc->stsh, FDSTS + fdc->sts_off)); } static void fddata_wr(struct fdc_data *fdc, u_int8_t v) { - bus_space_write_1(fdc->portt, fdc->porth, FDDATA+fdc->port_off, v); + bus_space_write_1(fdc->stst, fdc->stsh, FDDATA + fdc->sts_off, v); } static u_int8_t fddata_rd(struct fdc_data *fdc) { - return bus_space_read_1(fdc->portt, fdc->porth, FDDATA+fdc->port_off); + return (bus_space_read_1(fdc->stst, fdc->stsh, FDDATA + fdc->sts_off)); } static u_int8_t @@ -1484,39 +1484,30 @@ device_t dev; dev = fdc->fdc_dev; - if (fdc->fdc_intr) { + if (fdc->fdc_intr) BUS_TEARDOWN_INTR(device_get_parent(dev), dev, fdc->res_irq, fdc->fdc_intr); - fdc->fdc_intr = NULL; - } - if (fdc->res_irq != 0) { - bus_deactivate_resource(dev, SYS_RES_IRQ, fdc->rid_irq, - fdc->res_irq); + fdc->fdc_intr = NULL; + if (fdc->res_irq != NULL) bus_release_resource(dev, SYS_RES_IRQ, fdc->rid_irq, - fdc->res_irq); - fdc->res_irq = NULL; - } - if (fdc->res_ctl != 0) { - bus_deactivate_resource(dev, SYS_RES_IOPORT, fdc->rid_ctl, - fdc->res_ctl); + fdc->res_irq); + fdc->res_irq = NULL; + if (fdc->res_ctl != NULL && fdc->rid_ctl != -1) bus_release_resource(dev, SYS_RES_IOPORT, fdc->rid_ctl, - fdc->res_ctl); - fdc->res_ctl = NULL; - } - if (fdc->res_ioport != 0) { - bus_deactivate_resource(dev, SYS_RES_IOPORT, fdc->rid_ioport, - fdc->res_ioport); + fdc->res_ctl); + fdc->res_ctl = NULL; + if (fdc->res_sts != NULL && fdc->rid_sts != -1) + bus_release_resource(dev, SYS_RES_IOPORT, fdc->rid_sts, + fdc->res_sts); + fdc->res_sts = NULL; + if (fdc->res_ioport != NULL) bus_release_resource(dev, SYS_RES_IOPORT, fdc->rid_ioport, - fdc->res_ioport); - fdc->res_ioport = NULL; - } - if (fdc->res_drq != 0) { - bus_deactivate_resource(dev, SYS_RES_DRQ, fdc->rid_drq, - fdc->res_drq); + fdc->res_ioport); + fdc->res_ioport = NULL; + if (fdc->res_drq != NULL) bus_release_resource(dev, SYS_RES_DRQ, fdc->rid_drq, - fdc->res_drq); - fdc->res_drq = NULL; - } + fdc->res_drq); + fdc->res_drq = NULL; } int Index: fdc_isa.c =================================================================== RCS file: /cache/ncvs/src/sys/dev/fdc/fdc_isa.c,v retrieving revision 1.12 diff -u -r1.12 fdc_isa.c --- fdc_isa.c 31 Aug 2004 20:37:10 -0000 1.12 +++ fdc_isa.c 13 Sep 2004 05:33:58 -0000 @@ -57,9 +57,8 @@ int fdc_isa_alloc_resources(device_t dev, struct fdc_data *fdc) { - int ispnp, nports; + int nports = 6; - ispnp = (fdc->flags & FDC_ISPNP) != 0; fdc->fdc_dev = dev; fdc->rid_ioport = 0; fdc->rid_irq = 0; @@ -69,99 +68,84 @@ /* * On standard ISA, we don't just use an 8 port range * (e.g. 0x3f0-0x3f7) since that covers an IDE control - * register at 0x3f6. + * register at 0x3f6. So, on older hardware, we use + * 0x3f0-0x3f5 and 0x3f7. However, some BIOSs omit the + * control port, while others start at 0x3f2. Of the latter, + * sometimes we have two resources, other times we have one. + * We have to deal with the following cases: * - * Isn't PC hardware wonderful. + * 1: 0x3f0-0x3f5 # very rare + * 2: 0x3f0 # hints -> 0x3f0-0x3f5,0x3f7 + * 3: 0x3f0-0x3f5,0x3f7 # Most common + * 4: 0x3f2-0x3f5,0x3f7 # Second most common + * 5: 0x3f2-0x3f5 # implies 0x3f7 too. + * 6: 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 # becoming common + * 7: 0x3f2-0x3f3,0x3f4-0x3f5 # rare + * + * The following code is generic for any value of 0x3fx :-) */ - nports = ispnp ? 1 : 6; /* - * Some ACPI BIOSen have _CRS objects for the floppy device that - * split the I/O port resource into several resources. We detect - * this case by checking if there are more than 2 IOPORT resources. - * If so, we use the resource with the smallest start address as - * the port RID and the largest start address as the control RID. + * First, allocated the main range of ports. In the best of + * worlds, this is 4 or 6 ports. In others, well, that's + * why this function is so complicated. */ - if (bus_get_resource_count(dev, SYS_RES_IOPORT, 2) != 0) { - u_long min_start, max_start, tmp; - int i; - - /* Find the min/max start addresses and their RIDs. */ - max_start = 0ul; - min_start = ~0ul; - for (i = 0; bus_get_resource_count(dev, SYS_RES_IOPORT, i) > 0; - i++) { - tmp = bus_get_resource_start(dev, SYS_RES_IOPORT, i); - KASSERT(tmp != 0, ("bogus resource")); - if (tmp < min_start) { - min_start = tmp; - fdc->rid_ioport = i; - } - if (tmp > max_start) { - max_start = tmp; - fdc->rid_ctl = i; - } - } - } - fdc->res_ioport = bus_alloc_resource(dev, SYS_RES_IOPORT, &fdc->rid_ioport, 0ul, ~0ul, nports, RF_ACTIVE); if (fdc->res_ioport == 0) { - device_printf(dev, "cannot reserve I/O port range (%d ports)\n", - nports); - return ENXIO; + device_printf(dev, "cannot allocate I/O port (%d ports)\n", + nports); + return (ENXIO); } fdc->portt = rman_get_bustag(fdc->res_ioport); fdc->porth = rman_get_bushandle(fdc->res_ioport); /* - * Some BIOSen report the device at 0x3f2-0x3f5,0x3f7 - * and some at 0x3f0-0x3f5,0x3f7. We detect the former - * by checking the size and adjust the port address - * accordingly. + * Handle cases 4-7 above */ - if (bus_get_resource_count(dev, SYS_RES_IOPORT, 0) == 4) - fdc->port_off = -2; + fdc->port_off = -(fdc->porth & 0x7); /* - * Register the control port range as rid 1 if it - * isn't there already. Most PnP BIOSen will have - * already done this but non-PnP configurations don't. - * - * And some (!!) report 0x3f2-0x3f5 and completely - * leave out the control register! It seems that some - * non-antique controller chips have a different - * method of programming the transfer speed which - * doesn't require the control register, but it's - * mighty bogus as the chip still responds to the - * address for the control register. + * Deal with case 6 and 7: FDSTS and FDSATA are in rid 1. */ - if (bus_get_resource_count(dev, SYS_RES_IOPORT, 1) == 0) { - u_long ctlstart; - /* Find the control port, usually 0x3f7 */ - ctlstart = rman_get_start(fdc->res_ioport) + fdc->port_off + 7; - bus_set_resource(dev, SYS_RES_IOPORT, 1, ctlstart, 1); + if (rman_get_size(fdc->res_ioport) == 2) { + fdc->rid_sts = 1; + fdc->res_sts = bus_alloc_resource_any(dev, SYS_RES_IOPORT, + &fdc->rid_sts, RF_ACTIVE); + if (fdc->res_sts == NULL) { + device_printf(dev, "Can't alloc rid 1"); + fdc_release_resources(fdc); + return (ENXIO); + } + fdc->rid_ctl++; + fdc->sts_off = -4; + } else { + fdc->res_sts = NULL; + fdc->sts_off = fdc->port_off; } + fdc->stst = rman_get_bustag(fdc->res_sts); + fdc->stsh = rman_get_bushandle(fdc->res_sts); /* - * Now (finally!) allocate the control port. + * allocate the control port. For cases 1, 2, 5 and 7, we + * fake it from the ioports resource. */ fdc->res_ctl = bus_alloc_resource_any(dev, SYS_RES_IOPORT, &fdc->rid_ctl, RF_ACTIVE); - if (fdc->res_ctl == 0) { - device_printf(dev, - "cannot reserve control I/O port range (control port)\n"); - return ENXIO; + if (fdc->res_ctl == NULL) { + fdc->ctl_off = 7 + fdc->port_off; + fdc->res_ctl = NULL; + } else { + fdc->ctl_off = 0; } fdc->ctlt = rman_get_bustag(fdc->res_ctl); fdc->ctlh = rman_get_bushandle(fdc->res_ctl); - fdc->ctl_off = 0; fdc->res_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, &fdc->rid_irq, - RF_ACTIVE | RF_SHAREABLE); + RF_ACTIVE | RF_SHAREABLE); if (fdc->res_irq == 0) { device_printf(dev, "cannot reserve interrupt line\n"); - return ENXIO; + return (ENXIO); } if ((fdc->flags & FDC_NODMA) == 0) { @@ -169,12 +153,13 @@ &fdc->rid_drq, RF_ACTIVE | RF_SHAREABLE); if (fdc->res_drq == 0) { device_printf(dev, "cannot reserve DMA request line\n"); + /* This is broken and doesn't work for ISA case */ fdc->flags |= FDC_NODMA; } else fdc->dmachan = rman_get_start(fdc->res_drq); } - return 0; + return (0); } static int Index: fdc_pccard.c =================================================================== RCS file: /cache/ncvs/src/sys/dev/fdc/fdc_pccard.c,v retrieving revision 1.9 diff -u -r1.9 fdc_pccard.c --- fdc_pccard.c 20 Aug 2004 15:14:25 -0000 1.9 +++ fdc_pccard.c 13 Sep 2004 05:34:23 -0000 @@ -65,6 +65,9 @@ } fdc->portt = rman_get_bustag(fdc->res_ioport); fdc->porth = rman_get_bushandle(fdc->res_ioport); + fdc->stst = fdc->portt; + fdc->stsh = fdc->porth; + fdc->sts_off = 0; fdc->ctlt = fdc->portt; fdc->ctlh = fdc->porth; fdc->ctl_off = 7; Index: fdcvar.h =================================================================== RCS file: /cache/ncvs/src/sys/dev/fdc/fdcvar.h,v retrieving revision 1.4 diff -u -r1.4 fdcvar.h --- fdcvar.h 20 Aug 2004 15:14:25 -0000 1.4 +++ fdcvar.h 13 Sep 2004 05:30:09 -0000 @@ -57,14 +57,17 @@ int fdc_errs; /* number of logged errors */ struct bio_queue_head head; struct bio *bp; /* active buffer */ - struct resource *res_ioport, *res_ctl, *res_irq, *res_drq; - int rid_ioport, rid_ctl, rid_irq, rid_drq; - int port_off; + struct resource *res_ioport, *res_sts, *res_ctl, *res_irq, *res_drq; + int rid_ioport, rid_sts, rid_ctl, rid_irq, rid_drq; bus_space_tag_t portt; bus_space_handle_t porth; + bus_space_tag_t stst; + bus_space_handle_t stsh; bus_space_tag_t ctlt; bus_space_handle_t ctlh; + int port_off; int ctl_off; + int sts_off; void *fdc_intr; struct device *fdc_dev; struct mtx fdc_mtx; ----Next_Part(Sun_Sep_12_23:39:46_2004_595)---- From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 06:03:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E83EC16A4CE for ; Mon, 13 Sep 2004 06:03:49 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4318643D2F for ; Mon, 13 Sep 2004 06:03:49 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8D62PZE021784 for ; Mon, 13 Sep 2004 00:02:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 13 Sep 2004 00:03:02 -0600 (MDT) Message-Id: <20040913.000302.94315208.imp@bsdimp.com> To: hackers@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040912.233946.30892794.imp@bsdimp.com> References: <20040912.233946.30892794.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Sep_13_00:03:02_2004_037)--" Content-Transfer-Encoding: 7bit Subject: Re: Preliminary fdc patches X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2004 06:03:50 -0000 ----Next_Part(Mon_Sep_13_00:03:02_2004_037)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit In message: <20040912.233946.30892794.imp@bsdimp.com> "M. Warner Losh" writes: : Can people test these? I seem to have only good, well behaved fdc : devices :-) These patches should be considered experimental. I've : tried them on one machine only. Hmmm. Last minute changes suck. The last patch will crash in some cease. This one should be a lot better. Warner ----Next_Part(Mon_Sep_13_00:03:02_2004_037)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=fdc-diff Only in /dell/imp/FreeBSD/src/sys/dev/fdc: .#fdc.c.1.276 Only in /dell/imp/FreeBSD/src/sys/dev/fdc: CVS Only in .: fd.c diff -du /dell/imp/FreeBSD/src/sys/dev/fdc/fdc.c ./fdc.c --- /dell/imp/FreeBSD/src/sys/dev/fdc/fdc.c Mon Sep 13 00:01:47 2004 +++ ./fdc.c Sun Sep 12 23:59:09 2004 @@ -197,9 +197,18 @@ #define FDCTL 7 /* Control Register (W) */ /* - * this is the secret PIO data port (offset from base) + * The YE-DATA PC Card floppies use PIO to read in the data rather than + * DMA due to the wild variability of DMA for the PC Card devices. In + * addition, if we cannot setup the DMA resources for the ISA attachment, + * we'll use this same offset for data transfer. + * + * For this mode, offset 0 and 1 must be used to setup the transfer + * for this floppy. This means they are only available on those systems + * that map them to the floppy drive. Newer systems do not do this, and + * we should likely prohibit access to them (or disallow NODMA to be set). */ -#define FDC_YE_DATAPORT 6 +#define FDBCDR 0 /* And 1 */ +#define FD_YE_DATAPORT 6 /* Drive Data port */ #define FDI_DCHG 0x80 /* diskette has been changed */ /* requires drive and motor being selected */ @@ -337,6 +346,19 @@ return bus_space_read_1(fdc->ctlt, fdc->ctlh, fdc->ctl_off); } +/* + * Magic pseudo-DMA initialization for YE FDC. Sets count and + * direction. + */ +static void +fdbcdr_wr(struct fdc_data *fdc, int iswrite, uint16_t count) +{ + bus_space_write_1(fdc->portt, fdc->porth, fdc->port_off + FDBCDR, + (count - 1) & 0xff); + bus_space_write_1(fdc->portt, fdc->porth, fdc->port_off + FDBCDR + 1, + ((iswrite ? 0x80 : 0) | (((count - 1) >> 8) & 0x7f))); +} + static int fdc_err(struct fdc_data *fdc, const char *s) { @@ -634,18 +656,6 @@ } /* - * Magic pseudo-DMA initialization for YE FDC. Sets count and - * direction. - */ -#define SET_BCDR(fdc,wr,cnt,port) \ - do { \ - bus_space_write_1(fdc->portt, fdc->porth, fdc->port_off + port, \ - ((cnt)-1) & 0xff); \ - bus_space_write_1(fdc->portt, fdc->porth, fdc->port_off + port + 1, \ - ((wr ? 0x80 : 0) | ((((cnt)-1) >> 8) & 0x7f))); \ - } while (0) - -/* * fdc_pio(): perform programmed IO read/write for YE PCMCIA floppy. */ static void @@ -660,13 +670,13 @@ count = fdc->fd->fd_iosize; if (bp->bio_cmd == BIO_READ) { - SET_BCDR(fdc, 0, count, 0); + fdbcdr_wr(fdc, 0, count); bus_space_read_multi_1(fdc->portt, fdc->porth, fdc->port_off + - FDC_YE_DATAPORT, cptr, count); + FD_YE_DATAPORT, cptr, count); } else { bus_space_write_multi_1(fdc->portt, fdc->porth, fdc->port_off + - FDC_YE_DATAPORT, cptr, count); - SET_BCDR(fdc, 0, count, 0); + FD_YE_DATAPORT, cptr, count); + fdbcdr_wr(fdc, 0, count); /* needed? */ } } @@ -940,7 +950,7 @@ /* Do PIO if we have to */ if (fdc->flags & FDC_NODMA) { if (bp->bio_cmd & (BIO_READ|BIO_WRITE|BIO_FMT)) - SET_BCDR(fdc, 1, fd->fd_iosize, 0); + fdbcdr_wr(fdc, 1, fd->fd_iosize); if (bp->bio_cmd & (BIO_WRITE|BIO_FMT)) fdc_pio(fdc); } @@ -1484,39 +1494,30 @@ device_t dev; dev = fdc->fdc_dev; - if (fdc->fdc_intr) { + if (fdc->fdc_intr) BUS_TEARDOWN_INTR(device_get_parent(dev), dev, fdc->res_irq, fdc->fdc_intr); - fdc->fdc_intr = NULL; - } - if (fdc->res_irq != 0) { - bus_deactivate_resource(dev, SYS_RES_IRQ, fdc->rid_irq, - fdc->res_irq); + fdc->fdc_intr = NULL; + if (fdc->res_irq != NULL) bus_release_resource(dev, SYS_RES_IRQ, fdc->rid_irq, - fdc->res_irq); - fdc->res_irq = NULL; - } - if (fdc->res_ctl != 0) { - bus_deactivate_resource(dev, SYS_RES_IOPORT, fdc->rid_ctl, - fdc->res_ctl); + fdc->res_irq); + fdc->res_irq = NULL; + if (fdc->res_ctl != NULL) bus_release_resource(dev, SYS_RES_IOPORT, fdc->rid_ctl, - fdc->res_ctl); - fdc->res_ctl = NULL; - } - if (fdc->res_ioport != 0) { - bus_deactivate_resource(dev, SYS_RES_IOPORT, fdc->rid_ioport, - fdc->res_ioport); + fdc->res_ctl); + fdc->res_ctl = NULL; + if (fdc->res_sts != NULL) + bus_release_resource(dev, SYS_RES_IOPORT, fdc->rid_sts, + fdc->res_sts); + fdc->res_sts = NULL; + if (fdc->res_ioport != NULL) bus_release_resource(dev, SYS_RES_IOPORT, fdc->rid_ioport, - fdc->res_ioport); - fdc->res_ioport = NULL; - } - if (fdc->res_drq != 0) { - bus_deactivate_resource(dev, SYS_RES_DRQ, fdc->rid_drq, - fdc->res_drq); + fdc->res_ioport); + fdc->res_ioport = NULL; + if (fdc->res_drq != NULL) bus_release_resource(dev, SYS_RES_DRQ, fdc->rid_drq, - fdc->res_drq); - fdc->res_drq = NULL; - } + fdc->res_drq); + fdc->res_drq = NULL; } int diff -du /dell/imp/FreeBSD/src/sys/dev/fdc/fdc_isa.c ./fdc_isa.c --- /dell/imp/FreeBSD/src/sys/dev/fdc/fdc_isa.c Mon Sep 13 00:01:47 2004 +++ ./fdc_isa.c Sun Sep 12 23:59:09 2004 @@ -57,9 +57,8 @@ int fdc_isa_alloc_resources(device_t dev, struct fdc_data *fdc) { - int ispnp, nports; + int nports = 6; - ispnp = (fdc->flags & FDC_ISPNP) != 0; fdc->fdc_dev = dev; fdc->rid_ioport = 0; fdc->rid_irq = 0; @@ -69,99 +68,84 @@ /* * On standard ISA, we don't just use an 8 port range * (e.g. 0x3f0-0x3f7) since that covers an IDE control - * register at 0x3f6. + * register at 0x3f6. So, on older hardware, we use + * 0x3f0-0x3f5 and 0x3f7. However, some BIOSs omit the + * control port, while others start at 0x3f2. Of the latter, + * sometimes we have two resources, other times we have one. + * We have to deal with the following cases: * - * Isn't PC hardware wonderful. + * 1: 0x3f0-0x3f5 # very rare + * 2: 0x3f0 # hints -> 0x3f0-0x3f5,0x3f7 + * 3: 0x3f0-0x3f5,0x3f7 # Most common + * 4: 0x3f2-0x3f5,0x3f7 # Second most common + * 5: 0x3f2-0x3f5 # implies 0x3f7 too. + * 6: 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 # becoming common + * 7: 0x3f2-0x3f3,0x3f4-0x3f5 # rare + * + * The following code is generic for any value of 0x3fx :-) */ - nports = ispnp ? 1 : 6; /* - * Some ACPI BIOSen have _CRS objects for the floppy device that - * split the I/O port resource into several resources. We detect - * this case by checking if there are more than 2 IOPORT resources. - * If so, we use the resource with the smallest start address as - * the port RID and the largest start address as the control RID. + * First, allocated the main range of ports. In the best of + * worlds, this is 4 or 6 ports. In others, well, that's + * why this function is so complicated. */ - if (bus_get_resource_count(dev, SYS_RES_IOPORT, 2) != 0) { - u_long min_start, max_start, tmp; - int i; - - /* Find the min/max start addresses and their RIDs. */ - max_start = 0ul; - min_start = ~0ul; - for (i = 0; bus_get_resource_count(dev, SYS_RES_IOPORT, i) > 0; - i++) { - tmp = bus_get_resource_start(dev, SYS_RES_IOPORT, i); - KASSERT(tmp != 0, ("bogus resource")); - if (tmp < min_start) { - min_start = tmp; - fdc->rid_ioport = i; - } - if (tmp > max_start) { - max_start = tmp; - fdc->rid_ctl = i; - } - } - } - fdc->res_ioport = bus_alloc_resource(dev, SYS_RES_IOPORT, &fdc->rid_ioport, 0ul, ~0ul, nports, RF_ACTIVE); if (fdc->res_ioport == 0) { - device_printf(dev, "cannot reserve I/O port range (%d ports)\n", - nports); - return ENXIO; + device_printf(dev, "cannot allocate I/O port (%d ports)\n", + nports); + return (ENXIO); } fdc->portt = rman_get_bustag(fdc->res_ioport); fdc->porth = rman_get_bushandle(fdc->res_ioport); /* - * Some BIOSen report the device at 0x3f2-0x3f5,0x3f7 - * and some at 0x3f0-0x3f5,0x3f7. We detect the former - * by checking the size and adjust the port address - * accordingly. + * Handle cases 4-7 above */ - if (bus_get_resource_count(dev, SYS_RES_IOPORT, 0) == 4) - fdc->port_off = -2; + fdc->port_off = -(fdc->porth & 0x7); /* - * Register the control port range as rid 1 if it - * isn't there already. Most PnP BIOSen will have - * already done this but non-PnP configurations don't. - * - * And some (!!) report 0x3f2-0x3f5 and completely - * leave out the control register! It seems that some - * non-antique controller chips have a different - * method of programming the transfer speed which - * doesn't require the control register, but it's - * mighty bogus as the chip still responds to the - * address for the control register. + * Deal with case 6 and 7: FDSTS and FDSATA are in rid 1. */ - if (bus_get_resource_count(dev, SYS_RES_IOPORT, 1) == 0) { - u_long ctlstart; - /* Find the control port, usually 0x3f7 */ - ctlstart = rman_get_start(fdc->res_ioport) + fdc->port_off + 7; - bus_set_resource(dev, SYS_RES_IOPORT, 1, ctlstart, 1); + if (rman_get_size(fdc->res_ioport) == 2) { + fdc->rid_sts = 1; + fdc->res_sts = bus_alloc_resource_any(dev, SYS_RES_IOPORT, + &fdc->rid_sts, RF_ACTIVE); + if (fdc->res_sts == NULL) { + device_printf(dev, "Can't alloc rid 1"); + fdc_release_resources(fdc); + return (ENXIO); + } + fdc->rid_ctl++; + fdc->sts_off = -4; + } else { + fdc->res_sts = NULL; + fdc->sts_off = fdc->port_off; } + fdc->stst = rman_get_bustag(fdc->res_sts); + fdc->stsh = rman_get_bushandle(fdc->res_sts); /* - * Now (finally!) allocate the control port. + * allocate the control port. For cases 1, 2, 5 and 7, we + * fake it from the ioports resource. */ fdc->res_ctl = bus_alloc_resource_any(dev, SYS_RES_IOPORT, &fdc->rid_ctl, RF_ACTIVE); - if (fdc->res_ctl == 0) { - device_printf(dev, - "cannot reserve control I/O port range (control port)\n"); - return ENXIO; + if (fdc->res_ctl == NULL) { + fdc->ctl_off = 7 + fdc->port_off; + fdc->res_ctl = NULL; + } else { + fdc->ctl_off = 0; } fdc->ctlt = rman_get_bustag(fdc->res_ctl); fdc->ctlh = rman_get_bushandle(fdc->res_ctl); - fdc->ctl_off = 0; fdc->res_irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, &fdc->rid_irq, - RF_ACTIVE | RF_SHAREABLE); + RF_ACTIVE | RF_SHAREABLE); if (fdc->res_irq == 0) { device_printf(dev, "cannot reserve interrupt line\n"); - return ENXIO; + return (ENXIO); } if ((fdc->flags & FDC_NODMA) == 0) { @@ -169,12 +153,13 @@ &fdc->rid_drq, RF_ACTIVE | RF_SHAREABLE); if (fdc->res_drq == 0) { device_printf(dev, "cannot reserve DMA request line\n"); + /* This is broken and doesn't work for ISA case */ fdc->flags |= FDC_NODMA; } else fdc->dmachan = rman_get_start(fdc->res_drq); } - return 0; + return (0); } static int diff -du /dell/imp/FreeBSD/src/sys/dev/fdc/fdc_pccard.c ./fdc_pccard.c --- /dell/imp/FreeBSD/src/sys/dev/fdc/fdc_pccard.c Mon Sep 13 00:01:47 2004 +++ ./fdc_pccard.c Sun Sep 12 23:53:01 2004 @@ -65,6 +65,9 @@ } fdc->portt = rman_get_bustag(fdc->res_ioport); fdc->porth = rman_get_bushandle(fdc->res_ioport); + fdc->stst = fdc->portt; + fdc->stsh = fdc->porth; + fdc->sts_off = 0; fdc->ctlt = fdc->portt; fdc->ctlh = fdc->porth; fdc->ctl_off = 7; diff -du /dell/imp/FreeBSD/src/sys/dev/fdc/fdcvar.h ./fdcvar.h --- /dell/imp/FreeBSD/src/sys/dev/fdc/fdcvar.h Mon Sep 13 00:01:47 2004 +++ ./fdcvar.h Sun Sep 12 23:59:09 2004 @@ -57,14 +57,17 @@ int fdc_errs; /* number of logged errors */ struct bio_queue_head head; struct bio *bp; /* active buffer */ - struct resource *res_ioport, *res_ctl, *res_irq, *res_drq; - int rid_ioport, rid_ctl, rid_irq, rid_drq; - int port_off; + struct resource *res_ioport, *res_sts, *res_ctl, *res_irq, *res_drq; + int rid_ioport, rid_sts, rid_ctl, rid_irq, rid_drq; bus_space_tag_t portt; bus_space_handle_t porth; + bus_space_tag_t stst; + bus_space_handle_t stsh; bus_space_tag_t ctlt; bus_space_handle_t ctlh; + int port_off; int ctl_off; + int sts_off; void *fdc_intr; struct device *fdc_dev; struct mtx fdc_mtx; ----Next_Part(Mon_Sep_13_00:03:02_2004_037)---- From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 06:30:38 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F173916A4CE for ; Mon, 13 Sep 2004 06:30:38 +0000 (GMT) Received: from f27.mail.ru (f27.mail.ru [194.67.57.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87E3E43D1D for ; Mon, 13 Sep 2004 06:30:38 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f27.mail.ru with local id 1C6kMG-000FsK-00; Mon, 13 Sep 2004 10:30:36 +0400 Received: from [68.160.197.203] by msg.mail.ru with HTTP; Mon, 13 Sep 2004 10:30:35 +0400 From: Igor Shmukler To: peterg@ptree32.com.au Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [68.160.197.203] Date: Mon, 13 Sep 2004 10:30:35 +0400 In-Reply-To: <200409130607.AGL36193@dommail.onthenet.com.au> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: freebsd-hackers@freebsd.org Subject: Re[6]: FreeBSD on Xserve? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Shmukler List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 06:30:39 -0000 That's true indeed. Below is a quote from http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/AB70A3470F9CC0E287256ECC006D6A54/$file/970-software.pdf The implementation of memory management in the 64-bit PowerPC processors is significantly different from the 32-bit PowerPC implementations. The support for BAT (Block Address Translation) is no longer available in the PowerPC 970FX processor and in the 64-bit PowerPC architecture. The removal of the BAT mechanism will require all application programs to enable the MMU (Memory Management Unit) in order to access non-cachable memory. It's very strange that original manual states quite the opposite. Igor. -----Original Message----- From: To: Igor Shmukler Date: Mon, 13 Sep 2004 16:07:45 +1000 Subject: Re: Re[4]: FreeBSD on Xserve ? > > >I am not trying to suggest that you and/or him are wrong, > >but I cannot find (in manual) anything that would support > >your position that 970 has no block address translation. > >Regarding 16MB superpages, I believe manual explicitly says > >that 970 has no superpages, but I did not go through the doc > >again. Therefore, I could be mistaken. > > I think there's an IBM technote that states there are > no BATs on the 970. Linux source has comments to that > effect as well. > > And before I found that info, I tried in vain to get it > to work on my G5. > > later, > > Peter. From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 07:20:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD99716A4CE; Mon, 13 Sep 2004 07:20:37 +0000 (GMT) Received: from cydem.org (S0106000103ce4c9c.ed.shawcable.net [68.149.254.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47D7943D31; Mon, 13 Sep 2004 07:20:37 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from S01060020ed3972ba.ed.shawcable.net (S01060020ed3972ba.ed.shawcable.net [68.149.254.42]) by cydem.org (Postfix/FreeBSD) with ESMTP id 425A2381BA; Mon, 13 Sep 2004 01:20:36 -0600 (MDT) From: To: freebsd-hardware@freebsd.org Date: Mon, 13 Sep 2004 01:20:35 -0600 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409130120.35057.soralx@cydem.org> cc: freebsd-hackers@freebsd.org cc: freebsd-small@freebsd.org cc: freebsd-mobile@freebsd.org Subject: 586Core X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2004 07:20:38 -0000 Good localtime() I'm starting some small project, and I need to decide what hardware will fit its needs. I'm looking for a small single-board computer that should have minimum: 2 serial ports (RS232 & [RS232 | USB(preferable)]), 8-bit databus, FLASH disk, RTC, 486 CPU performance, low power consumption; should be able to run FreeBSD. PCB size does not matter much. One of the applications I plan to run on it is 'gnokii'. I've found this: 'http://www.compulab.co.il/586core.htm', and I'd appreciate to get some opinions on this product. Is anyone using it? How well does it work with FreeBSD (or *BSD)? How well FBSD works with its USB controller (ScanLogic SL811HST)? Maybe someone can suggest a better and possibly less expensive alternative? I'd like to get as many opinions as possible, therefore crossposting. Sorry. Timestamp: 0x41453D16 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 07:24:20 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76D2A16A4CE for ; Mon, 13 Sep 2004 07:24:20 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 847A843D58 for ; Mon, 13 Sep 2004 07:24:19 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (d7l6ctmn@localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id i8D7OA8J051356; Mon, 13 Sep 2004 11:24:10 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Mon, 13 Sep 2004 11:24:10 +0400 (MSD) From: Maxim Konovalov To: soralx@cydem.org In-Reply-To: <200409130120.35057.soralx@cydem.org> Message-ID: <20040913112301.H51189@mp2.macomnet.net> References: <200409130120.35057.soralx@cydem.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: 586Core X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2004 07:24:20 -0000 [ Excessive crosspost ] On Mon, 13 Sep 2004, 01:20-0600, soralx@cydem.org wrote: > > Good localtime() > > I'm starting some small project, and I need to decide what hardware > will fit its needs. I'm looking for a small single-board computer that > should have minimum: 2 serial ports (RS232 & [RS232 | USB(preferable)]), > 8-bit databus, FLASH disk, RTC, 486 CPU performance, low power consumption; > should be able to run FreeBSD. PCB size does not matter much. One > of the applications I plan to run on it is 'gnokii'. > > I've found this: 'http://www.compulab.co.il/586core.htm', and I'd appreciate > to get some opinions on this product. Is anyone using it? How well does it > work with FreeBSD (or *BSD)? How well FBSD works with its USB controller > (ScanLogic SL811HST)? > > Maybe someone can suggest a better and possibly less expensive alternative? http://soekris.com/ ? -- Maxim Konovalov From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 11:51:10 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCE4416A4CE for ; Mon, 13 Sep 2004 11:51:10 +0000 (GMT) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFD2B43D58 for ; Mon, 13 Sep 2004 11:51:09 +0000 (GMT) (envelope-from tbyte@OTEL.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.30; FreeBSD) id 1C6pMO-0000Ge-U9; Mon, 13 Sep 2004 14:51:04 +0300 Message-ID: <4145899C.6040800@OTEL.net> Date: Mon, 13 Sep 2004 14:50:52 +0300 From: Iasen Kostov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vxp References: <20040910212926.V2370@digital-security.org> In-Reply-To: <20040910212926.V2370@digital-security.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: help with a module, please.. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2004 11:51:10 -0000 vxp wrote: >hi > >this is another one of my possibly lame questions.. >so i wrote a module, it compiles with a few warnings (was too lazy to put >func prototypes, so it outputs warnings about that). > >among other things, the compilation produces an icmp.ko (name of my mod) >but when i try to do kldload ./icmp.ko it tells me: >digital-security# kldload icmp.kld >kldload: can't load icmp.kld: No such file or directory >digital-security# ls -l icmp.* >-rw-r--r-- 1 vxp vxp 12702 Sep 10 21:28 icmp.c >-rw-r--r-- 1 vxp vxp 5276 Sep 10 21:31 icmp.kld >-rwxr-xr-x 1 vxp vxp 7548 Sep 10 21:31 icmp.ko >-rw-r--r-- 1 vxp vxp 5148 Sep 10 21:31 icmp.o >digital-security# > >what gives? :) > >may be i screwed up, somehow, in my load_handler? > >static int >load_handler(module_t mod, int what, void *arg) >{ > variable declarations here.. > > case MOD_LOAD: > blah blah blah > break; > case MOD_UNLOAD: > blah blah blah > break; > default: > err = EINVAL; > break; > } > return(err); >} > > >static moduledata_t icmp_mod = { > "RebootByICMP", > load_handler, > NULL >}; > >DECLARE_MODULE(icmp, icmp_mod, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); > > > >any help appreciated :) > >can post full src, if needed.. > >thanks, > >Val >_______________________________________________ >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" > > > Don't be fooled by the message "No such file or directory" - it's a problem with the module itself (that sym "min") - and the kldload alway says "No such file or directory" ... :) From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 12:01:43 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C292116A4CF for ; Mon, 13 Sep 2004 12:01:43 +0000 (GMT) Received: from sulu.ae.katowice.pl (sulu.ae.katowice.pl [213.227.88.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C21143D53 for ; Mon, 13 Sep 2004 12:01:43 +0000 (GMT) (envelope-from asledzik@ae.katowice.pl) Received: from sulu.ae.katowice.pl (localhost [127.0.0.1]) by sulu.ae.katowice.pl (8.13.0/8.12.11) with ESMTP id i8DC1fhP186041 for ; Mon, 13 Sep 2004 14:01:42 +0200 (CEST) Received: from localhost (asledzik@localhost)i8DC1doc184588 for ; Mon, 13 Sep 2004 14:01:39 +0200 (CEST) X-Authentication-Warning: sulu.ae.katowice.pl: asledzik owned process doing -bs Date: Mon, 13 Sep 2004 14:01:39 +0200 (CEST) From: Joanna Sledzik To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: struct proc - basic question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 12:01:43 -0000 Hi :) I'm very very begginer in Unix system programming. What function should I use to catch the struct proc for some process? Is it possible to get the pointer to struct proc using for example the pid_t pid as an argument? Thanks for help Joanna Sledzik From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 12:29:26 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A499D16A4CE for ; Mon, 13 Sep 2004 12:29:26 +0000 (GMT) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEC5D43D5C for ; Mon, 13 Sep 2004 12:29:24 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from [61.8.46.197] (ppp2EC5.dyn.pacific.net.au [61.8.46.197]) i8DCSaRw006013; Mon, 13 Sep 2004 22:28:36 +1000 From: Sam Lawrance To: Joanna Sledzik In-Reply-To: References: Content-Type: text/plain Message-Id: <1095078631.77709.53.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 13 Sep 2004 22:30:31 +1000 Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: struct proc - basic question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 12:29:26 -0000 On Mon, 2004-09-13 at 22:01, Joanna Sledzik wrote: > Hi :) > I'm very very begginer in Unix system programming. > What function should I use to catch the struct proc for some process? > Is it possible to get the pointer to struct proc using for example the pid_t pid > as an argument? >From userland, maybe the kvm_* functions will do what you want. See the kvm, kvm_open and kvm_getprocs manpages. -Sam From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 12:50:02 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7505D16A4CE for ; Mon, 13 Sep 2004 12:50:02 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id E006D43D41 for ; Mon, 13 Sep 2004 12:50:00 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 32326 invoked from network); 13 Sep 2004 12:47:38 -0000 Received: from unknown (HELO straylight.m.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 13 Sep 2004 12:47:38 -0000 Received: (qmail 39006 invoked by uid 1000); 13 Sep 2004 12:50:30 -0000 Date: Mon, 13 Sep 2004 15:50:30 +0300 From: Peter Pentchev To: Joanna Sledzik Message-ID: <20040913125030.GA839@straylight.m.ringlet.net> Mail-Followup-To: Joanna Sledzik , freebsd-hackers@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: struct proc - basic question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 12:50:02 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 13, 2004 at 02:01:39PM +0200, Joanna Sledzik wrote: > Hi :) > I'm very very begginer in Unix system programming. > What function should I use to catch the struct proc for some process? > Is it possible to get the pointer to struct proc using for example the > pid_t pid as an argument? Yes, the function you are looking for is #include struct proc *pfind(pid_t pid) You pass it a pid_t argument and it returns a pointer to a proc structure. However, note that the pfind() function is only available to code running in kernel space - it has to be invoked either from a kernel module, or from code compiled into the kernel itself. If you want to get a process's struct proc from a user-space program, there are two ways to go about it: - use libkvm to muck around the kernel's memory: this is a pretty bad approach for most cases, especially as the kernel's internal structures may change even as you try to examine them and follow the list pointers. If you choose this approach, take a look at the kvm(3) manual page, and note that you need to look for the 'allproc' list, which is usually a singly-linked list, but see for details. - use the sysctl(3) interface to fetch the value of the kern.proc.all sysctl. It is a snapshot of the current process info, see the kinfo_proc structure and the comments around it in the file for more information. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If the meanings of 'true' and 'false' were switched, then this sentence wou= ldn't be false. --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBRZeW7Ri2jRYZRVMRAnaVAKCTwF7LoaEGSt6oLXYG6/GAM/MGmQCgtet9 fNgiz7pbIRX6YSUqls1YD5E= =ecit -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 12:50:38 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 290AB16A4CE for ; Mon, 13 Sep 2004 12:50:38 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 0787E43D41 for ; Mon, 13 Sep 2004 12:50:37 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 32757 invoked from network); 13 Sep 2004 12:48:15 -0000 Received: from unknown (HELO straylight.m.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 13 Sep 2004 12:48:15 -0000 Received: (qmail 39030 invoked by uid 1000); 13 Sep 2004 12:51:07 -0000 Date: Mon, 13 Sep 2004 15:51:07 +0300 From: Peter Pentchev To: Sam Lawrance Message-ID: <20040913125107.GB839@straylight.m.ringlet.net> Mail-Followup-To: Sam Lawrance , Joanna Sledzik , freebsd-hackers@freebsd.org References: <1095078631.77709.53.camel@dirk.no.domain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline In-Reply-To: <1095078631.77709.53.camel@dirk.no.domain> User-Agent: Mutt/1.5.6i cc: Joanna Sledzik cc: freebsd-hackers@freebsd.org Subject: Re: struct proc - basic question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 12:50:38 -0000 --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 13, 2004 at 10:30:31PM +1000, Sam Lawrance wrote: > On Mon, 2004-09-13 at 22:01, Joanna Sledzik wrote: > > Hi :) > > I'm very very begginer in Unix system programming. > > What function should I use to catch the struct proc for some process? > > Is it possible to get the pointer to struct proc using for example the = pid_t pid > > as an argument? >=20 > >From userland, maybe the kvm_* functions will do what you want. > See the kvm, kvm_open and kvm_getprocs manpages. The kern.proc.all sysctl might be a better idea; see my other e-mail for details. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am jealous of the first word in this sentence. --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBRZe77Ri2jRYZRVMRAlbSAKCxllbLZFZ62qaF1VLwlpXEMrAzXgCfd0Rn I5KmAXGltV72jXjd6zHEr2k= =gVog -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M-- From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 13:15:51 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 120DD16A4CE for ; Mon, 13 Sep 2004 13:15:51 +0000 (GMT) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E72F43D54 for ; Mon, 13 Sep 2004 13:15:49 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from [61.8.46.197] (ppp2EC5.dyn.pacific.net.au [61.8.46.197]) i8DDF9Vw024508; Mon, 13 Sep 2004 23:15:10 +1000 From: Sam Lawrance To: Peter Pentchev In-Reply-To: <20040913125107.GB839@straylight.m.ringlet.net> References: <1095078631.77709.53.camel@dirk.no.domain> <20040913125107.GB839@straylight.m.ringlet.net> Content-Type: text/plain Message-Id: <1095081425.77709.62.camel@dirk.no.domain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 13 Sep 2004 23:17:05 +1000 Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: struct proc - basic question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2004 13:15:51 -0000 On Mon, 2004-09-13 at 22:51, Peter Pentchev wrote: > On Mon, Sep 13, 2004 at 10:30:31PM +1000, Sam Lawrance wrote: > > On Mon, 2004-09-13 at 22:01, Joanna Sledzik wrote: > > > Hi :) > > > I'm very very begginer in Unix system programming. > > > What function should I use to catch the struct proc for some process? > > > Is it possible to get the pointer to struct proc using for example the pid_t pid > > > as an argument? > > > > >From userland, maybe the kvm_* functions will do what you want. > > See the kvm, kvm_open and kvm_getprocs manpages. > > The kern.proc.all sysctl might be a better idea; see my other e-mail for > details. > Is there a functional difference? kvm_getprocs uses the kern.proc sysctls anyway. I did note the comment in the manpage that "these routines do not belong in the kvm interface". -Sam From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 12 18:16:19 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7CD216A4CE for ; Sun, 12 Sep 2004 18:16:19 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id B525E43D39 for ; Sun, 12 Sep 2004 18:16:19 +0000 (GMT) (envelope-from leimy2k@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i8CIGJjY011232; Sun, 12 Sep 2004 11:16:19 -0700 (PDT) Received: from [192.168.1.100] (c-67-165-114-246.client.comcast.net [67.165.114.246]) (authenticated bits=0)i8CIGIvl005670; Sun, 12 Sep 2004 11:16:18 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Leimbach Date: Sun, 12 Sep 2004 11:16:16 -0700 To: Igor Shmukler X-Mailer: Apple Mail (2.619) X-Mailman-Approved-At: Mon, 13 Sep 2004 15:13:54 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: Re[2]: FreeBSD on Xserve ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Sep 2004 18:16:20 -0000 On Sep 12, 2004, at 9:59 AM, Igor Shmukler wrote: > Why do you think that 970 does not have BAT registers? > There are 16 special purpose registers specifically to implement Block > Address Translation. > Because Peter already told us that they have no BAT registers: http://lists.freebsd.org/pipermail/freebsd-ppc/2004-February/000359.html > I don't know what's a story with fan-drivers. Personally, I was under > impression that G5 has liquid cooling system. > Not that should be a major show stopper for FreeBSD support of G5 > boxes. Only one Apple [G5 2.5GHz PowerMac] is liquid cooled and it still has fans that are controlled by software on Mac OS X. Early versions of Linux had them on "full-blast" in order to avoid potential overheating. YellowDog Linux was the first one to support these fans with drivers if I remember correctly outside of Apple. > > AFAIK, PPC port of FreeBSD is incomplete, but moving ahead quite fast. > > I am not sure what kind of stack protection was referred in the > original email. OpenBSD has propolis, but I was under impression there > is no such option in FreeBSD. I recall that it was decided that > security by obscurity will not make it into the kernel. > > >> I don't think we have G5 support yet. G5's are significantly >> different >> from G4s in a few ways that really matter to operating systems. >> Missing BAT registers and other "fun stuff" like fan-drivers have >> meant >> that even platforms that support 64bit PPC don't necessarily support >> G5 >> [like the L4 microkernels I've been playing with] >> >> Dave >> On Sep 12, 2004, at 2:30 AM, jade@oxymail.org wrote: >> >>> Hello, >>> >>> I'm planning on buying an Apple Xserve G5 bi-processor. I know mac os >>> X (server) >>> is running on it and that's a modified version of freebsd. >>> So here are my questions : >>> >>> - I've been using freebsd for a while now and if I buy the Xserve I'd >>> very much >>> like to replace mac os X by a freebsd 5.2 / 5.3 if this is possible. >>> My >>> motivations are that I want to make intensive use of Jails and >>> Mandatory Access >>> Control (MAC). I'd also like to recompile the whole thing with stack >>> protection >>> (if possible). >>> >>> Yet I have no idea if Mac os X can run jails, and MAC (anyone an idea >>> here ?), >>> but if not, I'd switch to Freebie. >>> >>> So in general : >>> - has anyone experienced the change >>> - would it be difficult to replace OS X by FreeBSD ? >>> - would it be possible to run these options (Jails,MAC,stack >>> protection) on this >>> hardware ? >>> >>> Thanks for the hints, because I'm a little lost. >>> >>> By, >>> Jade. From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 12 20:01:32 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FA7316A4CE for ; Sun, 12 Sep 2004 20:01:32 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1991243D46 for ; Sun, 12 Sep 2004 20:01:32 +0000 (GMT) (envelope-from leimy2k@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i8CK1V2G020608; Sun, 12 Sep 2004 13:01:31 -0700 (PDT) Received: from [192.168.1.100] (c-67-165-114-246.client.comcast.net [67.165.114.246]) (authenticated bits=0)i8CK1Vrx029816; Sun, 12 Sep 2004 13:01:31 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88A2EE14-04F6-11D9-8975-000A95AFBEB4@mac.com> Content-Transfer-Encoding: 7bit From: David Leimbach Date: Sun, 12 Sep 2004 13:01:28 -0700 To: Igor Shmukler X-Mailer: Apple Mail (2.619) X-Mailman-Approved-At: Mon, 13 Sep 2004 15:13:54 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: Re[4]: FreeBSD on Xserve ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Sep 2004 20:01:32 -0000 On Sep 12, 2004, at 12:38 PM, Igor Shmukler wrote: >>> Why do you think that 970 does not have BAT registers? >>> There are 16 special purpose registers specifically to implement >>> Block >>> Address Translation. >>> >> >> Because Peter already told us that they have no BAT registers: >> >> http://lists.freebsd.org/pipermail/freebsd-ppc/2004-February/ >> 000359.html > > I don't know what Peter said, but I do have documentation in front of > me. > In 7.4 of Programming Environments Manual we have an overview of BAT > including BAT array organization. > > This comes as a shock to me. I am sending carbon copy to Peter Grehan, > perhaps he could tell us where he got his information. > > I am not trying to suggest that you and/or him are wrong, but I cannot > find (in manual) anything that would support your position that 970 > has no block address translation. Regarding 16MB superpages, I believe > manual explicitly says that 970 has no superpages, but I did not go > through the doc again. Therefore, I could be mistaken. > I understand :). I am not able to confirm this information with anything technical as I haven't looked very hard or had the time to check into these issues. > Regarding fans, it's not a big deal to support this kind of equipment. > IMO, SMP support and other low-level stuff is order[s] of magnitude > more complex. I agree. It's just the fans would likely be an issue for many users who have G5 desktops. An Xserve in a rack is probably allowed to be more noisy than other stuff. And I hope that you are correct about the BAT registers :). Dave > > Igor. From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 12 21:01:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5C5E16A4CE for ; Sun, 12 Sep 2004 21:01:24 +0000 (GMT) Received: from thebsh.namesys.com (thebsh.namesys.com [212.16.7.65]) by mx1.FreeBSD.org (Postfix) with SMTP id 252C443D3F for ; Sun, 12 Sep 2004 21:01:23 +0000 (GMT) (envelope-from nikita@clusterfs.com) Received: (qmail 2700 invoked by uid 511); 12 Sep 2004 21:01:21 -0000 From: Nikita Danilov MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16708.47393.249768.90818@thebsh.namesys.com> Date: Mon, 13 Sep 2004 01:01:21 +0400 To: Igor Shmukler In-Reply-To: References: <20040912183437.GF20097@mongers.org> X-Mailer: VM 7.17 under 21.5 (patch 17) "chayote" (+CVS-20040321) XEmacs Lucid X-Mailman-Approved-At: Mon, 13 Sep 2004 15:13:54 +0000 cc: freebsd-hackers@freebsd.org cc: Morten Liebach Subject: Re: FreeBSD on Xserve? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 12 Sep 2004 21:01:24 -0000 Igor Shmukler writes: > > > If original author wants to mature OS with MAC and SMP support SELinux > > > might be a good candidate. > > > However, Linux does not have jails. Only other OS that has them is > > > Solaris 10 which does not run on PPC. > > > > There's something named User Mode Linux which seems to be a little like > > jails. I haven't got the faintest idea how well it works. > > I could be wrong, but AFAIK UML is not same thing as jail. AFAIK, UML > has a serious performance penalty. It used to work pretty well for > 2.4.x kernels. However, there are associated issues with keeping UML > up to date. I don't think UML ever made it into mainline. Jail is > part of kernel. UML (User Mode Linux, user-mode-linux.sf.net) is a port of Linux kernel to Linux used as an underlying platform. UML kernel is built as a normal user-level executable, that is run on a "host" machine, providing "guest" Linux instance. You can log into guest, run processes there, attach debugger to it, etc. It's more like vmware than jail. UML is a part of 2.6 mainline. Nikita. From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 06:08:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04B2516A4CE for ; Mon, 13 Sep 2004 06:08:07 +0000 (GMT) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9682D43D3F for ; Mon, 13 Sep 2004 06:08:04 +0000 (GMT) (envelope-from peterg@ptree32.com.au) Received: from dommail.onthenet.com.au (localhost.onthenet.com.au [127.0.0.1]) by dommail.onthenet.com.au (Mirapoint Messaging Server MOS 3.2.4-GA) with ESMTP id AGL36193; Mon, 13 Sep 2004 16:07:45 +1000 (EST) From: Message-Id: <200409130607.AGL36193@dommail.onthenet.com.au> Received: from 202.72.131.230 by dommail.onthenet.com.au (Mirapoint Messaging Server MOS 3.2.4-GA) with HTTP/1.1; Mon, 13 Sep 2004 16:07:45 +1000 Date: Mon, 13 Sep 2004 16:07:45 +1000 To: Igor Shmukler X-Mailer: Webmail Mirapoint Direct 3.2.4-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Sep 2004 15:13:54 +0000 cc: freebsd-hackers@freebsd.org cc: David Leimbach Subject: Re: Re[4]: FreeBSD on Xserve ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2004 06:08:07 -0000 >I am not trying to suggest that you and/or him are wrong, >but I cannot find (in manual) anything that would support >your position that 970 has no block address translation. >Regarding 16MB superpages, I believe manual explicitly says >that 970 has no superpages, but I did not go through the doc >again. Therefore, I could be mistaken. I think there's an IBM technote that states there are no BATs on the 970. Linux source has comments to that effect as well. And before I found that info, I tried in vain to get it to work on my G5. later, Peter. From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 15:57:03 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAA7F16A4CE for ; Mon, 13 Sep 2004 15:57:03 +0000 (GMT) Received: from atlasta.net (mail.atlasta.net [209.246.234.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 8F21843D2D for ; Mon, 13 Sep 2004 15:57:03 +0000 (GMT) (envelope-from drais@atlasta.net) Received: (qmail 10446 invoked by uid 1012); 13 Sep 2004 15:57:02 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Sep 2004 15:57:02 -0000 Date: Mon, 13 Sep 2004 08:57:02 -0700 (PDT) From: David Raistrick To: soralx@cydem.org In-Reply-To: <200409130120.35057.soralx@cydem.org> Message-ID: References: <200409130120.35057.soralx@cydem.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: 586Core X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2004 15:57:03 -0000 On Mon, 13 Sep 2004 soralx@cydem.org wrote: > I've found this: 'http://www.compulab.co.il/586core.htm', and I'd appreciate > to get some opinions on this product. Is anyone using it? How well does it > work with FreeBSD (or *BSD)? How well FBSD works with its USB controller > (ScanLogic SL811HST)? > > Maybe someone can suggest a better and possibly less expensive alternative? Might take a look at: http://www.pcengines.ch/wrap.htm as well. Does require a kernel tweak for FreeBSD to run on it (keyboard controller related), but Pascal has all of this documented. ...david --- david raistrick http://www.netmeister.org/news/learn2quote.html drais@atlasta.net http://www.expita.com/nomime.html From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 17:13:40 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4E4116A4CE for ; Mon, 13 Sep 2004 17:13:40 +0000 (GMT) Received: from epita.fr (hermes.epita.fr [163.5.255.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B587A43D58 for ; Mon, 13 Sep 2004 17:13:39 +0000 (GMT) (envelope-from le-hen_j@epita.fr) Received: from garak (garak [10.42.25.5]) by epita.fr id i8DHDSC28453 Mon, 13 Sep 2004 19:13:29 +0200 (CEST) Date: Mon, 13 Sep 2004 19:13:29 +0200 From: Jeremie Le Hen To: Nikita Danilov Message-ID: <20040913171329.GA16110@garak.epita.fr> References: <20040912183437.GF20097@mongers.org> <16708.47393.249768.90818@thebsh.namesys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16708.47393.249768.90818@thebsh.namesys.com> User-Agent: Mutt/1.4i cc: freebsd-hackers@freebsd.org cc: Morten Liebach Subject: Re: FreeBSD on Xserve? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2004 17:13:40 -0000 > UML (User Mode Linux, user-mode-linux.sf.net) is a port of Linux kernel > to Linux used as an underlying platform. UML kernel is built as a normal > user-level executable, that is run on a "host" machine, providing > "guest" Linux instance. You can log into guest, run processes there, > attach debugger to it, etc. It's more like vmware than jail. I would add that the UML patch applied to the hosted kernel source deeply modifies the ptrace(2) infrastructure. All UML processes are in fact processes on the host kernel, but the UML kernel ptrace's so that it reroutes all invoked syscalls to itself and mmap's processes address space to its own one. There is obviously a major drawback here, since every process may corrupt the address space of other ones, and even the kernel one. This is the reason why the SKAS kernel patch was created : this patch modifies the host kernel so that the MMU can be used to protect addresss spaces, as if processes were on a real kernel ; of course the UML kernel is then also protected. I don't know the internal of this patch, my VM skills are not good enough. > UML is a part of 2.6 mainline. This is correct, but usually patches provided on UML website are newer than those included in the 2.6 source. Sorry for my english, I'm doing my best to improve it :-). -- Jeremie LE HEN aka TtZ jeremie.le-hen@epita.fr ttz@epita.fr Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 13 17:31:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED9D716A4CE for ; Mon, 13 Sep 2004 17:31:11 +0000 (GMT) Received: from mps9.plala.or.jp (c152002.vh.plala.or.jp [210.150.152.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEF6243D53 for ; Mon, 13 Sep 2004 17:31:10 +0000 (GMT) (envelope-from sf@FreeBSD.org) Received: from i60-35-144-114.s02.a026.ap.plala.or.jp ([60.35.144.114]) by mps9.plala.or.jp with ESMTP <20040913173109.YFHR12539.mps9.plala.or.jp@i60-35-144-114.s02.a026.ap.plala.or.jp>; Tue, 14 Sep 2004 02:31:09 +0900 Date: Tue, 14 Sep 2004 02:30:58 +0900 Message-ID: <86d60qrs8d.wl%sf@FreeBSD.org> From: FUJISHIMA Satsuki To: "M. Warner Losh" In-Reply-To: <20040913.000302.94315208.imp@bsdimp.com> References: <20040912.233946.30892794.imp@bsdimp.com> <20040913.000302.94315208.imp@bsdimp.com> Mail-Followup-To: "M. Warner Losh" , hackers@freebsd.org User-Agent: Wanderlust/2.11.30 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: Preliminary fdc patches X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 13 Sep 2004 17:31:12 -0000 My FDD shows up again with this patch, thank you. Previously it was proved twice and failed to attach. --- /var/tmp/dmesg.prev Mon Sep 13 06:23:51 2004 +++ /var/run/dmesg.boot Mon Sep 13 17:16:17 2004 @@ -1,7 +1,7 @@ Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. -FreeBSD 6.0-CURRENT #528: Tue Sep 7 17:50:26 JST 2004 +FreeBSD 6.0-CURRENT #531: Mon Sep 13 16:31:11 JST 2004 k5@souffle:/ad4/src/sys/i386/compile/SOUFFLE WARNING: MPSAFE network stack disabled, expect reduced performance. acpi_alloc_wakeup_handler: can't alloc wake memory @@ -66,13 +66,9 @@ psm0: [GIANT-LOCKED] psm0: model MouseMan+, device ID 0 fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 drq 2 on acpi0 -fdc0: does not respond -device_attach: fdc0 attach returned 6 +fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A -fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 drq 2 on acpi0 -fdc0: does not respond -device_attach: fdc0 attach returned 6 orm0: at iomem 0xc8000-0xc97ff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 00:02:49 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AA8D16A4CE; Tue, 14 Sep 2004 00:02:49 +0000 (GMT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 871B843D39; Tue, 14 Sep 2004 00:02:48 +0000 (GMT) (envelope-from des@des.no) Received: from dwp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id AD0441416; Tue, 14 Sep 2004 02:03:26 +0200 (MEST) Received: by dwp.des.no (Postfix, from userid 2602) id 55660B85E; Tue, 14 Sep 2004 02:02:47 +0200 (CEST) To: Maxime Henrion References: <200409091630.36721.db@traceroute.dk> <20040909143621.GD13294@elvis.mu.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 14 Sep 2004 02:02:47 +0200 In-Reply-To: <20040909143621.GD13294@elvis.mu.org> (Maxime Henrion's message of "Thu, 9 Sep 2004 16:36:21 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: hackers@freebsd.org Subject: Re: Runtime loading X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2004 00:02:49 -0000 Maxime Henrion writes: > db wrote: > > In my C++ program I need to load some files/classes at runtime, so > > that users can add "plugins" without recompilling my program. What > > functions should I use? I'm using FreeBSD 5.3-beta2 btw. > I'm not sure about C++, though I guess you could use the same functions as > in C. dlopen() etc. work just fine in C++. Beware of name mangling issues, though; you might not be able to load plugins compiled with a different compiler. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 03:26:45 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3049916A4CE for ; Tue, 14 Sep 2004 03:26:45 +0000 (GMT) Received: from freebsd3.cimlogic.com.au (adsl-20-121.swiftdsl.com.au [218.214.20.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 561DE43D2D for ; Tue, 14 Sep 2004 03:26:44 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id A830F6A9FE; Tue, 14 Sep 2004 13:26:42 +1000 (EST) Date: Tue, 14 Sep 2004 13:26:42 +1000 From: John Birrell To: soralx@cydem.org Message-ID: <20040914032642.GB69109@freebsd3.cimlogic.com.au> References: <200409130120.35057.soralx@cydem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409130120.35057.soralx@cydem.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org Subject: Re: 586Core X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2004 03:26:45 -0000 On Mon, Sep 13, 2004 at 01:20:35AM -0600, soralx@cydem.org wrote: > I'm starting some small project, and I need to decide what hardware > will fit its needs. I'm looking for a small single-board computer that > should have minimum: 2 serial ports (RS232 & [RS232 | USB(preferable)]), > 8-bit databus, FLASH disk, RTC, 486 CPU performance, low power consumption; > should be able to run FreeBSD. PCB size does not matter much. One > of the applications I plan to run on it is 'gnokii'. > > I've found this: 'http://www.compulab.co.il/586core.htm', and I'd appreciate > to get some opinions on this product. Is anyone using it? How well does it > work with FreeBSD (or *BSD)? How well FBSD works with its USB controller > (ScanLogic SL811HST)? FreeBSD runs fine on the 586Core (and 586Base). Compulab also responds to support emails. I haven't used any USB devices, but I plan to. The USB controller is detected, so I guess it will work. -- John Birrell From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 06:40:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56C1716A4CE for ; Tue, 14 Sep 2004 06:40:12 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDE7F43D4C for ; Tue, 14 Sep 2004 06:40:11 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8E6cwCN037702; Tue, 14 Sep 2004 00:38:59 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 14 Sep 2004 00:39:40 -0600 (MDT) Message-Id: <20040914.003940.97852010.imp@bsdimp.com> To: jb@cimlogic.com.au From: "M. Warner Losh" In-Reply-To: <20040914032642.GB69109@freebsd3.cimlogic.com.au> References: <200409130120.35057.soralx@cydem.org> <20040914032642.GB69109@freebsd3.cimlogic.com.au> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: 586Core X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2004 06:40:12 -0000 In message: <20040914032642.GB69109@freebsd3.cimlogic.com.au> John Birrell writes: : On Mon, Sep 13, 2004 at 01:20:35AM -0600, soralx@cydem.org wrote: : > I'm starting some small project, and I need to decide what hardware : > will fit its needs. I'm looking for a small single-board computer that : > should have minimum: 2 serial ports (RS232 & [RS232 | USB(preferable)]), : > 8-bit databus, FLASH disk, RTC, 486 CPU performance, low power consumption; : > should be able to run FreeBSD. PCB size does not matter much. One : > of the applications I plan to run on it is 'gnokii'. : > : > I've found this: 'http://www.compulab.co.il/586core.htm', and I'd appreciate : > to get some opinions on this product. Is anyone using it? How well does it : > work with FreeBSD (or *BSD)? How well FBSD works with its USB controller : > (ScanLogic SL811HST)? : : FreeBSD runs fine on the 586Core (and 586Base). Compulab also responds to : support emails. We're using the 586Core board on a system here that needs to run in a very small space (smaller than the soekris boards fit into even). We've had excellent response from Compulab on our questions as well. Their serial BIOS is a pain to use, but for most applications it doesn't matter at all... Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 06:44:43 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2825A16A4CF for ; Tue, 14 Sep 2004 06:44:43 +0000 (GMT) Received: from freebsd3.cimlogic.com.au (adsl-20-121.swiftdsl.com.au [218.214.20.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5961543D46 for ; Tue, 14 Sep 2004 06:44:42 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id 7ACFC6A9FE; Tue, 14 Sep 2004 16:44:40 +1000 (EST) Date: Tue, 14 Sep 2004 16:44:40 +1000 From: John Birrell To: "M. Warner Losh" Message-ID: <20040914064440.GC69109@freebsd3.cimlogic.com.au> References: <200409130120.35057.soralx@cydem.org> <20040914032642.GB69109@freebsd3.cimlogic.com.au> <20040914.003940.97852010.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040914.003940.97852010.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org Subject: Re: 586Core X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2004 06:44:43 -0000 On Tue, Sep 14, 2004 at 12:39:40AM -0600, M. Warner Losh wrote: > Their serial BIOS is a pain to use, but for most applications it > doesn't matter at all... What problems do you have with it? It seems to work fine for me once I build FreeBSD to it's fixed baud rate. -- John Birrell From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 07:22:21 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D66C16A4CE for ; Tue, 14 Sep 2004 07:22:21 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 392F643D4C for ; Tue, 14 Sep 2004 07:22:21 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8E7KErt038275; Tue, 14 Sep 2004 01:20:14 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 14 Sep 2004 01:20:56 -0600 (MDT) Message-Id: <20040914.012056.106261879.imp@bsdimp.com> To: jb@cimlogic.com.au From: "M. Warner Losh" In-Reply-To: <20040914064440.GC69109@freebsd3.cimlogic.com.au> References: <20040914032642.GB69109@freebsd3.cimlogic.com.au> <20040914.003940.97852010.imp@bsdimp.com> <20040914064440.GC69109@freebsd3.cimlogic.com.au> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: 586Core X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2004 07:22:21 -0000 In message: <20040914064440.GC69109@freebsd3.cimlogic.com.au> John Birrell writes: : On Tue, Sep 14, 2004 at 12:39:40AM -0600, M. Warner Losh wrote: : > Their serial BIOS is a pain to use, but for most applications it : > doesn't matter at all... : : What problems do you have with it? It seems to work fine for me once : I build FreeBSD to it's fixed baud rate. tabbing between items is a bit painful. We've also had issue where it wouldn't boot off the second device if the first one were missing. Nothing major or earth shattering, but it took some getting used to. Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 07:25:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B861F16A4CE for ; Tue, 14 Sep 2004 07:25:37 +0000 (GMT) Received: from freebsd3.cimlogic.com.au (adsl-20-121.swiftdsl.com.au [218.214.20.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 619FB43D48 for ; Tue, 14 Sep 2004 07:25:37 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id 5BDC16A9FE; Tue, 14 Sep 2004 17:25:36 +1000 (EST) Date: Tue, 14 Sep 2004 17:25:36 +1000 From: John Birrell To: "M. Warner Losh" Message-ID: <20040914072536.GD69109@freebsd3.cimlogic.com.au> References: <20040914032642.GB69109@freebsd3.cimlogic.com.au> <20040914.003940.97852010.imp@bsdimp.com> <20040914064440.GC69109@freebsd3.cimlogic.com.au> <20040914.012056.106261879.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040914.012056.106261879.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org Subject: Re: 586Core X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2004 07:25:37 -0000 On Tue, Sep 14, 2004 at 01:20:56AM -0600, M. Warner Losh wrote: > In message: <20040914064440.GC69109@freebsd3.cimlogic.com.au> > John Birrell writes: > : On Tue, Sep 14, 2004 at 12:39:40AM -0600, M. Warner Losh wrote: > : > Their serial BIOS is a pain to use, but for most applications it > : > doesn't matter at all... > : > : What problems do you have with it? It seems to work fine for me once > : I build FreeBSD to it's fixed baud rate. > > tabbing between items is a bit painful. We've also had issue where it > wouldn't boot off the second device if the first one were missing. > Nothing major or earth shattering, but it took some getting used to. *Phew* 8-) -- John Birrell From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 03:15:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD70416A4CE for ; Tue, 14 Sep 2004 03:15:41 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71A1143D53 for ; Tue, 14 Sep 2004 03:15:41 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) i8E3FfdZ087425 for ; Mon, 13 Sep 2004 20:15:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)i8E3FfMX087424 for freebsd-hackers@freebsd.org; Mon, 13 Sep 2004 20:15:41 -0700 (PDT) (envelope-from sgk) Date: Mon, 13 Sep 2004 20:15:41 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Message-ID: <20040914031541.GA87387@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Tue, 14 Sep 2004 12:17:30 +0000 Subject: more than 8GB of memory? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2004 03:15:41 -0000 Is anyone using a FreeBSD system with more than 8 GB of physical memory? Can you email me your kernel config file and sysctl -a output? -- Steve From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 05:56:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E32B16A4CE for ; Tue, 14 Sep 2004 05:56:36 +0000 (GMT) Received: from ns.mmk.ru (ns1.mmk.ru [193.16.208.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9863343D1F for ; Tue, 14 Sep 2004 05:56:34 +0000 (GMT) (envelope-from dmitry@mmk.ru) Received: from antivirus.mmk.ru (antivirus [161.8.100.3]) by ns.mmk.ru (8.12.9p1/8.12.9) with ESMTP id i8E5v1K4037324 for ; Tue, 14 Sep 2004 11:57:02 +0600 (YEKST) (envelope-from dmitry@mmk.ru) Received: from dimasic (localhost [127.0.0.1]) by antivirus.mmk.ru (8.12.9/8.12.9) with SMTP id i8E5pVY9027145 for ; Tue, 14 Sep 2004 11:51:31 +0600 (YEKST) Message-ID: <018e01c49a1f$6a4c1050$02010101@dimasic> From: "Dmitry A. Bondareff" To: Date: Tue, 14 Sep 2004 11:55:18 +0600 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailman-Approved-At: Tue, 14 Sep 2004 12:17:30 +0000 Subject: What does it mean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2004 05:56:36 -0000 Hello hackers! On my system which connected to Internet I''ll see many processes like (sh): # ps axu | more USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 59548 1,0 0,0 0 0 ?? Z 11:00 0:00,00 (sh) root 59588 0,0 0,0 0 0 ?? Z 11:02 0:00,00 (sh) root 185 0,0 0,0 0 0 ?? Z 2ÉÀÌ04 0:00,00 (sh) WHAT IS IT ?? Regards, Dmitry. From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 12:30:29 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 908B216A4D3 for ; Tue, 14 Sep 2004 12:30:29 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 27FFE43D31 for ; Tue, 14 Sep 2004 12:30:23 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 9646 invoked from network); 14 Sep 2004 12:27:55 -0000 Received: from unknown (HELO straylight.m.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 14 Sep 2004 12:27:55 -0000 Received: (qmail 1999 invoked by uid 1000); 14 Sep 2004 12:30:53 -0000 Date: Tue, 14 Sep 2004 15:30:53 +0300 From: Peter Pentchev To: "Dmitry A. Bondareff" Message-ID: <20040914123052.GA965@straylight.m.ringlet.net> Mail-Followup-To: "Dmitry A. Bondareff" , freebsd-hackers@freebsd.org References: <018e01c49a1f$6a4c1050$02010101@dimasic> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <018e01c49a1f$6a4c1050$02010101@dimasic> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: What does it mean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2004 12:30:29 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 14, 2004 at 11:55:18AM +0600, Dmitry A. Bondareff wrote: > Hello hackers! >=20 > On my system which connected to Internet I''ll see many processes like (s= h): > # ps axu | more > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 59548 1,0 0,0 0 0 ?? Z 11:00 0:00,00 (sh) > root 59588 0,0 0,0 0 0 ?? Z 11:02 0:00,00 (sh) > root 185 0,0 0,0 0 0 ?? Z 2=E8=FE=EB04 0:00,00 (sh) >=20 > WHAT IS IT ?? According to the ps(1) manual page, the 'Z' flag means that the process is what is commonly known as 'zombie' - a process that has ended its execution, either exiting voluntarily or killed by a signal, and is being kept in memory until its parent process collects whatever information is necessary. The fact that you are seeing those zombie processes may mean one of two things: either the 'sh' processes have ended really, really recently and their parent has not yet had a chance to invoke one of the functions described in the wait(2) manual page to collect the information, or the 'sh' processes have terminated some time ago but their parent is busy doing something else, possibly locked up or something. You may gather a lot more information by including the parent process ID in the 'ps' output: try 'ps axl' or 'ps axlwww', see what has invoked all those 'sh' processes, see if it has left any logs as to why, what happened, and so on. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I've heard that this sentence is a rumor. --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBRuR87Ri2jRYZRVMRAo0SAJ9UIJx6MfiXrrqQQ8G2MsS7LyQZGwCcDDBD t2POPZKyq9xLwW8+6daMqFE= =Waqy -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 14:56:59 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B43C16A4CE for ; Tue, 14 Sep 2004 14:56:59 +0000 (GMT) Received: from smtp.cegetel.net (mf00.sitadelle.com [212.94.174.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5037243D2F for ; Tue, 14 Sep 2004 14:56:58 +0000 (GMT) (envelope-from tataz@sitadelle.com) Received: from droopy.tech.sitadelle.com (unknown [213.223.184.201]) by smtp.cegetel.net (Postfix) with ESMTP id 394496726C for ; Mon, 13 Sep 2004 19:18:19 +0200 (CEST) Received: by droopy.tech.sitadelle.com (Postfix, from userid 1000) id A096AFC01C; Mon, 13 Sep 2004 19:18:36 +0200 (CEST) Resent-From: jeremie.le-hen@sitadelle.com Resent-Date: Mon, 13 Sep 2004 19:18:36 +0200 Resent-Message-ID: <20040913171836.GK12877@sitadelle.com> Resent-To: freebsd-hackers@freebsd.org X-Original-To: tataz@localhost Received: from localhost (localhost [127.0.0.1]) by droopy.tech.sitadelle.com (Postfix) with ESMTP id A34B8FC01C for ; Mon, 13 Sep 2004 19:14:14 +0200 (CEST) X-Original-To: tataz@sitadelle.com Received: from mail.sitadelle.com [212.94.174.23] by localhost with IMAP (fetchmail-6.2.5) for tataz@localhost (single-drop); Mon, 13 Sep 2004 19:14:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx.sitadelle.com (Postfix) with ESMTP id 3EF219C0E2 for ; Mon, 13 Sep 2004 19:13:54 +0200 (CEST) Received: from mx.sitadelle.com ([127.0.0.1]) by localhost (mx01 [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 01845-01-37 for ; Mon, 13 Sep 2004 19:13:52 +0200 (CEST) Received: from mx.sitadelle.com (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 829AC9C033 for ; Mon, 13 Sep 2004 19:13:52 +0200 (CEST) Received: from epita.fr (hermes.epita.fr [163.5.255.10]) by mx.sitadelle.com (Postfix) with ESMTP id 658B79C050 for ; Mon, 13 Sep 2004 19:13:50 +0200 (CEST) Received: from garak (garak [10.42.25.5]) by epita.fr id i8DHDkC18493 for tataz@sitadelle.com EPITA Paris France Mon, 13 Sep 2004 19:13:46 +0200 (CEST) Resent-From: jeremie le-hen Resent-Message-Id: <200409131713.i8DHDkC18493@epita.fr> Date: Mon, 13 Sep 2004 19:13:29 +0200 From: Jeremie Le Hen To: Nikita Danilov Message-ID: <20040913171329.GA16110@garak.epita.fr> References: <20040912183437.GF20097@mongers.org> <16708.47393.249768.90818@thebsh.namesys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16708.47393.249768.90818@thebsh.namesys.com> User-Agent: Mutt/1.4i Resent-Date: Mon, 13 Sep 2004 19:13:46 +0200 Resent-To: tataz@sitadelle.com X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at mx01.sitadelle.com X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: cc: freebsd-hackers@freebsd.org cc: Morten Liebach Subject: Re: FreeBSD on Xserve? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2004 14:56:59 -0000 > UML (User Mode Linux, user-mode-linux.sf.net) is a port of Linux kernel > to Linux used as an underlying platform. UML kernel is built as a normal > user-level executable, that is run on a "host" machine, providing > "guest" Linux instance. You can log into guest, run processes there, > attach debugger to it, etc. It's more like vmware than jail. I would add that the UML patch applied to the hosted kernel source deeply modifies the ptrace(2) infrastructure. All UML processes are in fact processes on the host kernel, but the UML kernel ptrace's so that it reroutes all invoked syscalls to itself and mmap's processes address space to its own one. There is obviously a major drawback here, since every process may corrupt the address space of other ones, and even the kernel one. This is the reason why the SKAS kernel patch was created : this patch modifies the host kernel so that the MMU can be used to protect addresss spaces, as if processes were on a real kernel ; of course the UML kernel is then also protected. I don't know the internal of this patch, my VM skills are not good enough. > UML is a part of 2.6 mainline. This is correct, but usually patches provided on UML website are newer than those included in the 2.6 source. Sorry for my english, I'm doing my best to improve it :-). -- Jeremie LE HEN aka TtZ jeremie.le-hen@epita.fr ttz@epita.fr Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 16:37:03 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10AC016A4CE for ; Tue, 14 Sep 2004 16:37:02 +0000 (GMT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9005843D48 for ; Tue, 14 Sep 2004 16:37:01 +0000 (GMT) SRS0+16b390477d8a77a0b55b+387+infradead.org+hch@phoenix.srs.infradead.org) Received: from hch by phoenix.infradead.org with local (Exim 4.42 #2 (Red Hat Linux)) id 1C7GIa-0002Ub-25; Tue, 14 Sep 2004 17:36:56 +0100 Date: Tue, 14 Sep 2004 17:36:55 +0100 From: Christoph Hellwig To: Jeremie Le Hen Message-ID: <20040914173655.A9479@infradead.org> References: <20040912183437.GF20097@mongers.org> <16708.47393.249768.90818@thebsh.namesys.com> <20040913171329.GA16110@garak.epita.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040913171329.GA16110@garak.epita.fr>; from jeremie.le-hen@epita.fr on Mon, Sep 13, 2004 at 07:13:29PM +0200 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html cc: freebsd-hackers@freebsd.org cc: Morten Liebach cc: Nikita Danilov Subject: Re: FreeBSD on Xserve? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2004 16:37:03 -0000 On Mon, Sep 13, 2004 at 07:13:29PM +0200, Jeremie Le Hen wrote: > I would add that the UML patch applied to the hosted kernel source deeply > modifies the ptrace(2) infrastructure. All UML processes are in fact > processes on the host kernel, but the UML kernel ptrace's so that it reroutes > all invoked syscalls to itself and mmap's processes address space to its > own one. That's not ture. For the ptrace method you describe unmodified host kernels work. There's an alternate implementation using multiple address spaces per process that needs a heavily patched kernel. (the SKAS patch you mention below) From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 20:23:22 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CD9416A4D0 for ; Tue, 14 Sep 2004 20:23:22 +0000 (GMT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A01E643D1F for ; Tue, 14 Sep 2004 20:23:21 +0000 (GMT) (envelope-from deker@slackdot.org) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.12.8/8.12.8) with ESMTP id i8EKNJXZ001439 for ; Tue, 14 Sep 2004 15:23:20 -0500 Received: from columbia.sparta.com (lilo.columbia.SPARTA.COM [157.185.80.32]) by Beta5.sparta.com (8.12.11/8.12.11) with ESMTP id i8EKNJ2E013582 for ; Tue, 14 Sep 2004 15:23:19 -0500 Received: from [157.185.80.108] (7lyxg41.columbia.sparta.com [157.185.80.108]) i8EKNIfq016900 for ; Tue, 14 Sep 2004 16:23:18 -0400 (EDT) Message-ID: <41475335.5020507@slackdot.org> Date: Tue, 14 Sep 2004 16:23:17 -0400 From: Rob Deker User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Parameters passed to ath_hal_setuptxdesc() from ath(4) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 20:23:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey folks, ~ I've recently been working on some patches to the ath(4) driver to allow for raw frame injection, and I've got a question. Our patches will be allowing for full-frame raw injection, and so we can't necessarily know the length of the header on any given packet (ie. If the injected frame includes the addr4 field, is WEPped, etc). As I understand the IEEE spec, the LLC headers must be transmitted at the lowest supported rate (usually 1Mbps). My questions are: ~ - Is this a function of the HAL? ~ - If so, does the header length parameter to ath_hal_setuptxdesc() tell the HAL how many bytes it needs to send at a slower rate? ~ - If the answers to the first two questions were "yes", and I wanted to provide a mechanism for the application programmer to specify his/her header length, what (if any) are the limits imposed on this parameter by the HAL? Any insight is appreciated,, - -d -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBR1M1iaU9aKbHcJcRAhHGAJ0VfhoBvyL9WWSkZHeG9/nmH3mkmgCeJrIZ XbWQoJX6jb508K5bOh7HBPE= =7ASk -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 22:29:20 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4692716A4CE for ; Tue, 14 Sep 2004 22:29:20 +0000 (GMT) Received: from vsmtp14.tin.it (vsmtp14.tin.it [212.216.176.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id C027243D48 for ; Tue, 14 Sep 2004 22:29:19 +0000 (GMT) (envelope-from flag@tin.it) Received: from southcross.homeunix.org (82.49.164.44) by vsmtp14.tin.it (7.0.027) id 411B8D0E004CE1E4; Wed, 15 Sep 2004 00:29:19 +0200 Received: by southcross.homeunix.org (Postfix, from userid 1001) id 2E35D20CD; Wed, 15 Sep 2004 00:39:31 +0200 (CEST) Date: Wed, 15 Sep 2004 00:39:30 +0200 From: Paolo Pisati To: FreeBSD_Hackers Message-ID: <20040914223930.GA1945@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: mk@neon1.net Subject: Installing minibsd inside vmware virtual disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 14 Sep 2004 22:29:20 -0000 Hi guys, [the long story] i've a problem while i try to install minibsd inside a virtual disk of vmware3 running on top of FreeBSD. I obtained minibsd scripts form the freesbie cvs, unpacked in a dir on my disk, executed all the scripts and generated a iso containing a complete minibsd system. /* * personal note: minibsd is SO sweetttt!!!! * ONLY 15mbs for a working system!!! =) */ Booted vmware with freesbie, mouned the minibsd iso and a 32mb virtual disk previously prepared(see below for some more info), copied all the stuff from the minibsd iso and updated /etc/fstab. Installed the boot code and halted the system. Unmounted all the iso (freesbie & minibsd iso), and booted vmware with only virtual disk. It started correctly, executed the boot code, loaded the kernel, decompressed it but when it came to mount / (the previously created fs) it paniced: panic: going nowhere without my init (detaild screenshot here: http://www.gufi.org/~flag/vmware-minibsd-init-signal6.gif) Now, i know i'm missing something very stupid, but i don't know what... /* WARNING: brain fart starts here */ The panic msg seems to be clear: the kernel can't find the init executable so it panics, but: 1) the fs seemed to be ok cause it was mounted with no prob (if it couldn't find the fs i expected a panic during the mount phase "Mounting root from ufs:..." 2) the init file is present in the created fs (/sbin/init) So here comes the question: why the hell (if the fs is good and it was mounted correctly) the kernel cannot find it? /* End of brain fart */ Uhmmm... probably i should read again the boot section in the handbook or think a bit more but i'm sure there's something REALLY stupid i'm missing... Or maybe is just minibsd that doesn't use init but a custom program and i botched it... But if you have any ideas or suggestions i would be REALLY pleased to here it from you... =) Thanks. structure of the created fs: root@FreeSBIE:~# fdisk /dev/ad0 ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=65 heads=16 sectors/track=63 (1008 blks/cyl) parameters to be used for BIOS calculations are: cylinders=65 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 64449 (31 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 63/ head 15/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: root@FreeSBIE:~#)))))) bsdlabel ad0s1 # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 64433 16 4.2BSD 2048 16384 4032 c: 64449 0 unused 0 0 # "raw" part, don't edit root@FreeSBIE:~# mkdir /tmp/minibsd root@FreeSBIE:~# mount /dev/ad0s1a /tmp/minibsd root@FreeSBIE:~# ls -la /tmp/minibsd/sbin/init -r-x------ 1 root wheel 18272 Sep 14 13:07 /tmp/minibsd/sbin/init root@FreeSBIE:~# /tmp/minibsd/sbin/init init: already running root@FreeSBIE:~# root@FreeSBIE:~# ls -la /tmp/minibsd/ total 34 drwxr-xr-x 17 root wheel 512 Sep 14 13:07 . drwxrwxrwx 5 root wheel 512 Sep 14 14:04 .. drwxrwxr-x 2 root operator 512 Sep 14 13:06 .snap drwxr-xr-x 2 root wheel 512 Sep 14 13:07 bin drwxr-xr-x 5 root wheel 512 Sep 14 13:06 boot dr-xr-xr-x 2 root wheel 512 Sep 14 13:06 dev drwxr-xr-x 18 root wheel 1536 Sep 14 13:07 etc drwxr-xr-x 3 root wheel 512 Sep 14 13:06 lib drwxr-xr-x 2 root wheel 512 Sep 14 13:06 libexec drwxr-xr-x 2 root wheel 512 Sep 14 13:06 mnt dr-xr-xr-x 2 root wheel 512 Sep 14 13:07 proc drwxr-xr-x 2 root wheel 512 Sep 14 13:07 rescue drwxr-xr-x 2 root wheel 512 Sep 14 13:07 root drwxr-xr-x 2 root wheel 1024 Sep 14 13:07 sbin lrwxr-xr-x 1 root wheel 11 Sep 14 13:07 sys -> usr/src/sys drwxr-xr-t 2 root wheel 512 Sep 14 13:07 tmp drwxr-xr-x 13 root wheel 512 Sep 14 13:07 usr drwxr-xr-x 20 root wheel 512 Sep 14 13:07 var root@FreeSBIE:~# cat /tmp/minibsd/etc/fstab # See the fstab(5) manual page for important information on automatic mounts # of network filesystems before modifying this file. # # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1a / ufs rw,noatime 1 1 root@FreeSBIE:~# kernel config file: machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident MINIBSD maxusers 0 options SCHED_4BSD options INET #InterNETworking options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options NFSCLIENT #Network Filesystem Client options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options ROOTDEVNAME=\"ufs:ad0s1\" device isa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives options ATA_STATIC_ID #Static device numbering # syscons is the default console driver, resembling an SCO console device atkbdc device atkbd device vga device sc options SC_NO_SYSMOUSE # Floating point support - do not disable. device npx device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device miibus # MII bus support device lnc # NIC emulated in vmware # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop # Network loopback device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" options NETGRAPH -- Paolo Italian FreeBSD User Group: http://www.gufi.org From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 00:24:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C58AC16A4CE for ; Wed, 15 Sep 2004 00:24:07 +0000 (GMT) Received: from newmail.slackdot.org (mail2.slackdot.org [66.92.146.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4762243D1F for ; Wed, 15 Sep 2004 00:24:07 +0000 (GMT) (envelope-from deker@slackdot.org) Received: from localhost (localhost [127.0.0.1]) by newmail.slackdot.org (Postfix) with ESMTP id 2D44914AF6; Tue, 14 Sep 2004 20:22:08 -0400 (EDT) Received: from newmail.slackdot.org ([127.0.0.1]) by localhost (newmail.slackdot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11525-09; Tue, 14 Sep 2004 20:22:05 -0400 (EDT) Received: from [192.168.0.157] (unknown [192.168.0.157]) by newmail.slackdot.org (Postfix) with ESMTP id 4A97C141BF; Tue, 14 Sep 2004 20:22:05 -0400 (EDT) From: Rob Deker To: Sam Leffler In-Reply-To: <200409141621.52897.sam@errno.com> References: <41475335.5020507@slackdot.org> <200409141621.52897.sam@errno.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bmz/ZYRuL99KHqH1s1bo" Message-Id: <1095207831.16006.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 14 Sep 2004 20:23:51 -0400 X-Virus-Scanned: by amavisd-new at slackdot.org cc: freebsd-hackers@freebsd.org Subject: Re: Parameters passed to ath_hal_setuptxdesc() from ath(4) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2004 00:24:07 -0000 --=-bmz/ZYRuL99KHqH1s1bo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-09-14 at 19:21, Sam Leffler wrote: > > ~ - Is this a function of the HAL? >=20 > hardware (but only 5210 parts need it). >=20 > > ~ - If so, does the header length parameter to ath_hal_setuptxdesc() > > tell the HAL how many bytes it needs to send at a slower rate? > > ~ - If the answers to the first two questions were "yes", and I wanted > > to provide a mechanism for the application programmer to specify > > his/her header length, what (if any) are the limits imposed on this > > parameter by the HAL? >=20 > hdrLen <=3D pktLen probably; though I'm not sure a 5210 would care what y= ou=20 > supplied. >=20 So if it were to have an "incorrect" value would listening STAs still properly recieve the packet? Also, on a related note, is the txpower parameter actually honored? I noted that it's hardcoded to '60' and wondered. thanks, -d --=-bmz/ZYRuL99KHqH1s1bo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBR4uXiIu2X5vnl3ERAvteAKDJmLpTWmUsyVbvP/P1wo/sVTgzBACg8YxF uULF0WRedEujbAkMUAuSRS4= =GiaF -----END PGP SIGNATURE----- --=-bmz/ZYRuL99KHqH1s1bo-- From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 14 23:17:38 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D259E16A4CE for ; Tue, 14 Sep 2004 23:17:38 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97D3043D45 for ; Tue, 14 Sep 2004 23:17:38 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i8ENHbWi036473 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 14 Sep 2004 16:17:38 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: freebsd-hackers@freebsd.org Date: Tue, 14 Sep 2004 16:21:52 -0700 User-Agent: KMail/1.7 References: <41475335.5020507@slackdot.org> In-Reply-To: <41475335.5020507@slackdot.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409141621.52897.sam@errno.com> X-Mailman-Approved-At: Wed, 15 Sep 2004 12:34:11 +0000 cc: Rob Deker Subject: Re: Parameters passed to ath_hal_setuptxdesc() from ath(4) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2004 23:17:38 -0000 On Tuesday 14 September 2004 01:23 pm, Rob Deker wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey folks, > > ~ I've recently been working on some patches to the ath(4) driver to > allow for raw frame injection, and I've got a question. Our patches > will be allowing for full-frame raw injection, and so we can't > necessarily know the length of the header on any given packet (ie. If > the injected frame includes the addr4 field, is WEPped, etc). As I > understand the IEEE spec, the LLC headers must be transmitted at the > lowest supported rate (usually 1Mbps). My questions are: > > ~ - Is this a function of the HAL? hardware (but only 5210 parts need it). > ~ - If so, does the header length parameter to ath_hal_setuptxdesc() > tell the HAL how many bytes it needs to send at a slower rate? > ~ - If the answers to the first two questions were "yes", and I wanted > to provide a mechanism for the application programmer to specify > his/her header length, what (if any) are the limits imposed on this > parameter by the HAL? hdrLen <= pktLen probably; though I'm not sure a 5210 would care what you supplied. Sam From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 04:24:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3684216A4CE for ; Wed, 15 Sep 2004 04:24:35 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id D271843D5E for ; Wed, 15 Sep 2004 04:24:34 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i8F4OYWi037933 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 14 Sep 2004 21:24:34 -0700 (PDT) (envelope-from sam@errno.com) In-Reply-To: <1095207831.16006.10.camel@localhost> References: <41475335.5020507@slackdot.org> <200409141621.52897.sam@errno.com> <1095207831.16006.10.camel@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <26CB460B-06CF-11D9-A154-000A95AD0668@errno.com> Content-Transfer-Encoding: 7bit From: Sam Leffler Date: Tue, 14 Sep 2004 21:24:36 -0700 To: Rob Deker X-Mailer: Apple Mail (2.619) X-Mailman-Approved-At: Wed, 15 Sep 2004 12:34:11 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: Parameters passed to ath_hal_setuptxdesc() from ath(4) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2004 04:24:35 -0000 On Sep 14, 2004, at 5:23 PM, Rob Deker wrote: > On Tue, 2004-09-14 at 19:21, Sam Leffler wrote: > >>> ~ - Is this a function of the HAL? >> >> hardware (but only 5210 parts need it). >> >>> ~ - If so, does the header length parameter to ath_hal_setuptxdesc() >>> tell the HAL how many bytes it needs to send at a slower rate? >>> ~ - If the answers to the first two questions were "yes", and I >>> wanted >>> to provide a mechanism for the application programmer to specify >>> his/her header length, what (if any) are the limits imposed on this >>> parameter by the HAL? >> >> hdrLen <= pktLen probably; though I'm not sure a 5210 would care what >> you >> supplied. >> > So if it were to have an "incorrect" value would listening STAs still > properly recieve the packet? I have no idea, try it. > Also, on a related note, is the txpower parameter actually honored? I > noted that it's hardcoded to '60' and wondered. per-packet TPC is not working right now. Sam From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 12:59:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4761C16A4CE for ; Wed, 15 Sep 2004 12:59:12 +0000 (GMT) Received: from jagor.srce.hr (jagor.srce.hr [161.53.2.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 681BF43D5F for ; Wed, 15 Sep 2004 12:59:11 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [193.198.133.243] (cmung1513.cmu.carnet.hr [193.198.133.243]) by jagor.srce.hr (8.12.10/8.12.10) with ESMTP id i8FCx7CO011253 for ; Wed, 15 Sep 2004 14:59:08 +0200 (CEST) Message-ID: <41483C97.2030303@fer.hr> Date: Wed, 15 Sep 2004 14:59:03 +0200 From: Ivan Voras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040502 Thunderbird/0.6 Mnenhy/0.6.0.104 X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Face: L+\SC&qzD^$mE"W7='[pvNVqN~%w%yE$u=Z8>3^$16dK+jG[@H`; lFz^h,f=uzlw01 fajy]=lHAh(S@'EmM3FbC-`HqOh!,fJFeBS$2JU3w-3WQr{$ADS`,'xm8>G0/7I{p61vqy+RMCwQDg xh'z9&s0V:n Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.42 X-Virus-Scanned: by amavisd-new at jagor.srce.hr Subject: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Sep 2004 12:59:12 -0000 It looks like Sun is going to obsolete their UFS: http://www.sun.com/2004-0914/feature/?biga=15 Any comments? Anybody tried it yet? It seems like they have built on and extented concepts presented by geom and softupdates. Sun's been using a lot of ideas present in FreeBSD: jails, linux "emulation", and now this, and extended them nicely into their "enterprise-grade" idea. It would be interesting to try it in action :) -- What part of "Ph'nglui mglw'nath Cthulhu R'lyeh wgah'nagl fhtagn" don't you understand? From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 13:54:23 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4D0416A4CF for ; Wed, 15 Sep 2004 13:54:23 +0000 (GMT) Received: from mail.mynet.cz (74.mynet.cz [217.11.249.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 264C843D5A for ; Wed, 15 Sep 2004 13:54:22 +0000 (GMT) (envelope-from jp@devnull.cz) Received: from axxem.hide.subzone.cz (subzone.osad.prg.mynet.cz [82.119.254.162]) by mail.mynet.cz (8.12.9p2/8.12.9) with ESMTP id i8FDsJ1h034005 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 15 Sep 2004 15:54:20 +0200 (CEST) (envelope-from jp@devnull.cz) Date: Wed, 15 Sep 2004 15:51:44 +0200 (CEST) From: Jan Pechanec X-X-Sender: jp@axxem.hide.subzone.cz To: Paolo Pisati In-Reply-To: <20040914223930.GA1945@tin.it> Message-ID: <20040915154336.Q90028@axxem.hide.subzone.cz> References: <20040914223930.GA1945@tin.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD_Hackers cc: mk@neon1.net Subject: Re: Installing minibsd inside vmware virtual disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Sep 2004 13:54:23 -0000 On Wed, 15 Sep 2004, Paolo Pisati wrote: >panic: going nowhere without my init >(detaild screenshot here: http://www.gufi.org/~flag/vmware-minibsd-init-signal6.gif) > >Now, i know i'm missing something very stupid, but i don't know what... hi Paolo, minibsd offers you to use NOSHARED=no. If you set this option, check init: ldd YOUR_DISTRIBUTION/sbin/init I would think you don't include those libraries into your distro. Let me know if your problem was somewhere else please. j. -- Jan Pechanec From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 14:06:40 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80D7C16A4CE for ; Wed, 15 Sep 2004 14:06:40 +0000 (GMT) Received: from vsmtp2.tin.it (vsmtp2alice.tin.it [212.216.176.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02A5843D48 for ; Wed, 15 Sep 2004 14:06:40 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp2.tin.it (7.0.027) id 4141A7270013820C for freebsd-hackers@freebsd.org; Wed, 15 Sep 2004 16:06:40 +0200 Received: from [192.168.70.225] by ims3a.cp.tin.it with HTTP; Wed, 15 Sep 2004 16:06:39 +0200 Date: Wed, 15 Sep 2004 16:06:39 +0200 Message-ID: <4146316C0000429E@ims3a.cp.tin.it> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: struct sysentvec field X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Sep 2004 14:06:40 -0000 Hi, I've seen void (*sv_prepsyscall)(struct trapframe *, int *, u_int *, cad= dr_t *); field in struct sysentvec defined in sys/sysent.h; I've seen it's ca= ll be the current process in syscall interrupt 0x80 handling and it seems to= set number of arguments and base pointer for syscall arguments. It's not a comment in the code, somebody could tell me what is the task of this fi= eld? thanks rookie From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 14:59:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A2C216A4CF for ; Wed, 15 Sep 2004 14:59:55 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CEAE43D5F for ; Wed, 15 Sep 2004 14:59:55 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8FFxask021402 for ; Wed, 15 Sep 2004 10:59:37 -0500 Date: Wed, 15 Sep 2004 10:59:36 -0500 (EST) From: Sam X-X-Sender: sah@athena To: hackers@freebsd.org In-Reply-To: <41483C97.2030303@fer.hr> Message-ID: References: <41483C97.2030303@fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Sep 2004 14:59:55 -0000 On Wed, 15 Sep 2004, Ivan Voras wrote: > It looks like Sun is going to obsolete their UFS: > http://www.sun.com/2004-0914/feature/?biga=15 > > Any comments? Anybody tried it yet? > It seems like they have built on and extented concepts presented by geom and > softupdates. > > Sun's been using a lot of ideas present in FreeBSD: jails, linux "emulation", > and now this, and extended them nicely into their "enterprise-grade" idea. It > would be interesting to try it in action :) > "Sun engineers wondered if the 64-bit capabilities of current file systems will continue to suffice over the next 10 to 20 years. Their answer was no. If Moore's Law holds, in 10 to 15 years people will need a 65th bit. As a 128-bit system, ZFS is designed to support more storage, more file systems, more snapshots, more directory entries, and more files than can possibly be created in the foreseeable future." Call me crazy, but does anyone else see this as hooey? 2^64 512B sectors is 8192 zettabytes (zetta, exa, peta, tera, ...). I'm also wondering what perversion of moore's law is applicable to storage consumption. Crappy marketing articles. Sam From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 15:29:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40A1916A4CE for ; Wed, 15 Sep 2004 15:29:06 +0000 (GMT) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 079C643D5D for ; Wed, 15 Sep 2004 15:29:06 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id 3B22D21; Wed, 15 Sep 2004 17:29:05 +0200 (CEST) Resent-From: andrea@webcom.it Resent-Date: Wed, 15 Sep 2004 17:29:05 +0200 Resent-Message-ID: <20040915152905.GC68395@webcom.it> Resent-To: hackers@freebsd.org Date: Wed, 15 Sep 2004 17:26:39 +0200 From: Andrea Campi To: Sam Message-ID: <20040915152639.GB68395@webcom.it> References: <41483C97.2030303@fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Sep 2004 15:29:06 -0000 On Wed, Sep 15, 2004 at 10:59:36AM -0500, Sam wrote: > Call me crazy, but does anyone else see this as hooey? 2^64 512B > sectors is 8192 zettabytes (zetta, exa, peta, tera, ...). [...] > Crappy marketing articles. This one's good though. fortune(6) worthy, I mean: Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn't fill a 128-bit storage pool without boiling the oceans. Bye, Andrea -- Press every key to continue. From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 15:39:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D854B16A4CE for ; Wed, 15 Sep 2004 15:39:11 +0000 (GMT) Received: from smtp.distributel.net (cns2.distributel.NET [66.38.181.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F11E943D1D for ; Wed, 15 Sep 2004 15:39:08 +0000 (GMT) (envelope-from paul@colba.net) Received: from [10.14.61.42] (OUT.NAT01.MTNDODS.distributel.NET [66.38.181.24]) by smtp.distributel.net (8.12.6/8.12.6) with ESMTP id i8FFd6iU009228 for ; Wed, 15 Sep 2004 11:39:06 -0400 (EDT) From: Paul To: freebsd-hackers@freebsd.org Content-Type: text/plain Organization: DISTRIBUTEL Message-Id: <1095262830.10708.2.camel@paul> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 15 Sep 2004 11:40:30 -0400 Content-Transfer-Encoding: 7bit Subject: FibreChannel support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: paul@colba.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2004 15:39:12 -0000 Hi Guys. Is there anyone using fibrechannel SAN solutions with FreeBSD ? I have a couple questions: 1) Is concurrent access possible ? Like in a server cluster csenario where multiple servers share the same LUN ? 2) Is there a way to grow partitions when more drives are added to the SAN array ? Thanx Paul From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 15:43:44 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF59A16A4CE for ; Wed, 15 Sep 2004 15:43:44 +0000 (GMT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1310D43D55 for ; Wed, 15 Sep 2004 15:43:44 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr4.xs4all.nl (8.12.11/8.12.11) with ESMTP id i8FFhcSe068933; Wed, 15 Sep 2004 17:43:42 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i8FFhcjV055839; Wed, 15 Sep 2004 17:43:38 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i8FFhcfM055838; Wed, 15 Sep 2004 17:43:38 +0200 (CEST) (envelope-from wb) Date: Wed, 15 Sep 2004 17:43:38 +0200 From: Wilko Bulte To: Andrea Campi Message-ID: <20040915154338.GA55823@freebie.xs4all.nl> References: <41483C97.2030303@fer.hr> <20040915152639.GB68395@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040915152639.GB68395@webcom.it> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner cc: Sam cc: hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Sep 2004 15:43:44 -0000 On Wed, Sep 15, 2004 at 05:26:39PM +0200, Andrea Campi wrote.. > On Wed, Sep 15, 2004 at 10:59:36AM -0500, Sam wrote: > > Call me crazy, but does anyone else see this as hooey? 2^64 512B > > sectors is 8192 zettabytes (zetta, exa, peta, tera, ...). > [...] > > Crappy marketing articles. > > This one's good though. fortune(6) worthy, I mean: > > Populating 128-bit file systems would exceed the quantum limits of > earth-based storage. You couldn't fill a 128-bit storage pool without > boiling the oceans. Hmmmm... that explains the global warming then... -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 17:03:31 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE15A16A4CE for ; Wed, 15 Sep 2004 17:03:30 +0000 (GMT) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.69.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DCEB43D53 for ; Wed, 15 Sep 2004 17:03:29 +0000 (GMT) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost.infracaninophile.co.uk [IPv6:::1])i8FH3MDH075773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Sep 2004 18:03:22 +0100 (BST) (envelope-from matthew@happy-idiot-talk.infracaninophile.co.uk) Received: (from matthew@localhost)i8FH3Mft075772; Wed, 15 Sep 2004 18:03:22 +0100 (BST) (envelope-from matthew) Date: Wed, 15 Sep 2004 18:03:22 +0100 From: Matthew Seaman To: Wilko Bulte Message-ID: <20040915170322.GA75590@happy-idiot-talk.infracaninophile.co.uk> Mail-Followup-To: Matthew Seaman , Wilko Bulte , Andrea Campi , Sam , hackers@freebsd.org References: <41483C97.2030303@fer.hr> <20040915152639.GB68395@webcom.it> <20040915154338.GA55823@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline In-Reply-To: <20040915154338.GA55823@freebie.xs4all.nl> User-Agent: Mutt/1.4.2.1i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (smtp.infracaninophile.co.uk [IPv6:::1]); Wed, 15 Sep 2004 18:03:22 +0100 (BST) X-Virus-Scanned: clamd / ClamAV version devel-20040904, clamav-milter version 0.75l on smtp.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on happy-idiot-talk.infracaninophile.co.uk cc: Sam cc: hackers@freebsd.org cc: Andrea Campi Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Sep 2004 17:03:31 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 15, 2004 at 05:43:38PM +0200, Wilko Bulte wrote: > On Wed, Sep 15, 2004 at 05:26:39PM +0200, Andrea Campi wrote.. > > On Wed, Sep 15, 2004 at 10:59:36AM -0500, Sam wrote: > > > Call me crazy, but does anyone else see this as hooey? 2^64 512B > > > sectors is 8192 zettabytes (zetta, exa, peta, tera, ...). > > [...] > > > Crappy marketing articles. > >=20 > > This one's good though. fortune(6) worthy, I mean: > >=20 > > Populating 128-bit file systems would exceed the quantum limits of > > earth-based storage. You couldn't fill a 128-bit storage pool without > > boiling the oceans. >=20 > Hmmmm... that explains the global warming then... I once calculated that there were sufficient IPv6 addresses (another 128 bit quantity) to provide a distinct address for every cluster of about 10^12 atoms within planet Earth. 10^12 atoms sounds like quite a lot, but it is much smaller than a typical bacterium and a hell of a lot smaller than any transistor ever manufactured: even if you converted the entire planet into a data storage system, you wouldn't have enough matter to build a filesystem that big, let alone power supplies, cabling, support structures etc. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBSHXaiD657aJF7eIRAvwJAJ455OegVT5+m5gC9XKDaryz1nv21QCgnRT/ V+/6X2QSYSk/hmdH/hLhDRY= =7eyZ -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 20:34:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07FE516A4CE for ; Wed, 15 Sep 2004 20:34:08 +0000 (GMT) Received: from phuket.psconsult.nl (ps226.psconsult.nl [213.222.19.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E68E43D60 for ; Wed, 15 Sep 2004 20:34:06 +0000 (GMT) (envelope-from fb-hackers@psconsult.nl) Received: from phuket.psconsult.nl (localhost [127.0.0.1]) by phuket.psconsult.nl (8.12.8p2/8.12.8) with ESMTP id i8FKY4Ye027137; Wed, 15 Sep 2004 22:34:04 +0200 (CEST) (envelope-from fb-hackers@psconsult.nl) Received: (from paul@localhost) by phuket.psconsult.nl (8.12.8p2/8.12.8/Submit) id i8FKY4Id027136; Wed, 15 Sep 2004 22:34:04 +0200 (CEST) Date: Wed, 15 Sep 2004 22:34:03 +0200 From: Paul Schenkeveld To: hackers@freebsd.org Message-ID: <20040915203403.GA26454@psconsult.nl> Mail-Followup-To: hackers@freebsd.org, Matthew Seaman , Wilko Bulte , Andrea Campi , Sam References: <41483C97.2030303@fer.hr> <20040915152639.GB68395@webcom.it> <20040915154338.GA55823@freebie.xs4all.nl> <20040915170322.GA75590@happy-idiot-talk.infracaninophile.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040915170322.GA75590@happy-idiot-talk.infracaninophile.co.uk> User-Agent: Mutt/1.5.6i cc: Wilko Bulte cc: Sam cc: Andrea Campi Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Sep 2004 20:34:08 -0000 On Wed, Sep 15, 2004 at 06:03:22PM +0100, Matthew Seaman wrote: > On Wed, Sep 15, 2004 at 05:43:38PM +0200, Wilko Bulte wrote: > > On Wed, Sep 15, 2004 at 05:26:39PM +0200, Andrea Campi wrote.. > > > On Wed, Sep 15, 2004 at 10:59:36AM -0500, Sam wrote: > > > > Call me crazy, but does anyone else see this as hooey? 2^64 512B > > > > sectors is 8192 zettabytes (zetta, exa, peta, tera, ...). > > > [...] > > > > Crappy marketing articles. > > > > > > This one's good though. fortune(6) worthy, I mean: > > > > > > Populating 128-bit file systems would exceed the quantum limits of > > > earth-based storage. You couldn't fill a 128-bit storage pool without > > > boiling the oceans. > > > > Hmmmm... that explains the global warming then... > > I once calculated that there were sufficient IPv6 addresses (another > 128 bit quantity) to provide a distinct address for every cluster of > about 10^12 atoms within planet Earth. 10^12 atoms sounds like quite > a lot, but it is much smaller than a typical bacterium and a hell of a > lot smaller than any transistor ever manufactured: even if you > converted the entire planet into a data storage system, you wouldn't > have enough matter to build a filesystem that big, let alone power > supplies, cabling, support structures etc. Be ware... Jules Verne was called crazy when he saw men would walk on the moon sometime. Leonardo da Vinci was laughed at when he envisioned people flying like birds. We people had things wrong in the past when we held things for impossible. We may not be around to witness storing over 2^128 bytes of information but your words sound like NEVER and I think that's a scary word. > Cheers, > > Matthew Cheers! Paul Schenkeveld From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 20:43:04 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A54316A4CE for ; Wed, 15 Sep 2004 20:43:04 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id C60AA43D46 for ; Wed, 15 Sep 2004 20:43:03 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8FLghtV023562; Wed, 15 Sep 2004 16:42:43 -0500 Date: Wed, 15 Sep 2004 16:42:43 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Paul Schenkeveld In-Reply-To: <20040915203403.GA26454@psconsult.nl> Message-ID: References: <41483C97.2030303@fer.hr> <20040915154338.GA55823@freebie.xs4all.nl> <20040915170322.GA75590@happy-idiot-talk.infracaninophile.co.uk> <20040915203403.GA26454@psconsult.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Wilko Bulte cc: hackers@freebsd.org cc: Andrea Campi Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Sep 2004 20:43:04 -0000 On Wed, 15 Sep 2004, Paul Schenkeveld wrote: > On Wed, Sep 15, 2004 at 06:03:22PM +0100, Matthew Seaman wrote: >> On Wed, Sep 15, 2004 at 05:43:38PM +0200, Wilko Bulte wrote: >>> On Wed, Sep 15, 2004 at 05:26:39PM +0200, Andrea Campi wrote.. >>>> On Wed, Sep 15, 2004 at 10:59:36AM -0500, Sam wrote: >>>>> Call me crazy, but does anyone else see this as hooey? 2^64 512B >>>>> sectors is 8192 zettabytes (zetta, exa, peta, tera, ...). >>>> [...] >>>>> Crappy marketing articles. >>>> >>>> This one's good though. fortune(6) worthy, I mean: >>>> >>>> Populating 128-bit file systems would exceed the quantum limits of >>>> earth-based storage. You couldn't fill a 128-bit storage pool without >>>> boiling the oceans. >>> >>> Hmmmm... that explains the global warming then... >> >> I once calculated that there were sufficient IPv6 addresses (another >> 128 bit quantity) to provide a distinct address for every cluster of >> about 10^12 atoms within planet Earth. 10^12 atoms sounds like quite >> a lot, but it is much smaller than a typical bacterium and a hell of a >> lot smaller than any transistor ever manufactured: even if you >> converted the entire planet into a data storage system, you wouldn't >> have enough matter to build a filesystem that big, let alone power >> supplies, cabling, support structures etc. > > Be ware... > > Jules Verne was called crazy when he saw men would walk on the moon > sometime. > > Leonardo da Vinci was laughed at when he envisioned people flying like > birds. > > We people had things wrong in the past when we held things for impossible. > > We may not be around to witness storing over 2^128 bytes of information > but your words sound like NEVER and I think that's a scary word. And of course when we get there ZFS will be the storage filesystem of choice. Sam From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 20:48:26 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB10C16A4CE for ; Wed, 15 Sep 2004 20:48:26 +0000 (GMT) Received: from electricrain.com (electricrain.com [64.71.143.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F72843D39 for ; Wed, 15 Sep 2004 20:48:26 +0000 (GMT) (envelope-from fuzzy@electricrain.com) Received: (qmail 11506 invoked by uid 540); 15 Sep 2004 20:48:24 -0000 Date: Wed, 15 Sep 2004 13:48:24 -0700 From: Chris Doherty To: hackers@freebsd.org Message-ID: <20040915204824.GI7022@zot.electricrain.com> References: <41483C97.2030303@fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: XEmacs X-Koan: mu. X-Message-Flag: This message contains absolutely no malicious code. Organization: The Inside Foundation Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: chris-freebsd@randomcamel.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2004 20:48:26 -0000 On Wed, Sep 15, 2004 at 10:59:36AM -0500, Sam said: > "Sun engineers wondered if the 64-bit capabilities of current file systems > will continue to suffice over the next 10 to 20 years. Their answer was > no. If Moore's Law holds, in 10 to 15 years people will need a 65th bit. > As a 128-bit system, ZFS is designed to support more storage, more file > systems, more snapshots, more directory entries, and more files than can > possibly be created in the foreseeable future." > > Call me crazy, but does anyone else see this as hooey? 2^64 512B > sectors is 8192 zettabytes (zetta, exa, peta, tera, ...). [snip] > Crappy marketing articles. regardless of the marketing hyperbole, a friend of mine went to a week-long Solaris 10 beta conference put on my Sun, and says that their engineers said the extrapolations did show they'd have to go beyond 64-bit filesystems in the 10-15 year timeframe, so as long as they were going to have to rewrite everything anyway, they'd just go whole-hog and do 128-bit and add a ton of shiny features while they were at it. he also reported it worked well as advertised; I'm inclined to believe him, since he has no special love for Sun, and he was speaking directly with the engineers who developed the thing. chris ------------------------------- Chris Doherty chris [at] randomcamel.net "I think," said Christopher Robin, "that we ought to eat all our provisions now, so we won't have so much to carry." -- A. A. Milne ------------------------------- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 00:30:22 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E423516A4CE for ; Thu, 16 Sep 2004 00:30:22 +0000 (GMT) Received: from mail.praemunio.com (mail.praemunio.com [66.179.47.216]) by mx1.FreeBSD.org (Postfix) with SMTP id 6357A43D49 for ; Thu, 16 Sep 2004 00:30:22 +0000 (GMT) (envelope-from frank@knobbe.us) Received: from localhost (HELO mail.knobbe.us) by localhost with SMTP; 15 Sep 2004 19:30:21 -0500 Received: from localhost (HELO ??) by localhost with SMTP; 15 Sep 2004 19:30:20 -0500 From: Frank Knobbe To: hackers@freebsd.org In-Reply-To: <200409072022.i87KM7Kf049770@wattres.Watt.COM> References: <200409072022.i87KM7Kf049770@wattres.Watt.COM> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Ju6X22j4rxtHuheldqk6" Message-Id: <1095294619.633.206.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 15 Sep 2004 19:30:19 -0500 Subject: Re: Booting encrypted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 00:30:23 -0000 --=-Ju6X22j4rxtHuheldqk6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-09-07 at 15:22, Steve Watt wrote: > Having the password compiled in to something that's necessarily clear-tex= t > on the same media? Sorry for being late... I'm still catching up on piles of email :) Instead of having a plaintext password on the same media, how about a mechanism that reads the CPU's serial number, or some other hardware dependent number that can not be read by users on a system. If the drive gets removed from the system, the attacker would have a challenge. Of course you have to be careful before you replace failed hardware that is used to derive the key :) Don't replace the failed CPU before you decrypted... no wait... uhm... :) Okay, how about an offline copy of the number in case of hardware failure... :) Seriously though, tying the boot process to a hardware dependent value that is not accessible from within the booted system might be something to consider.=20 Any thoughts? Regards, Frank --=-Ju6X22j4rxtHuheldqk6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBSN6bJjGc5ftAw8wRAkDBAJ4mkmkrgooun82LbbF22zNeuX6duwCdE2O8 LHTMD7QA9YGj/2zq18EuW9A= =DMmR -----END PGP SIGNATURE----- --=-Ju6X22j4rxtHuheldqk6-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 01:02:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B73F216A4CE for ; Thu, 16 Sep 2004 01:02:47 +0000 (GMT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id B703443D41 for ; Thu, 16 Sep 2004 01:02:46 +0000 (GMT) (envelope-from roam@ringlet.net) Received: (qmail 5005 invoked from network); 16 Sep 2004 01:00:10 -0000 Received: from unknown (HELO straylight.m.ringlet.net) (217.75.134.254) by gandalf.online.bg with SMTP; 16 Sep 2004 01:00:10 -0000 Received: (qmail 38292 invoked by uid 1000); 16 Sep 2004 01:03:17 -0000 Date: Thu, 16 Sep 2004 04:03:17 +0300 From: Peter Pentchev To: Frank Knobbe Message-ID: <20040916010317.GN1001@straylight.m.ringlet.net> Mail-Followup-To: Frank Knobbe , hackers@freebsd.org References: <200409072022.i87KM7Kf049770@wattres.Watt.COM> <1095294619.633.206.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iK/wEI4vkfDmI6Zw" Content-Disposition: inline In-Reply-To: <1095294619.633.206.camel@localhost> User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org Subject: Re: Booting encrypted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 01:02:47 -0000 --iK/wEI4vkfDmI6Zw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 15, 2004 at 07:30:19PM -0500, Frank Knobbe wrote: > On Tue, 2004-09-07 at 15:22, Steve Watt wrote: > > Having the password compiled in to something that's necessarily clear-t= ext > > on the same media? >=20 > Sorry for being late... I'm still catching up on piles of email :) >=20 >=20 > Instead of having a plaintext password on the same media, how about a > mechanism that reads the CPU's serial number, or some other hardware > dependent number that can not be read by users on a system. If the drive > gets removed from the system, the attacker would have a challenge. >=20 > Of course you have to be careful before you replace failed hardware that > is used to derive the key :) Don't replace the failed CPU before you > decrypted... no wait... uhm... :) Okay, how about an offline copy of > the number in case of hardware failure... :) >=20 > Seriously though, tying the boot process to a hardware dependent value > that is not accessible from within the booted system might be something > to consider.=20 >=20 > Any thoughts? One word that Bruce M. Simpson already mentioned: TCPA :) Well, it's not exactly what you describe, but it is basically what you describe done right - no offense intended, of course, I mean that the TCPA specs at http://trustedcomputinggroup.org/home seem to provide the benefits that you are looking for in a framework that mostly alleviates the problems. Of course, the key word is 'mostly', and there is more to TCPA than just encrypted booting, and there are lots of people who disagree with the 'more' part, but still you might want to take a look at it. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@cnsys.bg roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am the meaning of this sentence. --iK/wEI4vkfDmI6Zw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBSOZU7Ri2jRYZRVMRAk5QAKCLepMfmlIpXmBybMDL+32JVrJG9ACgrBWI 0UfYZvlKLnJkdoWHgF7yH5A= =xpbl -----END PGP SIGNATURE----- --iK/wEI4vkfDmI6Zw-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 01:18:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2D3C16A4CE for ; Thu, 16 Sep 2004 01:18:54 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AD1743D45 for ; Thu, 16 Sep 2004 01:18:54 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i8G1IdOj025968; Wed, 15 Sep 2004 20:18:39 -0500 (CDT) (envelope-from dan) Date: Wed, 15 Sep 2004 20:18:39 -0500 From: Dan Nelson To: Paul Message-ID: <20040916011838.GB29528@dan.emsphone.com> References: <1095262830.10708.2.camel@paul> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095262830.10708.2.camel@paul> X-OS: FreeBSD 5.3-BETA3 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: FibreChannel support X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 01:18:54 -0000 In the last episode (Sep 15), Paul said: > Is there anyone using fibrechannel SAN solutions with FreeBSD ? I had a FreeBSD running on a SAN using qlogic cards a few months back but had to put Linux on it. It works fine. > I have a couple questions: > > 1) Is concurrent access possible ? Like in a server cluster > csenario where multiple servers share the same LUN ? You can whare the LUN, but only one system can have the filesystem mounted. There are no shared-storage filesystems for FreeBSD (and I don't really trust the ones for Linux yet). The easiest setup is an active/passive system, where the master has the fs mounted and holds an aliased IP. When it fails, the slave mounts the volume and grabs the IP. That should allow remote NFS access at least to continue transparently. > 2) Is there a way to grow partitions when more drives are added to > the SAN array ? Sure. If don't put any FDISK or disklabel partitions on the lun (i.e. you put the filesystem directly on /dev/da#), it's really easy. Dismount the volume, run "camcontrol rescan da#" to let the system detect the new size, run "growfs /mountpoint", remount. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 02:17:34 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 674F816A4CE for ; Thu, 16 Sep 2004 02:17:34 +0000 (GMT) Received: from ds.netgate.net (ds.netgate.net [205.214.170.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 051D443D1F for ; Thu, 16 Sep 2004 02:17:34 +0000 (GMT) (envelope-from ctodd@chrismiller.com) Received: (qmail 30130 invoked from network); 16 Sep 2004 02:17:33 -0000 Received: from vp4.netgate.net (ibrew@205.214.170.248) by ds.netgate.net with SMTP; 16 Sep 2004 02:17:33 -0000 Date: Wed, 15 Sep 2004 19:17:33 -0700 (PDT) From: ctodd@chrismiller.com X-X-Sender: ibrew@vp4.netgate.net To: Peter Pentchev In-Reply-To: <20040916010317.GN1001@straylight.m.ringlet.net> Message-ID: References: <200409072022.i87KM7Kf049770@wattres.Watt.COM> <20040916010317.GN1001@straylight.m.ringlet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org cc: Frank Knobbe Subject: Re: Booting encrypted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 02:17:34 -0000 > On Wed, Sep 15, 2004 at 07:30:19PM -0500, Frank Knobbe wrote: > > On Tue, 2004-09-07 at 15:22, Steve Watt wrote: > > > > Seriously though, tying the boot process to a hardware dependent value > > that is not accessible from within the booted system might be something > > to consider. > > One word that Bruce M. Simpson already mentioned: TCPA :) First let me say thanks, this is the kind of outside the box thinking I'm looking for. My main objective is to prevent someone from removing the drive and mounting it from another *nix system and turning it into a unix toy (turning on shell access, etc) which it's not designed to be, as well as getting at the application and configuration. By having encryption done by the loader in such a way that the key can not be derived, protects the entire filesystem from tampering. Nothing this appliance is going to be doing requires super fast disk i/o so encryption is not an issue. In fact I've even considered using flash instead of a drive, but the same issue is there. I think what TCPA does has it's application, but I'm not too concerned about the disk being booted from other hardware, or the hardware being scavenged for other projects. TCPA sounds like something useful for the internet tablet PCs of "the boom" that were sold at a loss to be made up by a subscription to a service. Many of these were purchased for the hardware (~$200) and hacked for geek projects :-). Chris From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 03:24:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38BCC16A4CF for ; Thu, 16 Sep 2004 03:24:12 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id E66A043D67 for ; Thu, 16 Sep 2004 03:24:11 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id E031B651FA; Thu, 16 Sep 2004 04:24:10 +0100 (BST) 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 31208-03-2; Thu, 16 Sep 2004 04:24:10 +0100 (BST) Received: from empiric.dek.spc.org (adsl-64-171-184-46.dsl.snfc21.pacbell.net [64.171.184.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 25826651F4; Thu, 16 Sep 2004 04:24:09 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id ADF9563B3; Wed, 15 Sep 2004 20:24:06 -0700 (PDT) Date: Wed, 15 Sep 2004 20:24:06 -0700 From: Bruce M Simpson To: ctodd@chrismiller.com Message-ID: <20040916032406.GC7413@empiric.icir.org> References: <200409072022.i87KM7Kf049770@wattres.Watt.COM> <20040916010317.GN1001@straylight.m.ringlet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: hackers@freebsd.org cc: Frank Knobbe Subject: Re: Booting encrypted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 03:24:12 -0000 Hello, It really depends on how far you want to go to protect the product, and what your threat model looks like. On Wed, Sep 15, 2004 at 07:17:33PM -0700, ctodd@chrismiller.com wrote: > My main objective is to prevent someone from removing the drive and > mounting it from another *nix system and turning it into a unix toy > (turning on shell access, etc) which it's not designed to be, as well as > getting at the application and configuration. By having encryption done by > the loader in such a way that the key can not be derived, protects the > entire filesystem from tampering. Nothing this appliance is going to be > doing requires super fast disk i/o so encryption is not an issue. In fact > I've even considered using flash instead of a drive, but the same issue is > there. This is more or less what I'd proposed. The key element here is that if your key for the hard drive is stored IN ANY WAY on the hard drive, particularly in or near the loader, your appliance would be cracked fairly easily. Using TCPA, you could lock down your device in this way, and extract the symmetric key for the media from nonvolatile secure storage on the chip once the OS has logged into it. Of course you'd have to sign the OS image in such a way that booting it unlocked the secure storage. I haven't researched this point in depth but I think it may be possible. The TCPA chip generally hangs off the ICH chip in Intel chipset based systems, on the LPC bus PCI function; it's possible that you could retrofit this to a board if the existing board design does not have TCPA pinned out, by pinning out LPC, or by pinning out ISA and slotting it in on a board. Regards, BMS From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 03:28:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 462E616A4CE for ; Thu, 16 Sep 2004 03:28:55 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0848A43D58 for ; Thu, 16 Sep 2004 03:28:55 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 2D956651F7; Thu, 16 Sep 2004 04:28:54 +0100 (BST) 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 31449-01; Thu, 16 Sep 2004 04:28:53 +0100 (BST) Received: from empiric.dek.spc.org (adsl-64-171-184-46.dsl.snfc21.pacbell.net [64.171.184.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id DD80A651F4; Thu, 16 Sep 2004 04:28:52 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id AA95863B3; Wed, 15 Sep 2004 20:28:50 -0700 (PDT) Date: Wed, 15 Sep 2004 20:28:50 -0700 From: Bruce M Simpson To: Chris Doherty Message-ID: <20040916032850.GD7413@empiric.icir.org> References: <41483C97.2030303@fer.hr> <20040915204824.GI7022@zot.electricrain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040915204824.GI7022@zot.electricrain.com> cc: hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 03:28:55 -0000 On Wed, Sep 15, 2004 at 01:48:24PM -0700, Chris Doherty wrote: > regardless of the marketing hyperbole, a friend of mine went to a > week-long Solaris 10 beta conference put on my Sun, and says that their > engineers said the extrapolations did show they'd have to go beyond 64-bit > filesystems in the 10-15 year timeframe, so as long as they were going to > have to rewrite everything anyway, they'd just go whole-hog and do 128-bit > and add a ton of shiny features while they were at it. > > he also reported it worked well as advertised; I'm inclined to believe > him, since he has no special love for Sun, and he was speaking directly > with the engineers who developed the thing. On a similar note, das@ came round to my place in Berkeley just before he moved out East. He was telling me about his internship at Sun, and what DFS/ZFS/whateverFS does as he was working on it, though he was careful not to break any NDAs. The claims seem to be grounded in good engineering, and I'd take David's word for it. BMS From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 06:41:43 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C42A16A4CE for ; Thu, 16 Sep 2004 06:41:43 +0000 (GMT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id DDD8D43D45 for ; Thu, 16 Sep 2004 06:41:42 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 4026 invoked from network); 16 Sep 2004 06:41:41 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 16 Sep 2004 06:41:41 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 16 Sep 2004 01:41:40 -0500 (CDT) From: Mike Silbersack To: Sam In-Reply-To: Message-ID: <20040916013550.I11071@odysseus.silby.com> References: <41483C97.2030303@fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 06:41:43 -0000 On Wed, 15 Sep 2004, Sam wrote: > Call me crazy, but does anyone else see this as hooey? 2^64 512B > sectors is 8192 zettabytes (zetta, exa, peta, tera, ...). > > I'm also wondering what perversion of moore's law is applicable to > storage consumption. > > Crappy marketing articles. > > Sam Maybe they're actually doing some sort of sub-sector addressing, so the 2^64 refers to the number of bytes on the disk, rather than the number of sectors. That would bring it down by 2^9, and might make the argument more potent. It'll be interesting to see what Hans Reiser says about it... Obviously he's biased towards ReiserFS, but he's certainly much more familiar with FS design than most of us, and will certainly have opinions. :) Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 11:54:48 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2FBF16A4CE for ; Thu, 16 Sep 2004 11:54:48 +0000 (GMT) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [194.125.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3099043D45 for ; Thu, 16 Sep 2004 11:54:46 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0)i8GF0Vvs099717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Sep 2004 15:00:32 GMT Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id 7BE3C1D7; Thu, 16 Sep 2004 14:54:42 +0300 (EEST) From: Andrey Simonenko To: gerarra@tin.it In-Reply-To: <1095269007.00132101.1095257401@10.7.7.3> X-Newsgroups: lucky.freebsd.hackers User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (FreeBSD/4.9-STABLE (i386)) Message-Id: <20040916115442.7BE3C1D7@pm514-9.comsys.ntu-kpi.kiev.ua> Date: Thu, 16 Sep 2004 14:54:42 +0300 (EEST) cc: freebsd-hackers@freebsd.org Subject: Re: struct sysentvec field X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 11:54:48 -0000 On Wed, 15 Sep 2004 16:06:39 +0200 in lucky.freebsd.hackers, gerarra@tin.it wrote: > I've seen void (*sv_prepsyscall)(struct trapframe *, int *, u_int *, caddr_t > *); field in struct sysentvec defined in sys/sysent.h; I've seen it's call > be the current process in syscall interrupt 0x80 handling and it seems to > set number of arguments and base pointer for syscall arguments. It's not > a comment in the code, somebody could tell me what is the task of this field? > If a program has another idea of passing syscall's arguments to the kernel than FreeBSD uses (arguments are stored in a stack), then sv_prepsyscall should take actions to fetch syscall's arguments, just because the 'base' kernel does not know to get them. sv_prepsyscall is not NULL for process which use different ABI, than FreeBSD ABI. For example i386/linux/linux_sysvec.c:linux_prepsyscall() copies syscall's arguments from registers. Following will help you: Handbook's: "Advanced Topics" from "Linux Binary Compatibility". Developer's Handbook: "x86 Assembly Language Programming" From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 15 17:05:03 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC64B16A4CF; Wed, 15 Sep 2004 17:05:03 +0000 (GMT) Received: from phuket.psconsult.nl (ps226.psconsult.nl [213.222.19.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3E2E43D45; Wed, 15 Sep 2004 17:05:01 +0000 (GMT) (envelope-from fb-stable@psconsult.nl) Received: from phuket.psconsult.nl (localhost [127.0.0.1]) by phuket.psconsult.nl (8.12.8p2/8.12.8) with ESMTP id i8FH50Ye023785; Wed, 15 Sep 2004 19:05:00 +0200 (CEST) (envelope-from fb-stable@psconsult.nl) Received: (from paul@localhost) by phuket.psconsult.nl (8.12.8p2/8.12.8/Submit) id i8FH502j023784; Wed, 15 Sep 2004 19:05:00 +0200 (CEST) Date: Wed, 15 Sep 2004 19:04:59 +0200 From: Paul Schenkeveld To: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20040915170459.GA23228@psconsult.nl> Mail-Followup-To: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Mailman-Approved-At: Thu, 16 Sep 2004 12:14:27 +0000 Subject: Trying to get Quatech quad SIO to work X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 15 Sep 2004 17:05:03 -0000 Hi All, I need some help with a quad serial I/O card and the puc driver. Hardware: Intel SCB2/SCSI board, dual Pentium 3 1.4GHz, 3GB Ram Quatech QSCLP-100 quad serial board OS: FreeBSD 4.9-RELEASE-p1 #8: Wed Sep 15 18:13:54 CEST 2004 After a long search I finally found a quad serial board for 3.3V only PCI bus available locally: Quatech QSCLP-100. It's not automatically recognized by the puc(4) driver so I tried to guess the entry in pucdata.c from the pciconf -l output: # pciconf -l | grep none0 none0@pci2:10:0: class=0x070200 card=0x0170135c chip=0x0170135c rev=0x01 hdr=0x00 I added the following to the end of pucdata.c: { "Quatech quad PCI/LP", { 0x135c, 0x0170, 0, 0 }, { 0xffff, 0xffff, 0, 0 }, { { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ }, { PUC_PORT_TYPE_COM, 0x10, 0x08, COM_FREQ }, { PUC_PORT_TYPE_COM, 0x10, 0x10, COM_FREQ }, { PUC_PORT_TYPE_COM, 0x10, 0x18, COM_FREQ }, }, }, >From dmesg I can see that the card is recognized but could not be configured (boot -v flag used): found-> vendor=0x135c, dev=0x0170, revid=0x01 class=07-02-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=18 map[10]: type 1, range 32, base febf0000, size 7 map[14]: type 1, range 32, base 00004000, size 7 map[18]: type 1, range 32, base 00004080, size 5 pci2: on pcib2 puc0: port 0x4080-0x409f,0x4000-0x407f mem 0xfebf0000-0xfe bf007f irq 18 at device 10.0 on pci2 could not get resource could not get resource could not get resource could not get resource >From the documentation I know the board has 16750 Uarts and an interrupt status register. The documentation (and sources for a Linux driver) are at: http://www.psconsult.nl/quatech/ Can anyone tell me how to get this board to work, preferrably with FreeBSD-4? Many thanks in advance! Paul Schenkeveld From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 12:17:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C513216A4CE for ; Thu, 16 Sep 2004 12:17:06 +0000 (GMT) Received: from sdf.lonestar.org (ol.freeshell.org [192.94.73.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 715ED43D45 for ; Thu, 16 Sep 2004 12:17:06 +0000 (GMT) (envelope-from pieckiel@sdf.lonestar.org) Received: from sdf.lonestar.org (IDENT:pieckiel@sverige.freeshell.org [192.94.73.4]) by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id i8GCH46R001237 for ; Thu, 16 Sep 2004 12:17:04 GMT Received: (from pieckiel@localhost) by sdf.lonestar.org (8.12.10/8.12.8/Submit) id i8GCH4YH016743 for freebsd-hackers@freebsd.org; Thu, 16 Sep 2004 08:17:04 -0400 (EDT) Date: Thu, 16 Sep 2004 08:17:04 -0400 From: "Kevin A. Pieckiel" To: freebsd-hackers@freebsd.org Message-ID: <20040916121704.GA29643@SDF.LONESTAR.ORG> 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.4.2.1i Subject: PR kern/67636 closed, but still not working? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 12:17:06 -0000 I have a 5.2.1-RELEASE computer that does work, and a 5.3-BETA4 computer that doesn't. Both have custom kernels that do NOT include IPv6. I'm trying to set up IPF on the 5.3-BETA4 computer, but I get the very error message in PR kern/67636: Inability to use ipfilter module (ipl.ko) with custom kernels w/o INET6 # kldload ipl kldload: can't load ipl: No such file or directory # dmesg|tail -1 link_elf: symbol in6_cksum undefined This PR has been closed. Did it not apply to HEAD or the current branch? Can someone apply the patch into CURRENT? This PR was rated with a severity of "serious". This functionality would be nice for 5.3-RELEASE. Thanks, Kevin From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 14:32:19 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 041DC16A4CE for ; Thu, 16 Sep 2004 14:32:19 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id B04C143D2F for ; Thu, 16 Sep 2004 14:32:18 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8GFVv3J028732 for ; Thu, 16 Sep 2004 10:31:57 -0500 Date: Thu, 16 Sep 2004 10:31:57 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-hackers@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 14:32:19 -0000 On Thu, 16 Sep 2004, Jan Grant wrote: > On Wed, 15 Sep 2004, Sam wrote: > >> On Wed, 15 Sep 2004, Ivan Voras wrote: >> >>> It looks like Sun is going to obsolete their UFS: >>> http://www.sun.com/2004-0914/feature/?biga=15 >>> >>> Any comments? Anybody tried it yet? >>> It seems like they have built on and extented concepts presented by geom >>> and >>> softupdates. >>> >>> Sun's been using a lot of ideas present in FreeBSD: jails, linux >>> "emulation", and now this, and extended them nicely into their >>> "enterprise-grade" idea. It would be interesting to try it in action :) >>> >> >> "Sun engineers wondered if the 64-bit capabilities of current file systems >> will continue to suffice over the next 10 to 20 years. Their answer was no. >> If >> Moore's Law holds, in 10 to 15 years people will need a 65th bit. As a >> 128-bit >> system, ZFS is designed to support more storage, more file systems, more >> snapshots, more directory entries, and more files than can possibly be >> created >> in the foreseeable future." >> >> Call me crazy, but does anyone else see this as hooey? 2^64 512B >> sectors is 8192 zettabytes (zetta, exa, peta, tera, ...). >> >> I'm also wondering what perversion of moore's law is applicable to >> storage consumption. >> >> Crappy marketing articles. > > CERN's LHC is expected to produce 10-15 PB/year. e-science ("the grid") > is capable of producing whopping huge data sets, and people already are. > Many aspects of data custodianship are still open questions, but there's > little doubt that what's cutting-edge storage today will be in > filesystems between now and 10 years' time. Filesystem views on data > sets that are physically stored and replicated at disparate locations > around the planet are the kind of things that potentially need larger > than 64-bit quantities. > Let's suppose you generate an exabyte of storage per year. Filling a 64-bit filesystem would take you approximately 8 million years. I'm not saying we'll never get there, just that doing it now is nothing more than a "look at us, ain't we forward thinking" ploy. It's a _single filesystem_. If you want another 8192 ZB, just make another. Sam From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 15:01:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AA0B16A502 for ; Thu, 16 Sep 2004 15:01:11 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC12443D31 for ; Thu, 16 Sep 2004 15:01:10 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8GG0iuN028890; Thu, 16 Sep 2004 11:00:44 -0500 Date: Thu, 16 Sep 2004 11:00:44 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Jan Grant , freebsd-hackers@freebsd.org In-Reply-To: Message-ID: References: <41483C97.2030303@fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 15:01:11 -0000 On Thu, 16 Sep 2004, Jan Grant wrote: > On Thu, 16 Sep 2004, Sam wrote: > >> Let's suppose you generate an exabyte of storage per year. Filling a 64-bit >> filesystem would take you approximately 8 million years. > > Hang on, I'm not sure I know where these numbers are coming from. > > 1PB is - what? 2^50 bytes? That looks closer to 2^64 than your > figures indicate. I'd imagine an exabyte a year ought to be topping out > after 16 years. I'm missing about half-a-dozen orders of magnitude > somewhere it seems. 1PB is indeed 2^50 bytes, but filesystems don't address on the byte, but on the block (1K, 4K, 8k, ...). The numbers I'm using assume the filesystem addresses on the sector, which is unrealistically small. Jack it up to a 16K blocksize and you jump a few hundred ZB in size. > Yes, it's a single filesystem. But the storage most likely won't be all > in one place. Making it look like it's accessible from one place is a > good thing. ... are you hinting at multiple globally remote block accessible storage sets? Otherwise I'm at a loss. Sam From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 15:12:30 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2859316A4CE for ; Thu, 16 Sep 2004 15:12:30 +0000 (GMT) Received: from sdf.lonestar.org (ol.freeshell.org [192.94.73.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id A883743D5C for ; Thu, 16 Sep 2004 15:12:29 +0000 (GMT) (envelope-from pieckiel@sdf.lonestar.org) Received: from sdf.lonestar.org (IDENT:pieckiel@sverige.freeshell.org [192.94.73.4]) by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id i8GFCHkO023326; Thu, 16 Sep 2004 15:12:18 GMT Received: (from pieckiel@localhost) by sdf.lonestar.org (8.12.10/8.12.8/Submit) id i8GFCGC8011773; Thu, 16 Sep 2004 11:12:16 -0400 (EDT) Date: Thu, 16 Sep 2004 11:12:16 -0400 From: "Kevin A. Pieckiel" To: Sam Message-ID: <20040916151216.GB29643@SDF.LONESTAR.ORG> Mail-Followup-To: Sam , Jan Grant , freebsd-hackers@freebsd.org References: <41483C97.2030303@fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 15:12:30 -0000 > >On Thu, 16 Sep 2004, Sam wrote: > >1PB is - what? 2^50 bytes? That looks closer to 2^64 than your > >figures indicate. I'd imagine an exabyte a year ought to be topping out > >after 16 years. I'm missing about half-a-dozen orders of magnitude > >somewhere it seems. Where on earth would you find a disk system that can store 2^64 bytes of data or larger, anyway? Don't physical and technological limitations limit the total capacity of even the largest hard drives now available? It would take millions of drives, or more, to create a single 2^64 byte logical drive. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 16:19:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78D1216A4CE for ; Thu, 16 Sep 2004 16:19:41 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE6FB43D55 for ; Thu, 16 Sep 2004 16:19:40 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 7BD71651EB; Thu, 16 Sep 2004 17:19:38 +0100 (BST) 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 40780-03-3; Thu, 16 Sep 2004 17:19:38 +0100 (BST) Received: from empiric.dek.spc.org (adsl-64-171-184-46.dsl.snfc21.pacbell.net [64.171.184.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 7277A651FC; Thu, 16 Sep 2004 17:19:37 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 13FC361C6; Thu, 16 Sep 2004 09:19:35 -0700 (PDT) Date: Thu, 16 Sep 2004 09:19:35 -0700 From: Bruce M Simpson To: Sam Message-ID: <20040916161935.GJ1047@empiric.icir.org> Mail-Followup-To: Sam , Jan Grant , freebsd-hackers@freebsd.org References: <41483C97.2030303@fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 16:19:41 -0000 On Thu, Sep 16, 2004 at 11:00:44AM -0500, Sam wrote: > >Yes, it's a single filesystem. But the storage most likely won't be all > >in one place. Making it look like it's accessible from one place is a > >good thing. > > ... are you hinting at multiple globally remote block accessible storage > sets? Otherwise I'm at a loss. To the best of my knowledge, no, ZFS/DFS is only accessible locally on the machine it's mounted on. But the block storage can be scattered across multiple devices. It can be exported via NFS, this much I know. BMS From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 16:20:34 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEAAF16A4CE for ; Thu, 16 Sep 2004 16:20:34 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CE7743D3F for ; Thu, 16 Sep 2004 16:20:34 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 821B16520E; Thu, 16 Sep 2004 17:20:33 +0100 (BST) 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 40780-03-6; Thu, 16 Sep 2004 17:20:33 +0100 (BST) Received: from empiric.dek.spc.org (adsl-64-171-184-46.dsl.snfc21.pacbell.net [64.171.184.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id C81CA65213; Thu, 16 Sep 2004 17:20:32 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id A5A5B61C6; Thu, 16 Sep 2004 09:20:30 -0700 (PDT) Date: Thu, 16 Sep 2004 09:20:30 -0700 From: Bruce M Simpson To: Sam , Jan Grant , freebsd-hackers@freebsd.org Message-ID: <20040916162030.GK1047@empiric.icir.org> Mail-Followup-To: Sam , Jan Grant , freebsd-hackers@freebsd.org References: <41483C97.2030303@fer.hr> <20040916151216.GB29643@SDF.LONESTAR.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916151216.GB29643@SDF.LONESTAR.ORG> Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 16:20:34 -0000 On Thu, Sep 16, 2004 at 11:12:16AM -0400, Kevin A. Pieckiel wrote: > Where on earth would you find a disk system that can store 2^64 bytes of > data or larger, anyway? Don't physical and technological limitations > limit the total capacity of even the largest hard drives now available? > It would take millions of drives, or more, to create a single 2^64 byte > logical drive. You can bet that somebody, somewhere, needs this right now. And someone will definitely need it in the next 5-10 years. BMS From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 16:58:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 726C916A515 for ; Thu, 16 Sep 2004 16:58:38 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 235C743D48 for ; Thu, 16 Sep 2004 16:58:38 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 21364 invoked from network); 16 Sep 2004 16:58:37 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 16 Sep 2004 16:58:37 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8GGwOub066233; Thu, 16 Sep 2004 12:58:27 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Thu, 16 Sep 2004 10:57:26 -0400 User-Agent: KMail/1.6.2 References: <20040916121704.GA29643@SDF.LONESTAR.ORG> In-Reply-To: <20040916121704.GA29643@SDF.LONESTAR.ORG> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409161057.26186.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: "Kevin A. Pieckiel" Subject: Re: PR kern/67636 closed, but still not working? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 16:58:39 -0000 On Thursday 16 September 2004 08:17 am, Kevin A. Pieckiel wrote: > I have a 5.2.1-RELEASE computer that does work, and a 5.3-BETA4 computer > that doesn't. Both have custom kernels that do NOT include IPv6. > > I'm trying to set up IPF on the 5.3-BETA4 computer, but I get the very > error message in PR kern/67636: > > Inability to use ipfilter module (ipl.ko) with custom kernels w/o INET6 > > # kldload ipl > kldload: can't load ipl: No such file or directory > # dmesg|tail -1 > link_elf: symbol in6_cksum undefined > > This PR has been closed. Did it not apply to HEAD or the current branch? > Can someone apply the patch into CURRENT? This PR was rated with a > severity of "serious". This functionality would be nice for 5.3-RELEASE. > > Thanks, > Kevin If you want ipfilter but no IPv6, then compile ipfilter into your custom kernel rather than using the module. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 17:20:12 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B167316A4CE for ; Thu, 16 Sep 2004 17:20:12 +0000 (GMT) Received: from mail.praemunio.com (mail.praemunio.com [66.179.47.216]) by mx1.FreeBSD.org (Postfix) with SMTP id 2D66443D45 for ; Thu, 16 Sep 2004 17:20:12 +0000 (GMT) (envelope-from frank@knobbe.us) Received: from localhost (HELO mail.knobbe.us) by localhost with SMTP; 16 Sep 2004 12:20:10 -0500 Received: from localhost (HELO ??) by localhost with SMTP; 16 Sep 2004 12:20:10 -0500 From: Frank Knobbe To: Bruce M Simpson In-Reply-To: <20040916162030.GK1047@empiric.icir.org> References: <41483C97.2030303@fer.hr> <20040916151216.GB29643@SDF.LONESTAR.ORG> <20040916162030.GK1047@empiric.icir.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OKj/zbt3D9ZsXH7RM7/9" Message-Id: <1095355201.530.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 16 Sep 2004 12:20:02 -0500 cc: freebsd-hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 17:20:12 -0000 --=-OKj/zbt3D9ZsXH7RM7/9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2004-09-16 at 11:20, Bruce M Simpson wrote: > On Thu, Sep 16, 2004 at 11:12:16AM -0400, Kevin A. Pieckiel wrote: > > Where on earth would you find a disk system that can store 2^64 bytes o= f > > data or larger, anyway?=20 >=20 > You can bet that somebody, somewhere, needs this right now. And someone > will definitely need it in the next 5-10 years. Naahh... there is No Such Application for it. ;) Cheers, Frank --=-OKj/zbt3D9ZsXH7RM7/9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBSctBJjGc5ftAw8wRAssOAKCwOoH3nUbNuvTBNLyJIQbmFwA56gCcCYgz +S2Cc4XbVtdRZypp+NphF68= =Xz2L -----END PGP SIGNATURE----- --=-OKj/zbt3D9ZsXH7RM7/9-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 17:30:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2438816A4CE for ; Thu, 16 Sep 2004 17:30:11 +0000 (GMT) Received: from mail.praemunio.com (mail.praemunio.com [66.179.47.216]) by mx1.FreeBSD.org (Postfix) with SMTP id ABD9543D2F for ; Thu, 16 Sep 2004 17:30:10 +0000 (GMT) (envelope-from frank@knobbe.us) Received: from localhost (HELO mail.knobbe.us) by localhost with SMTP; 16 Sep 2004 12:30:09 -0500 Received: from localhost (HELO ??) by localhost with SMTP; 16 Sep 2004 12:30:08 -0500 From: Frank Knobbe To: Bruce M Simpson In-Reply-To: <20040916032406.GC7413@empiric.icir.org> References: <200409072022.i87KM7Kf049770@wattres.Watt.COM> <20040916010317.GN1001@straylight.m.ringlet.net> <20040916032406.GC7413@empiric.icir.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-C+CVKfCfJpSD0IokEevN" Message-Id: <1095355800.530.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 16 Sep 2004 12:30:01 -0500 cc: hackers@freebsd.org Subject: Re: Booting encrypted X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 17:30:11 -0000 --=-C+CVKfCfJpSD0IokEevN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-09-15 at 22:24, Bruce M Simpson wrote: > Using TCPA, you could lock down your device in this way, and extract the > symmetric key for the media from nonvolatile secure storage on the chip > once the OS has logged into it. Of course you'd have to sign the OS image > in such a way that booting it unlocked the secure storage.=20 Yes, TCPA offers solutions for that. But they might be overkill for what he wants to accomplish. Having the key in the boot loader will do what he wants -- prevent someone booting from a CD and mounting the drive. But the key on the encrypted media itself (in the boot loader) is bad practice. Hence the idea of fetching it from hardware. Sure, it is still possible to break the systems (by booting a CD, reading the CPU ID, or VGA S/N, or whatever is used, and manually decrypting the drive). But it presents a significantly higher effort, while still not dependent on TCPA ready hardware and all the (key) management stuff that comes with it. Call it a poor-mans TCPA :) It's a balance, an in-between. For real security, choose TCPA. For good-enough security, this solution may work better. All depends on the level of paranoia present :) Cheers, Frank --=-C+CVKfCfJpSD0IokEevN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBSc2YJjGc5ftAw8wRAtFaAKD06WTs28llxev5p52SJYUsj5sxAQCfa4A4 bAujvUEKzFxm3n/zfnXJt+w= =Lxbo -----END PGP SIGNATURE----- --=-C+CVKfCfJpSD0IokEevN-- From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 17:59:43 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BB9E16A531 for ; Thu, 16 Sep 2004 17:59:43 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3150943D2D for ; Thu, 16 Sep 2004 17:59:43 +0000 (GMT) (envelope-from garycor@comcast.net) Received: from [10.56.78.111] (pcp09118143pcs.union01.nj.comcast.net[69.142.234.88]) by comcast.net (sccrmhc12) with ESMTP id <20040916175942012007ervfe> (Authid: garycor); Thu, 16 Sep 2004 17:59:42 +0000 Message-ID: <4149D73C.5030309@comcast.net> Date: Thu, 16 Sep 2004 14:11:08 -0400 From: Gary Corcoran User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam References: <41483C97.2030303@fer.hr> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 17:59:43 -0000 Sam wrote: > On Thu, 16 Sep 2004, Jan Grant wrote: > >> On Thu, 16 Sep 2004, Sam wrote: >> >>> Let's suppose you generate an exabyte of storage per year. Filling a >>> 64-bit >>> filesystem would take you approximately 8 million years. >> >> >> Hang on, I'm not sure I know where these numbers are coming from. >> >> 1PB is - what? 2^50 bytes? That looks closer to 2^64 than your >> figures indicate. I'd imagine an exabyte a year ought to be topping out >> after 16 years. I'm missing about half-a-dozen orders of magnitude >> somewhere it seems. > > > 1PB is indeed 2^50 bytes, but filesystems don't address on the byte, > but on the block (1K, 4K, 8k, ...). The numbers I'm using assume > the filesystem addresses on the sector, which is unrealistically > small. Jack it up to a 16K blocksize and you jump a few hundred > ZB in size. You have to be able to *seek* on a byte boundary. Hence doesn't a "64-bit" filesystem indeed mean "only" 2^64 bytes? Gary From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 18:03:02 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0F0A16A4CE for ; Thu, 16 Sep 2004 18:03:02 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC23043D2F for ; Thu, 16 Sep 2004 18:03:02 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i8GJ2c74029881; Thu, 16 Sep 2004 14:02:38 -0500 Date: Thu, 16 Sep 2004 14:02:38 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Gary Corcoran In-Reply-To: <4149D73C.5030309@comcast.net> Message-ID: References: <41483C97.2030303@fer.hr> <4149D73C.5030309@comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 18:03:03 -0000 On Thu, 16 Sep 2004, Gary Corcoran wrote: > Sam wrote: > >> On Thu, 16 Sep 2004, Jan Grant wrote: >> >>> On Thu, 16 Sep 2004, Sam wrote: >>> >>>> Let's suppose you generate an exabyte of storage per year. Filling a >>>> 64-bit >>>> filesystem would take you approximately 8 million years. >>> >>> >>> Hang on, I'm not sure I know where these numbers are coming from. >>> >>> 1PB is - what? 2^50 bytes? That looks closer to 2^64 than your >>> figures indicate. I'd imagine an exabyte a year ought to be topping out >>> after 16 years. I'm missing about half-a-dozen orders of magnitude >>> somewhere it seems. >> >> >> 1PB is indeed 2^50 bytes, but filesystems don't address on the byte, >> but on the block (1K, 4K, 8k, ...). The numbers I'm using assume >> the filesystem addresses on the sector, which is unrealistically >> small. Jack it up to a 16K blocksize and you jump a few hundred >> ZB in size. > > You have to be able to *seek* on a byte boundary. Hence doesn't a > "64-bit" filesystem indeed mean "only" 2^64 bytes? Only for the file you're seeking on. Sam From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 18:19:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5BBF16A4CE for ; Thu, 16 Sep 2004 18:19:14 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id BECE843D3F for ; Thu, 16 Sep 2004 18:19:14 +0000 (GMT) (envelope-from garycor@comcast.net) Received: from [10.56.78.111] (pcp09118143pcs.union01.nj.comcast.net[69.142.234.88]) by comcast.net (rwcrmhc11) with ESMTP id <20040916181913013008srrqe> (Authid: garycor); Thu, 16 Sep 2004 18:19:14 +0000 Message-ID: <4149DBCF.8010908@comcast.net> Date: Thu, 16 Sep 2004 14:30:39 -0400 From: Gary Corcoran User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam References: <41483C97.2030303@fer.hr> <4149D73C.5030309@comcast.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 18:19:15 -0000 Sam wrote: > On Thu, 16 Sep 2004, Gary Corcoran wrote: > >> Sam wrote: >> >>> On Thu, 16 Sep 2004, Jan Grant wrote: >>> >>>> On Thu, 16 Sep 2004, Sam wrote: >>>> >>>>> Let's suppose you generate an exabyte of storage per year. Filling >>>>> a 64-bit >>>>> filesystem would take you approximately 8 million years. >>>> >>>> >>>> >>>> Hang on, I'm not sure I know where these numbers are coming from. >>>> >>>> 1PB is - what? 2^50 bytes? That looks closer to 2^64 than your >>>> figures indicate. I'd imagine an exabyte a year ought to be topping out >>>> after 16 years. I'm missing about half-a-dozen orders of magnitude >>>> somewhere it seems. >>> >>> >>> >>> 1PB is indeed 2^50 bytes, but filesystems don't address on the byte, >>> but on the block (1K, 4K, 8k, ...). The numbers I'm using assume >>> the filesystem addresses on the sector, which is unrealistically >>> small. Jack it up to a 16K blocksize and you jump a few hundred >>> ZB in size. >> >> >> You have to be able to *seek* on a byte boundary. Hence doesn't a >> "64-bit" filesystem indeed mean "only" 2^64 bytes? > > > Only for the file you're seeking on. Yeah, okay, there's multiple definitions of what "64-bit filesystem" is referring to. So what are FreeBSD's current filesystem limitations? 2^64 bytes files, and 2^64 blocks per filesystem? But I seem to recall some problems as people were approaching a terabyte or two ??? Gary From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 18:23:45 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34B8C16A4CE for ; Thu, 16 Sep 2004 18:23:45 +0000 (GMT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A1E3243D39 for ; Thu, 16 Sep 2004 18:23:44 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 21635 invoked from network); 16 Sep 2004 18:23:43 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 16 Sep 2004 18:23:43 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 16 Sep 2004 13:23:41 -0500 (CDT) From: Mike Silbersack To: Gary Corcoran In-Reply-To: <4149DBCF.8010908@comcast.net> Message-ID: <20040916132246.G11659@odysseus.silby.com> References: <41483C97.2030303@fer.hr> <4149D73C.5030309@comcast.net><4149DBCF.8010908@comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-hackers@freebsd.org cc: Sam Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 18:23:45 -0000 On Thu, 16 Sep 2004, Gary Corcoran wrote: > Yeah, okay, there's multiple definitions of what "64-bit filesystem" > is referring to. So what are FreeBSD's current filesystem limitations? > 2^64 bytes files, and 2^64 blocks per filesystem? But I seem to recall > some problems as people were approaching a terabyte or two ??? > > Gary Scott Long is addressing this: http://www.freebsd.org/projects/bigdisk/ (To sum up, the filesystem is fine with > 1TB, the utilities aren't.) Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 19:45:29 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BD5816A4CE for ; Thu, 16 Sep 2004 19:45:29 +0000 (GMT) Received: from VARK.homeunix.com (SYDNEYPACIFIC-FOUR-EIGHTY-SIX.MIT.EDU [18.95.6.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE51143D2D for ; Thu, 16 Sep 2004 19:45:28 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.13.1/8.12.10) with ESMTP id i8GJjQ8u003662; Thu, 16 Sep 2004 15:45:26 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.13.1/8.12.10/Submit) id i8GJjQOH003661; Thu, 16 Sep 2004 15:45:26 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 16 Sep 2004 15:45:26 -0400 From: David Schultz To: Frank Knobbe Message-ID: <20040916194526.GA3364@VARK.homeunix.com> Mail-Followup-To: Frank Knobbe , Bruce M Simpson , freebsd-hackers@FreeBSD.ORG References: <41483C97.2030303@fer.hr> <20040916151216.GB29643@SDF.LONESTAR.ORG> <20040916162030.GK1047@empiric.icir.org> <1095355201.530.14.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1095355201.530.14.camel@localhost> cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 19:45:29 -0000 On Thu, Sep 16, 2004, Frank Knobbe wrote: > On Thu, 2004-09-16 at 11:20, Bruce M Simpson wrote: > > On Thu, Sep 16, 2004 at 11:12:16AM -0400, Kevin A. Pieckiel wrote: > > > Where on earth would you find a disk system that can store 2^64 bytes of > > > data or larger, anyway? > > > > You can bet that somebody, somewhere, needs this right now. And someone > > will definitely need it in the next 5-10 years. > > Naahh... there is No Such Application for it. ;) Actually, there are a number of parties---banks, governments, geneticists, and Internet search engines, for instance---who never seem to have enough storage. I've seen lots of FUD and bad math on this thread, so let's do a quick back-of-the-envelope calculation. Hitachi and other storage vendors already ship systems with on the order of 1 petabyte (2^50B) of capacity. That's 14 doublings away from 2^64. Storage capacity has increased at 60% per year since 1991, so if history is any indicator[1], capacity will continue to double every 18 months. Ergo, 64-bit byte addresses won't be enough in 21 more years. (Other estimates are even shorter.) UFS is about two decades old, so Sun's design is at least plausible on technical grounds[2]. Moreover, the percentage of disk bandwidth that is typically dedicated to updating filesystem metadata is small, so the cost of the larger pointers is nominal. Note that I'm not arguing that 128-bit block numbers are the best choice; I'm merely trying to convince you that they are a sensible idea. Anyway, out of all the features of ZFS, support for 128-bit block numbers is among the least interesting, both from an engineering perspective and from the user's perspective. I don't know why everyone is so eager to discuss them. Much more interesting, for instance, is the pooled storage model for volume management. (Basically, you tell the system, ``I have a bunch of disks with similar QoS characteristics, and I want N filesystems on top of them.'' ZFS then dynamically shares the pool of storage among the filesystems. It's amazing how much trouble this saves.) [1] The rate of increase is not very predictable in the short term. It was pretty slow in the early 90's, then picked up with the introduction of GMR, and is now starting to slow down again. [2] Of course, you can buy yourself another decade or so by using 128-bit byte and sector addresses and 64-bit block addresses. UFS1 employs that strategy to squeeze as much as possible out of 32 bits, but the result isn't pretty. And for various reasons, that trick isn't as helpful for ZFS. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 19:55:15 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3B3E16A4CE for ; Thu, 16 Sep 2004 19:55:15 +0000 (GMT) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id B024643D4C for ; Thu, 16 Sep 2004 19:55:14 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr3.xs4all.nl (8.12.11/8.12.11) with ESMTP id i8GJt5Js075698; Thu, 16 Sep 2004 21:55:10 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i8GJt4rX064013; Thu, 16 Sep 2004 21:55:04 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i8GJt48Q064012; Thu, 16 Sep 2004 21:55:04 +0200 (CEST) (envelope-from wb) Date: Thu, 16 Sep 2004 21:55:04 +0200 From: Wilko Bulte To: Frank Knobbe , Bruce M Simpson , freebsd-hackers@FreeBSD.ORG Message-ID: <20040916195504.GA63980@freebie.xs4all.nl> References: <41483C97.2030303@fer.hr> <20040916151216.GB29643@SDF.LONESTAR.ORG> <20040916162030.GK1047@empiric.icir.org> <1095355201.530.14.camel@localhost> <20040916194526.GA3364@VARK.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916194526.GA3364@VARK.homeunix.com> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 19:55:15 -0000 On Thu, Sep 16, 2004 at 03:45:26PM -0400, David Schultz wrote.. > On Thu, Sep 16, 2004, Frank Knobbe wrote: > > On Thu, 2004-09-16 at 11:20, Bruce M Simpson wrote: > > > On Thu, Sep 16, 2004 at 11:12:16AM -0400, Kevin A. Pieckiel wrote: > > > > Where on earth would you find a disk system that can store 2^64 bytes of > > > > data or larger, anyway? > > > > > > You can bet that somebody, somewhere, needs this right now. And someone > > > will definitely need it in the next 5-10 years. > > > > Naahh... there is No Such Application for it. ;) > > Actually, there are a number of parties---banks, governments, > geneticists, and Internet search engines, for instance---who > never seem to have enough storage. > > I've seen lots of FUD and bad math on this thread, so let's do a > quick back-of-the-envelope calculation. Hitachi and other storage > vendors already ship systems with on the order of 1 petabyte > (2^50B) of capacity. That's 14 doublings away from 2^64. Storage Actually, I have been in a discussion with a customer intrested in 11PB of storage. Typically you are looking at people storing audio & video archives and the like. Or the folks that run particle accelerators or biosciences. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 20:06:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 313D516A4CE for ; Thu, 16 Sep 2004 20:06:06 +0000 (GMT) Received: from lemori.mokr.net (lemori.mokr.net [193.28.46.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EB3543D31 for ; Thu, 16 Sep 2004 20:06:05 +0000 (GMT) (envelope-from mokr@mokr.net) Received: from lemori.mokr.ru (lemori.mokr.ru [193.28.46.2]) i8GK60J1092978; Fri, 17 Sep 2004 00:06:00 +0400 (MSD) (envelope-from mokr@mokr.net) Date: Fri, 17 Sep 2004 00:05:59 +0400 (MSD) From: Sergey Mokryshev To: "Kevin A. Pieckiel" In-Reply-To: <200409161057.26186.jhb@FreeBSD.org> Message-ID: <20040917000504.T1965@lemori.mokr.net> References: <20040916121704.GA29643@SDF.LONESTAR.ORG> <200409161057.26186.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on lemori.mokr.net X-Virus-Status: Clean X-Spam-Status: No, hits=-1.5 required=6.5 tests=AWL,BAYES_00, DATE_IN_FUTURE_12_24 autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on lemori.mokr.net cc: freebsd-hackers@FreeBSD.org Subject: Re: PR kern/67636 closed, but still not working? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 20:06:06 -0000 On Thu, 16 Sep 2004, John Baldwin wrote: > On Thursday 16 September 2004 08:17 am, Kevin A. Pieckiel wrote: >> I have a 5.2.1-RELEASE computer that does work, and a 5.3-BETA4 computer >> that doesn't. Both have custom kernels that do NOT include IPv6. >> >> I'm trying to set up IPF on the 5.3-BETA4 computer, but I get the very >> error message in PR kern/67636: >> >> Inability to use ipfilter module (ipl.ko) with custom kernels w/o INET6 >> >> # kldload ipl >> kldload: can't load ipl: No such file or directory >> # dmesg|tail -1 >> link_elf: symbol in6_cksum undefined >> >> This PR has been closed. Did it not apply to HEAD or the current branch? >> Can someone apply the patch into CURRENT? This PR was rated with a >> severity of "serious". This functionality would be nice for 5.3-RELEASE. >> >> Thanks, >> Kevin > > If you want ipfilter but no IPv6, then compile ipfilter into your custom > kernel rather than using the module. > You should define NOINET6=YES in /etc/make.conf. -- Sergey S. Mokryshev SMP453, MOKR-RIPN From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 20:26:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C784B16A4D0; Thu, 16 Sep 2004 20:26:50 +0000 (GMT) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 595E443D1F; Thu, 16 Sep 2004 20:26:50 +0000 (GMT) (envelope-from mike@reifenberger.com) Received: from fwd08.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1C82q8-00059W-04; Thu, 16 Sep 2004 22:26:48 +0200 Received: from fw.reifenberger.com (S8Jq2QZOoecCwU-ahC3ug-vdE+YfOPIuyfKvYOLEAYCsPp6Gu4uGwc@[217.232.230.35]) by fmrl08.sul.t-online.com with esmtp id 1C82q0-1Mbq0O0; Thu, 16 Sep 2004 22:26:40 +0200 Received: from localhost (mike@localhost)i8GKQY09007304; Thu, 16 Sep 2004 22:26:34 +0200 (CEST) (envelope-from mike@reifenberger.com) X-Authentication-Warning: fw.reifenberger.com: mike owned process doing -bs Date: Thu, 16 Sep 2004 22:26:34 +0200 (CEST) From: Michael Reifenberger To: David Schultz In-Reply-To: <20040916194526.GA3364@VARK.homeunix.com> Message-ID: <20040916222403.B7226@fw.reifenberger.com> References: <41483C97.2030303@fer.hr> <20040916151216.GB29643@SDF.LONESTAR.ORG> <1095355201.530.14.camel@localhost> <20040916194526.GA3364@VARK.homeunix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-ID: S8Jq2QZOoecCwU-ahC3ug-vdE+YfOPIuyfKvYOLEAYCsPp6Gu4uGwc@t-dialin.net X-TOI-MSGID: 56e9acaf-1482-44ef-9ce1-3ac22d82d944 cc: freebsd-hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 20:26:50 -0000 On Thu, 16 Sep 2004, David Schultz wrote: ... > Anyway, out of all the features of ZFS, support for 128-bit block > numbers is among the least interesting, both from an engineering > perspective and from the user's perspective. I don't know why > everyone is so eager to discuss them. Much more interesting, for > instance, is the pooled storage model for volume management. > (Basically, you tell the system, ``I have a bunch of disks with > similar QoS characteristics, and I want N filesystems on top of > them.'' ZFS then dynamically shares the pool of storage among the > filesystems. It's amazing how much trouble this saves.) > Sounds like ADVFS on OSF/ALPHA... Was nice to work with. Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: Michael.Reifenberger@plaut.de | Priv: Michael@Reifenberger.com http://www.plaut.de | http://www.Reifenberger.com From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 21:02:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7EEF16A4CE; Thu, 16 Sep 2004 21:02:09 +0000 (GMT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F87043D41; Thu, 16 Sep 2004 21:02:09 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr7.xs4all.nl (8.12.11/8.12.11) with ESMTP id i8GL276c000170; Thu, 16 Sep 2004 23:02:07 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i8GL27Aj064416; Thu, 16 Sep 2004 23:02:07 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i8GL27MB064415; Thu, 16 Sep 2004 23:02:07 +0200 (CEST) (envelope-from wb) Date: Thu, 16 Sep 2004 23:02:07 +0200 From: Wilko Bulte To: Michael Reifenberger Message-ID: <20040916210207.GA64378@freebie.xs4all.nl> References: <41483C97.2030303@fer.hr> <20040916151216.GB29643@SDF.LONESTAR.ORG> <1095355201.530.14.camel@localhost> <20040916194526.GA3364@VARK.homeunix.com> <20040916222403.B7226@fw.reifenberger.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916222403.B7226@fw.reifenberger.com> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner cc: freebsd-hackers@freebsd.org cc: David Schultz Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 21:02:09 -0000 On Thu, Sep 16, 2004 at 10:26:34PM +0200, Michael Reifenberger wrote.. > On Thu, 16 Sep 2004, David Schultz wrote: > ... > >Anyway, out of all the features of ZFS, support for 128-bit block > >numbers is among the least interesting, both from an engineering > >perspective and from the user's perspective. I don't know why > >everyone is so eager to discuss them. Much more interesting, for > >instance, is the pooled storage model for volume management. > >(Basically, you tell the system, ``I have a bunch of disks with > >similar QoS characteristics, and I want N filesystems on top of > >them.'' ZFS then dynamically shares the pool of storage among the > >filesystems. It's amazing how much trouble this saves.) > > > > Sounds like ADVFS on OSF/ALPHA... > Was nice to work with. Still is. AdvFS is in Tru64/TruCluster. It is the clusterfs for TruClusters. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 21:18:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 5E8E716A4CF; Thu, 16 Sep 2004 21:18:37 +0000 (GMT) Date: Thu, 16 Sep 2004 21:18:37 +0000 From: Kris Kennaway To: Sam Message-ID: <20040916211837.GE70401@hub.freebsd.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 21:18:37 -0000 On Thu, Sep 16, 2004 at 10:31:57AM -0500, Sam wrote: > >CERN's LHC is expected to produce 10-15 PB/year. e-science ("the grid") > >is capable of producing whopping huge data sets, and people already are. > >Many aspects of data custodianship are still open questions, but there's > >little doubt that what's cutting-edge storage today will be in > >filesystems between now and 10 years' time. Filesystem views on data > >sets that are physically stored and replicated at disparate locations > >around the planet are the kind of things that potentially need larger > >than 64-bit quantities. > > > > Let's suppose you generate an exabyte of storage per year. Filling a > 64-bit filesystem would take you approximately 8 million years. > > I'm not saying we'll never get there, just that doing it now is nothing > more than a "look at us, ain't we forward thinking" ploy. It's a > _single filesystem_. If you want another 8192 ZB, just make another. The detectors in the particle accelerator at Fermilab produce raw data at a rate of 100 TB/sec (yes, 100 terabytes per second). They have to use a three-tiered system of hardware filters to throw away most of this and try to pick out the events that might actually be interesting, to get it down to a "slow" data rate of 100 MB/sec that can actually be written out to storage. If the hardware and software was up to it I'm sure they'd want to keep much more of the data than this. Now, over a year of runtime, the raw data amounts to (according to Google Calculator): (100 (terabytes / sec)) * 1 year = 3.4697207 10^21 bytes or just over 2^71 bytes in a year. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 21:22:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6568E16A4CE; Thu, 16 Sep 2004 21:22:36 +0000 (GMT) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA1F643D2F; Thu, 16 Sep 2004 21:22:35 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) i8GLMYlI045548; Thu, 16 Sep 2004 23:22:34 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i8GLMXm3064657; Thu, 16 Sep 2004 23:22:33 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i8GLMXl5064656; Thu, 16 Sep 2004 23:22:33 +0200 (CEST) (envelope-from wb) Date: Thu, 16 Sep 2004 23:22:33 +0200 From: Wilko Bulte To: Kris Kennaway Message-ID: <20040916212233.GA64634@freebie.xs4all.nl> References: <20040916211837.GE70401@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916211837.GE70401@hub.freebsd.org> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner cc: freebsd-hackers@freebsd.org cc: Sam Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 21:22:36 -0000 On Thu, Sep 16, 2004 at 09:18:37PM +0000, Kris Kennaway wrote.. > On Thu, Sep 16, 2004 at 10:31:57AM -0500, Sam wrote: > > > >CERN's LHC is expected to produce 10-15 PB/year. e-science ("the grid") > > >is capable of producing whopping huge data sets, and people already are. > > >Many aspects of data custodianship are still open questions, but there's > > >little doubt that what's cutting-edge storage today will be in > > >filesystems between now and 10 years' time. Filesystem views on data > > >sets that are physically stored and replicated at disparate locations > > >around the planet are the kind of things that potentially need larger > > >than 64-bit quantities. > > > > > > > Let's suppose you generate an exabyte of storage per year. Filling a > > 64-bit filesystem would take you approximately 8 million years. > > > > I'm not saying we'll never get there, just that doing it now is nothing > > more than a "look at us, ain't we forward thinking" ploy. It's a > > _single filesystem_. If you want another 8192 ZB, just make another. > > The detectors in the particle accelerator at Fermilab produce raw data > at a rate of 100 TB/sec (yes, 100 terabytes per second). They have to > use a three-tiered system of hardware filters to throw away most of > this and try to pick out the events that might actually be > interesting, to get it down to a "slow" data rate of 100 MB/sec that > can actually be written out to storage. If the hardware and software 100MB/s is slow, I think this number is wrong. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 21:46:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 3661A16A4D8; Thu, 16 Sep 2004 21:46:50 +0000 (GMT) Date: Thu, 16 Sep 2004 21:46:50 +0000 From: Kris Kennaway To: Wilko Bulte Message-ID: <20040916214650.GA73372@hub.freebsd.org> References: <20040916211837.GE70401@hub.freebsd.org> <20040916212233.GA64634@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916212233.GA64634@freebie.xs4all.nl> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org cc: Sam Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 21:46:50 -0000 On Thu, Sep 16, 2004 at 11:22:33PM +0200, Wilko Bulte wrote: > On Thu, Sep 16, 2004 at 09:18:37PM +0000, Kris Kennaway wrote.. > > On Thu, Sep 16, 2004 at 10:31:57AM -0500, Sam wrote: > > > > > >CERN's LHC is expected to produce 10-15 PB/year. e-science ("the grid") > > > >is capable of producing whopping huge data sets, and people already are. > > > >Many aspects of data custodianship are still open questions, but there's > > > >little doubt that what's cutting-edge storage today will be in > > > >filesystems between now and 10 years' time. Filesystem views on data > > > >sets that are physically stored and replicated at disparate locations > > > >around the planet are the kind of things that potentially need larger > > > >than 64-bit quantities. > > > > > > > > > > Let's suppose you generate an exabyte of storage per year. Filling a > > > 64-bit filesystem would take you approximately 8 million years. > > > > > > I'm not saying we'll never get there, just that doing it now is nothing > > > more than a "look at us, ain't we forward thinking" ploy. It's a > > > _single filesystem_. If you want another 8192 ZB, just make another. > > > > The detectors in the particle accelerator at Fermilab produce raw data > > at a rate of 100 TB/sec (yes, 100 terabytes per second). They have to > > use a three-tiered system of hardware filters to throw away most of > > this and try to pick out the events that might actually be > > interesting, to get it down to a "slow" data rate of 100 MB/sec that > > can actually be written out to storage. If the hardware and software > > 100MB/s is slow, I think this number is wrong. I think they do heavier software processing in the third stage, so it might have been CPU-bound instead of storage-bound. The figures I quoted were from http://humanresources.web.cern.ch/humanresources/external/training/acad/sphicas.pdf which I now see was from 1998, so this might have improved somewhat. It's also for LHC, although I have the Fermilab stats from 2001 somewhere, which I remember being of comparable magnitudes. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 21:56:13 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8862016A4CE for ; Thu, 16 Sep 2004 21:56:13 +0000 (GMT) Received: from vsmtp2.tin.it (vsmtp2alice.tin.it [212.216.176.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 139BB43D2F for ; Thu, 16 Sep 2004 21:56:13 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp2.tin.it (7.0.027) id 41499A75000309BE for freebsd-hackers@freebsd.org; Thu, 16 Sep 2004 23:56:09 +0200 Received: from [192.168.70.227] by ims3a.cp.tin.it with HTTP; Thu, 16 Sep 2004 23:56:07 +0200 Date: Thu, 16 Sep 2004 23:56:07 +0200 Message-ID: <4146316C00007764@ims3a.cp.tin.it> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: FreeBSD kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 21:56:13 -0000 Topic: Buffer Overflow in FreeBSD Versions: All the versions of FreeBSD are broken (4.x, 5.x, 6.0) Arch: x86 Date: 16/09/2004 All discussion refers to CURRENT-6.0, for other versions some things coul= d change (btw bugged). Discussion involves a lot of arch x32 dependant mechanisms, so, in some points, could sound a little bit dark. A buffer overflow has been found in i386/i386/trap.c syscall() function of FreeBSD official source tree. In order to rule syscalls mechanism, the 'particular' interrupt 128 (0x80= ) is provided in the IDT vector. To serve this interrupt, i386/i386/exception.s int0x80_syscal= l() function is done and, in the end, it calls syscall(). syscall() is responsible for loading arguments from a syscall and copying= them in a kspace pointer in order to accessing them. The code to do that is the following:= void syscall(frame) struct trapframe frame; { caddr_t params; struct sysent *callp; struct thread *td =3D curthread; struct proc *p =3D td->td_proc; register_t orig_tf_eflags; u_int sticks; int error; int narg; int args[8]; u_int code; ... narg =3D callp->sy_narg & SYF_ARGMASK; (<- you can see it's the only on= e check) if (params !=3D NULL && narg !=3D 0) error =3D copyin(params, (caddr_t)args, (u_int)(narg * sizeof(int))); else error =3D 0; ... and: > grep SYF_ARGMASK /usr/src/sys/sys/sysent.h #define SYF_ARGMASK 0x0000FFFF It's obvious that the amount of selectable memory is beyond the (8 * size= of(int)) limit of args array, so it would overwrite the saved eip by syscall() (it's invoke= d through a call) or making an interesting pointer corruption overwriting struct proc *p . It's exploitable, but the only one way I discovered is to link a new sysc= all to the sysent array and to do this you need to be root; I've no time to work on this vu= lnerability, but i think another way could be found. However it could give serious pro= blems (e.g. kernel crashes). A good patch could be a dinamyc memory allocation for args, but it's not a good solution in order to mantain a well performanced system; another one could be a st= rongest check, but it's not a good solution in order to set a good flexibility. You can get proof of concept code in http://www.gufi.org/~rookie/poc.tar.= gz (all versions). greetings rookie P.S: in order to try the bug before make and link kld, later do 'make tes= t' and start ./poc exe From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 22:17:40 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1201C16A4CE for ; Thu, 16 Sep 2004 22:17:40 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id F14DF43D46 for ; Thu, 16 Sep 2004 22:17:39 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id BEEAA7A3D2; Thu, 16 Sep 2004 15:17:39 -0700 (PDT) Message-ID: <414A1103.2030809@elischer.org> Date: Thu, 16 Sep 2004 15:17:39 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: gerarra@tin.it References: <4146316C00007764@ims3a.cp.tin.it> In-Reply-To: <4146316C00007764@ims3a.cp.tin.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 22:17:40 -0000 As you point out, gerarra@tin.it wrote: >Topic: Buffer Overflow in FreeBSD >Versions: All the versions of FreeBSD are broken (4.x, 5.x, 6.0) >Arch: x86 >Date: 16/09/2004 > > >A buffer overflow has been found in i386/i386/trap.c syscall() function >of FreeBSD official >source tree. > > [...] As you say below this is not exploitable except for root. The number of arguments for a syscall is defined within the kernel and is not supplied from an untrusted source. This means that this is not a security problem.. to load a kernel module you must be root (and not in a jail) meaning that if you wanted to, the quicker and easier exploit would be /bin/sh :-) The arg mask is not there for security, but rather to allow other values to be store in the same longword. >It's exploitable, but the only one way I discovered is to link a new syscall >to the sysent >array and to do this you need to be root; I've no time to work on this vulnerability, >but i think another way could be found. However it could give serious problems >(e.g. kernel >crashes). > > From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 22:53:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B02216A4CE; Thu, 16 Sep 2004 22:53:50 +0000 (GMT) Received: from VARK.homeunix.com (SYDNEYPACIFIC-FOUR-EIGHTY-SIX.MIT.EDU [18.95.6.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D9FC43D3F; Thu, 16 Sep 2004 22:53:50 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.13.1/8.12.10) with ESMTP id i8GMrn04001119; Thu, 16 Sep 2004 18:53:49 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.13.1/8.12.10/Submit) id i8GMrnUq001118; Thu, 16 Sep 2004 18:53:49 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 16 Sep 2004 18:53:49 -0400 From: David Schultz To: Kris Kennaway Message-ID: <20040916225349.GA892@VARK.homeunix.com> Mail-Followup-To: Kris Kennaway , Sam , freebsd-hackers@FreeBSD.ORG References: <20040916211837.GE70401@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916211837.GE70401@hub.freebsd.org> cc: freebsd-hackers@FreeBSD.ORG cc: Sam Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 22:53:50 -0000 > On Thu, Sep 16, 2004 at 10:31:57AM -0500, Sam wrote: > > Let's suppose you generate an exabyte of storage per year. Filling a > > 64-bit filesystem would take you approximately 8 million years. I suggest that you review your calculations. > > I'm not saying we'll never get there, [...] > > It's a_single filesystem_. If you want another 8192 ZB, just make another. A goal for ZFS is to eliminate that kind of nonsense. On Thu, Sep 16, 2004, Kris Kennaway wrote: > The detectors in the particle accelerator at Fermilab produce raw data > at a rate of 100 TB/sec (yes, 100 terabytes per second). They have to > use a three-tiered system of hardware filters to throw away most of > this and try to pick out the events that might actually be > interesting, to get it down to a "slow" data rate of 100 MB/sec that > can actually be written out to storage. If the hardware and software > was up to it I'm sure they'd want to keep much more of the data than > this. > > Now, over a year of runtime, the raw data amounts to (according to > Google Calculator): > > (100 (terabytes / sec)) * 1 year = 3.4697207 10^21 bytes > > or just over 2^71 bytes in a year. A UC Berkeley study has some interesting statistics on total storage sold per year, including a breakdown by medium: http://www.sims.berkeley.edu/research/projects/how-much-info-2003/printable_magnetic.pdf They place the total storage sold in 2003 at 2^68 bytes and the amount of original data produced at 2^62 bytes. From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 23:15:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84BA316A4CE for ; Thu, 16 Sep 2004 23:15:14 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 201F943D2F for ; Thu, 16 Sep 2004 23:15:14 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 7683 invoked from network); 16 Sep 2004 23:15:13 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 16 Sep 2004 23:15:13 -0000 Received: from hydrogen.funkthat.com (tgbshk@localhost.funkthat.com [127.0.0.1])i8GNFDuU018175; Thu, 16 Sep 2004 16:15:13 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i8GNFCwl018174; Thu, 16 Sep 2004 16:15:12 -0700 (PDT) Date: Thu, 16 Sep 2004 16:15:12 -0700 From: John-Mark Gurney To: Kris Kennaway , Sam , freebsd-hackers@FreeBSD.ORG Message-ID: <20040916231512.GT72089@funkthat.com> Mail-Followup-To: Kris Kennaway , Sam , freebsd-hackers@FreeBSD.ORG References: <20040916211837.GE70401@hub.freebsd.org> <20040916225349.GA892@VARK.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916225349.GA892@VARK.homeunix.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2004 23:15:14 -0000 David Schultz wrote this message on Thu, Sep 16, 2004 at 18:53 -0400: > > Now, over a year of runtime, the raw data amounts to (according to > > Google Calculator): > > > > (100 (terabytes / sec)) * 1 year = 3.4697207 10^21 bytes > > > > or just over 2^71 bytes in a year. > > A UC Berkeley study has some interesting statistics on total > storage sold per year, including a breakdown by medium: > > http://www.sims.berkeley.edu/research/projects/how-much-info-2003/printable_magnetic.pdf > > They place the total storage sold in 2003 at 2^68 bytes and the > amount of original data produced at 2^62 bytes. Ummm.. Don't forget that pdf is only talking about megnetic media.. it doesn't include all the CD/DVD+-RW? discs sold.. A single store probably has close to a half petabyte of optical media too... Plus it doesn't include all the cd and dvd's sold either.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 23:29:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB03016A4CE for ; Thu, 16 Sep 2004 23:29:24 +0000 (GMT) Received: from vsmtp2.tin.it (vsmtp2alice.tin.it [212.216.176.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BB3743D53 for ; Thu, 16 Sep 2004 23:29:24 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp2.tin.it (7.0.027) id 41499A7500036165 for freebsd-hackers@freebsd.org; Fri, 17 Sep 2004 01:29:24 +0200 Received: from [192.168.70.225] by ims3a.cp.tin.it with HTTP; Fri, 17 Sep 2004 01:29:22 +0200 Date: Fri, 17 Sep 2004 01:29:22 +0200 Message-ID: <4146316C000077FD@ims3a.cp.tin.it> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 23:29:24 -0000 > As you point out, Seen i said alredy, why repeating? I was pointing out about the problem, not security issue. Like FreeBSD user I want the patch for this code and I think is useful re= porting bug. It's an important part of the kernel so I didn't prepared a patch al= redy, I would like to know how core team will move. > The number of arguments for a syscall is defined within the kernel and > is not > supplied from an untrusted source. This means that this is not a > security problem. Inside the kernel? i can define a syscall accepting 30 args and it could send in panic freebsd kernel. I think it's a problem and a patch 'must' occur. > to load a kernel module you must be root (and not in a jail) meaning > that if you > wanted to, the quicker and easier exploit would be > /bin/sh > nice but it doesn't solve the problem. cheers, rookie From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 23:44:51 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD91C16A4CE for ; Thu, 16 Sep 2004 23:44:51 +0000 (GMT) Received: from vsmtp12.tin.it (vsmtp12.tin.it [212.216.176.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E18643D4C for ; Thu, 16 Sep 2004 23:44:51 +0000 (GMT) (envelope-from flag@tin.it) Received: from southcross.homeunix.org (82.49.164.44) by vsmtp12.tin.it (7.0.027) id 4149A03A00032A0B for freebsd-hackers@freebsd.org; Fri, 17 Sep 2004 01:44:51 +0200 Received: by southcross.homeunix.org (Postfix, from userid 1001) id 755FE20CD; Fri, 17 Sep 2004 01:55:05 +0200 (CEST) Date: Fri, 17 Sep 2004 01:55:05 +0200 From: Paolo Pisati To: FreeBSD_Hackers Message-ID: <20040916235505.GA8460@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: sysctl stuff and your article in daemon news zine 200305 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 23:44:51 -0000 Hi guys i was looking for some material about sysctl stuff when i found out phk's article in daemonews. Sysctl are simple to use but i'm stuck with SYSCTL_ADD_PROC(). Lets' take this: sysctl_ctx_init(&xxx_clist); o = SYSCTL_ADD_NODE(&xxx_clist, SYSCTL_STATIC_CHILDREN(_net), OID_AUTO, "xxx", CTLFLAG_RW, 0, "Virtual Network XXX"); SYSCTL_ADD_INT(&xxx_clist, SYSCTL_CHILDREN(o), OID_AUTO, "status", CTLFLAG_RW, &status, 0, "status of xxx"); SYSCTL_ADD_PROC(&xxx_clist, SYSCTL_CHILDREN(o), OID_AUTO, "text_xxx", CTLTYPE_STRING|CTLFLAG_WR, string, 10, sysctl_xxx_text_prg, "A", "baubaubau"); Here i create xxx under _net and start to add oid but, while "status" appear in the sysctl tree, "text_xxx" it doesn't show up. And the function sysctl_xxx_text_prg is called EVERY time i issue sysctl -a. Why it works this way? I mean, why don't "text_xxx" show up in sysctl tree? And why sysctl -a trigger sysctl_xxx_text_prg? I expected to see text_xxx near status in the sysctl tree, to be a text buffer and that sysctl_xxx_text_prg get called when i manipulate it and not everytime i list the complete sysctl tree. To put it clear, i would like something like this: net- \ |-foo |-bar |-xxx- |-... \ |-status |-text_xxx |-other_text_xxx and i would like that ONLY when i modify text_xxx my function sysctl_xxx_text_prg, it reads the content of text_prg, modify it and then write the results in other_text_xxx. Well, i know i'm wrong somewhere, but i don't know where... =P I read some sources of geom and random but i couldn't find where's my mistake, hope someone can help me... =P Thank you. -- Paolo Italian FreeBSD User Group: http://www.gufi.org From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 23:51:16 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 313F916A4CE for ; Thu, 16 Sep 2004 23:51:16 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1800143D31 for ; Thu, 16 Sep 2004 23:51:16 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 9141C7A41E; Thu, 16 Sep 2004 16:51:15 -0700 (PDT) Message-ID: <414A26F3.8030201@elischer.org> Date: Thu, 16 Sep 2004 16:51:15 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: gerarra@tin.it References: <4146316C000077FD@ims3a.cp.tin.it> In-Reply-To: <4146316C000077FD@ims3a.cp.tin.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 23:51:16 -0000 This is standard proceedure. "there is no security problem." There is not even a practical problem.. No-one is going to be able to break into your machine because of this unless they have already broken into your machine by some other method. There is an implicit understanding in the kernel that it trusts itrself to be done right.. If you wan to check this I can show you many more things we trust ourselves on in the kernel for example do you check the function pointers in vfs method arrays before calling them? If we checked everything we would never get anything done.. In the end we draw the line at "we check values that come from userspace." We trust values that come from root indirectly e.g. when root mounts a filesystem or a kld module. As you have raise dth issue we might add a KASSERT checking that it is within bounds but the check would not be turned on for normal kernels just debug kernels. gerarra@tin.it wrote: >>As you point out, >> >> > >Seen i said alredy, why repeating? I was pointing out about the problem, >not security issue. >Like FreeBSD user I want the patch for this code and I think is useful reporting >bug. It's an important part of the kernel so I didn't prepared a patch alredy, >I would like to know how core team will move. > > > >>The number of arguments for a syscall is defined within the kernel and >> >> > > > >>is not >>supplied from an untrusted source. This means that this is not a >>security problem. >> >> > >Inside the kernel? i can define a syscall accepting 30 args and it could >send in panic freebsd kernel. I think it's a problem and a patch 'must' >occur. > > > >>to load a kernel module you must be root (and not in a jail) meaning >>that if you >>wanted to, the quicker and easier exploit would be >>/bin/sh >> >> >> >nice but it doesn't solve the problem. > > what problem would that be? If you are writing a kernel module then we assume yuo are truted otherwise whoever gave you root privs is in more trouble than a crashed system. > >cheers, >rookie > > >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 23:51:21 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4405216A4D3; Thu, 16 Sep 2004 23:51:21 +0000 (GMT) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5E5E43D31; Thu, 16 Sep 2004 23:51:19 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.12.11/8.12.9) with ESMTP id i8GNoF6i006599; Thu, 16 Sep 2004 16:51:11 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.12.11/8.12.9) with ESMTP id i8GNoF1J068130; Thu, 16 Sep 2004 16:50:15 -0700 (PDT) (envelope-from frank@realtime.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.12.11/8.12.11/Submit) id i8GNoFVU068129; Thu, 16 Sep 2004 16:50:15 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <200409162350.i8GNoFVU068129@realtime.exit.com> In-Reply-To: <20040916194526.GA3364@VARK.homeunix.com> To: David Schultz Date: Thu, 16 Sep 2004 16:50:15 -0700 (PDT) X-Copyright0: Copyright 2004 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL119 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: Frank Knobbe Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: frank@exit.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2004 23:51:21 -0000 David Schultz wrote: > On Thu, Sep 16, 2004, Frank Knobbe wrote: > > On Thu, 2004-09-16 at 11:20, Bruce M Simpson wrote: > > > On Thu, Sep 16, 2004 at 11:12:16AM -0400, Kevin A. Pieckiel wrote: > > > > Where on earth would you find a disk system that can store 2^64 bytes of > > > > data or larger, anyway? > > > You can bet that somebody, somewhere, needs this right now. And someone > > > will definitely need it in the next 5-10 years. > > Naahh... there is No Such Application for it. ;) > Actually, there are a number of parties---banks, governments, > geneticists, and Internet search engines, for instance---who > never seem to have enough storage. Not to mention the folks to whom Frank was (very obliquely) referring. This whole argument just seems silly to me. So what if 128 bits seems large? Thirty years ago it would have seemed utterly ludicrous that an individual could possibly ever use even a few gigabytes of storage, but in this room I have .75 terabyte online. A zetabyte may seem like a lot now, but in thirty years? Who knows? I think that the one thing we can say is that there's pretty much zero chance that we can predict what the future will bring, "number of particles in the observable universe" notwithstanding. Personally, I think that an apparently infinite address space is a _good_ thing. At least we won't run out soon, right? :-) -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 23:59:38 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A74D916A4CE for ; Thu, 16 Sep 2004 23:59:38 +0000 (GMT) Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B48843D48 for ; Thu, 16 Sep 2004 23:59:38 +0000 (GMT) (envelope-from viro@www.linux.org.uk) Received: from viro by www.linux.org.uk with local (Exim 4.33) id 1C86A5-0007GJ-1K; Fri, 17 Sep 2004 00:59:37 +0100 Date: Fri, 17 Sep 2004 00:59:36 +0100 From: viro@parcelfarce.linux.theplanet.co.uk To: gerarra@tin.it Message-ID: <20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk> References: <4146316C000077FD@ims3a.cp.tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4146316C000077FD@ims3a.cp.tin.it> User-Agent: Mutt/1.4.1i Sender: cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 16 Sep 2004 23:59:38 -0000 On Fri, Sep 17, 2004 at 01:29:22AM +0200, gerarra@tin.it wrote: > Inside the kernel? i can define a syscall accepting 30 args and it could > send in panic freebsd kernel. I think it's a problem and a patch 'must' > occur. You could also define a syscall with no arguments and have it call panic(9). So what? From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 00:13:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E04F416A4CE for ; Fri, 17 Sep 2004 00:13:54 +0000 (GMT) Received: from vsmtp14.tin.it (vsmtp14.tin.it [212.216.176.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90B7B43D3F for ; Fri, 17 Sep 2004 00:13:54 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp14.tin.it (7.0.027) id 4149A1880003298A for freebsd-hackers@freebsd.org; Fri, 17 Sep 2004 02:13:54 +0200 Received: from [192.168.70.229] by ims3a.cp.tin.it with HTTP; Fri, 17 Sep 2004 02:13:53 +0200 Date: Fri, 17 Sep 2004 02:13:53 +0200 Message-ID: <4146316C00007819@ims3a.cp.tin.it> In-Reply-To: <414A26F3.8030201@elischer.org> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 00:13:55 -0000 >This is standard proceedure. > >"there is no security problem." >There is not even a practical problem.. > >No-one is going to be able to break into your machine because of this >unless they >have already broken into your machine by some other method. > We all agree with it, i worte 3 e-mails ago. >There is an implicit understanding in the kernel that it trusts itrself >to be done right.. >If you wan to check this I can show you many more things we trust >ourselves on in the kernel > >for example do you check the function pointers in vfs method arrays >before calling them? This is not the same situation... why an user might change vfs method poi= nters? Instead if I want to code a syscall accepting 9 arguments I can't do it..= . and it could be happen! I repeat, a check might be there... >If we checked everything we would never get anything done.. In the end >we draw the line at >"we check values that come from userspace." We trust values that come >from root indirectly >e.g. when root mounts a filesystem or a kld module. Ok, but a syscall of 9 arguments it's not so strange and nobody knows is impossible to realize. > >As you have raise dth issue we might add a KASSERT checking that it is > >within bounds but >the check would not be turned on for normal kernels just debug kernels.= > I'm very sorry for this decision. However i will write my patch (would be= enough simple) and put it in the web to let other download, but, sincerel= y, I hoped to cooperate with FreeBSD core team. greetings, rookie From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 00:40:34 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A800216A4CE for ; Fri, 17 Sep 2004 00:40:34 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FE6A43D3F for ; Fri, 17 Sep 2004 00:40:33 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id BEFE47A3D2; Thu, 16 Sep 2004 17:40:31 -0700 (PDT) Message-ID: <414A327F.2070207@elischer.org> Date: Thu, 16 Sep 2004 17:40:31 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: gerarra@tin.it References: <4146316C00007819@ims3a.cp.tin.it> In-Reply-To: <4146316C00007819@ims3a.cp.tin.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 00:40:34 -0000 gerarra@tin.it wrote: >>This is standard proceedure. >> >>"there is no security problem." >>There is not even a practical problem.. >> >>No-one is going to be able to break into your machine because of this >>unless they >>have already broken into your machine by some other method. >> >> >> > >We all agree with it, i worte 3 e-mails ago. > > > >>There is an implicit understanding in the kernel that it trusts itrself >> >> > > > >>to be done right.. >>If you wan to check this I can show you many more things we trust >>ourselves on in the kernel >> >>for example do you check the function pointers in vfs method arrays >>before calling them? >> >> > >This is not the same situation... why an user might change vfs method pointers? >Instead if I want to code a syscall accepting 9 arguments I can't do it... >and it could be happen! >I repeat, a check might be there... > > > >>If we checked everything we would never get anything done.. In the end >> >> > > > >>we draw the line at >>"we check values that come from userspace." We trust values that come >> >> >>from root indirectly > > >>e.g. when root mounts a filesystem or a kld module. >> >> > >Ok, but a syscall of 9 arguments it's not so strange and nobody knows is >impossible to realize. > If we put your patch in but as a KASSERT then anyone ruinning with debugging turned on (and no-one in their right mind would write a kernel module without turning on debugging, right?) will immediatly find the problem. > > > >>As you have raise dth issue we might add a KASSERT checking that it is >> >> > > > >>within bounds but >>the check would not be turned on for normal kernels just debug kernels. >> >> >> >I'm very sorry for this decision. However i will write my patch (would be >enough simple) and put it in the web to let other download, but, sincerely, >I hoped to cooperate with FreeBSD core team. > >greetings, > >rookie > > >_______________________________________________ >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 Sep 17 00:50:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5248616A4CE for ; Fri, 17 Sep 2004 00:50:36 +0000 (GMT) Received: from vsmtp1.tin.it (vsmtp1.tin.it [212.216.176.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id D870543D49 for ; Fri, 17 Sep 2004 00:50:35 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp1.tin.it (7.0.027) id 414947D700063B2E for freebsd-hackers@freebsd.org; Fri, 17 Sep 2004 02:50:36 +0200 Received: from [192.168.70.226] by ims3a.cp.tin.it with HTTP; Fri, 17 Sep 2004 02:50:35 +0200 Date: Fri, 17 Sep 2004 02:50:35 +0200 Message-ID: <4146316C00007823@ims3a.cp.tin.it> In-Reply-To: <20040917002301.GB73372@hub.freebsd.org> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 00:50:36 -0000 >A couple of points: > >1) No-one from the FreeBSD core team has participated in this >discussion so far. > >2) Because you initially claimed that this was a security problem, you >prejudiced people against you because it's quite obviously not >security-related, as has been discussed. If you'd initially just >asked for the sanity check for developers who might accidentally shoot >their feet off (this is what Julian suggested in response to you), >there would have been little controversy. > >Kris Hi Kris, you're quite right but: former what I mean to say is that the problem *ex= ists*. Nobody can write a syscall with more than 8 arguments and this is concept= ually wrong. In my opinion this is a mistake, no assumptions might be done on number of arguments (I've not seen a documentation about that somewhere too...). Latter, it could be a security problem. I've seen a lot of bug declared *not exploitable* exploitted by other coders after some times. Nothing is impossible. I wanted to point out that. I think this is differ= ent respect VFS pointers, don't you agree? rookie From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 00:55:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 3791916A4CF; Fri, 17 Sep 2004 00:55:11 +0000 (GMT) Date: Fri, 17 Sep 2004 00:55:11 +0000 From: Kris Kennaway To: gerarra@tin.it Message-ID: <20040917005511.GC73372@hub.freebsd.org> References: <20040917002301.GB73372@hub.freebsd.org> <4146316C00007823@ims3a.cp.tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4146316C00007823@ims3a.cp.tin.it> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 00:55:11 -0000 On Fri, Sep 17, 2004 at 02:50:35AM +0200, gerarra@tin.it wrote: > >A couple of points: > > > >1) No-one from the FreeBSD core team has participated in this > >discussion so far. > > > >2) Because you initially claimed that this was a security problem, you > >prejudiced people against you because it's quite obviously not > >security-related, as has been discussed. If you'd initially just > >asked for the sanity check for developers who might accidentally shoot > >their feet off (this is what Julian suggested in response to you), > >there would have been little controversy. > > > >Kris > > Hi Kris, > you're quite right but: former what I mean to say is that the problem *exists*. > Nobody can write a syscall with more than 8 arguments and this is conceptually > wrong. In my opinion this is a mistake, no assumptions might be done on > number of arguments (I've not seen a documentation about that somewhere > too...). Latter, it could be a security problem. I've seen a lot of bug > declared *not exploitable* exploitted by other coders after some times. > Nothing is impossible. I wanted to point out that. I think this is different > respect VFS pointers, don't you agree? No, it's just another example of what can go wrong if you already have root privileges or make a coding mistake. By the way, thanks for copying my private mail to the mailing list :P Kris From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 01:37:36 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 495EB16A4CE for ; Fri, 17 Sep 2004 01:37:36 +0000 (GMT) Received: from vsmtp3.tin.it (vsmtp3alice.tin.it [212.216.176.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE93A43D67 for ; Fri, 17 Sep 2004 01:37:35 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp3.tin.it (7.0.027) id 41499D520003A142 for freebsd-hackers@freebsd.org; Fri, 17 Sep 2004 03:37:36 +0200 Received: from [192.168.70.181] by ims3a.cp.tin.it with HTTP; Fri, 17 Sep 2004 03:37:35 +0200 Date: Fri, 17 Sep 2004 03:37:35 +0200 Message-ID: <4146316C00007833@ims3a.cp.tin.it> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 01:37:36 -0000 > >If we put your patch in but as a KASSERT then anyone ruinning with >debugging turned on >(and no-one in their right mind would write a kernel module without >turning on debugging, right?) >will immediatly find the problem. > What you can't understand is that having a limit about arguments is wrong= (it's not documented too). Why limiting to 8 and not to 20? or 65? i don'= t understand... In my opinion a patch would be better (and even quicker respect KASSERT).= rookie From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 01:53:39 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C18416A4CE for ; Fri, 17 Sep 2004 01:53:39 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3256243D39 for ; Fri, 17 Sep 2004 01:53:39 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13226 invoked from network); 17 Sep 2004 01:53:39 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 17 Sep 2004 01:53:38 -0000 Received: from slimer.baldwin.cx (slimer.baldwin.cx [192.168.0.16]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i8H1rNN5002471; Thu, 16 Sep 2004 21:53:36 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Thu, 16 Sep 2004 21:44:16 -0400 User-Agent: KMail/1.6.2 References: <4146316C00007823@ims3a.cp.tin.it> In-Reply-To: <4146316C00007823@ims3a.cp.tin.it> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200409162144.16853.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: gerarra@tin.it Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 01:53:39 -0000 On Thursday 16 September 2004 08:50 pm, gerarra@tin.it wrote: > >A couple of points: > > > >1) No-one from the FreeBSD core team has participated in this > >discussion so far. > > > >2) Because you initially claimed that this was a security problem, you > >prejudiced people against you because it's quite obviously not > >security-related, as has been discussed. If you'd initially just > >asked for the sanity check for developers who might accidentally shoot > >their feet off (this is what Julian suggested in response to you), > >there would have been little controversy. > > > >Kris > > Hi Kris, > you're quite right but: former what I mean to say is that the problem > *exists*. Nobody can write a syscall with more than 8 arguments and this is > conceptually wrong. In my opinion this is a mistake, no assumptions might > be done on number of arguments (I've not seen a documentation about that > somewhere too...). Latter, it could be a security problem. I've seen a lot > of bug declared *not exploitable* exploitted by other coders after some > times. Nothing is impossible. I wanted to point out that. I think this is > different respect VFS pointers, don't you agree? You can pass as much as you want by wrapping it in a structure and passing a pointer to the structure as the argument to the system call. See ioctl(2) for examples. People who write system calls that are supposed to be useful are expected to not panic the kernel. :) You demonstrated that in that you found the limit (8 args) and now know to not go over it. :) It's ok to require kernel programmers to think. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 05:29:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99EFE16A4CE for ; Fri, 17 Sep 2004 05:29:11 +0000 (GMT) Received: from VARK.homeunix.com (SYDNEYPACIFIC-THREE-EIGHTY-SEVEN.MIT.EDU [18.95.6.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FCF943D3F for ; Fri, 17 Sep 2004 05:29:11 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.13.1/8.12.10) with ESMTP id i8H5TAjV000896; Fri, 17 Sep 2004 01:29:10 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.13.1/8.12.10/Submit) id i8H5TAE6000895; Fri, 17 Sep 2004 01:29:10 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 17 Sep 2004 01:29:10 -0400 From: David Schultz To: gerarra@tin.it Message-ID: <20040917052910.GA858@VARK.homeunix.com> Mail-Followup-To: gerarra@tin.it, freebsd-hackers@FreeBSD.ORG References: <4146316C00007833@ims3a.cp.tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4146316C00007833@ims3a.cp.tin.it> cc: freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 05:29:11 -0000 On Fri, Sep 17, 2004, gerarra@tin.it wrote: > > > > >If we put your patch in but as a KASSERT then anyone ruinning with > >debugging turned on > >(and no-one in their right mind would write a kernel module without > >turning on debugging, right?) > >will immediatly find the problem. > > > > What you can't understand is that having a limit about arguments is wrong > (it's not documented too). Why limiting to 8 and not to 20? or 65? i don't > understand... > In my opinion a patch would be better (and even quicker respect KASSERT). Hey, until recently, Linux on i386 required a special case for any syscall with over 4 arguments. Supporting 8 makes us twice as good! ;-) From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 06:31:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F4B716A4CE for ; Fri, 17 Sep 2004 06:31:37 +0000 (GMT) Received: from smartmx-02.inode.at (smartmx-02.inode.at [213.229.60.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9D2143D2F for ; Fri, 17 Sep 2004 06:31:36 +0000 (GMT) (envelope-from mranner@inode.at) Received: from [83.64.101.63] (port=2273 helo=[83.64.101.63]) by smartmx-02.inode.at with esmtp (Exim 4.30) id 1C8CHP-0006Jx-9C for freebsd-hackers@freebsd.org; Fri, 17 Sep 2004 08:31:35 +0200 From: Michael Ranner To: freebsd-hackers@freebsd.org Date: Fri, 17 Sep 2004 08:31:11 +0200 User-Agent: KMail/1.6.2 References: <41483C97.2030303@fer.hr> <20040915152639.GB68395@webcom.it> In-Reply-To: <20040915152639.GB68395@webcom.it> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409170831.11963.mranner@inode.at> Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 06:31:37 -0000 Am Mittwoch, 15. September 2004 17:26 schrieb Andrea Campi: > On Wed, Sep 15, 2004 at 10:59:36AM -0500, Sam wrote: > > Call me crazy, but does anyone else see this as hooey? 2^64 512B > > sectors is 8192 zettabytes (zetta, exa, peta, tera, ...). > > [...] > > > Crappy marketing articles. > > This one's good though. fortune(6) worthy, I mean: > > Populating 128-bit file systems would exceed the quantum limits of > earth-based storage. You couldn't fill a 128-bit storage pool without > boiling the oceans. An technical facility with an diameter of 1 centimeter could store 10 ^ 66 bits. The maximal capability is limited by the entropy of the system, the whole visible universe has an entropy of 10 ^ 100 bits. The absolute border is the holographic border, a system increasing information storage over the holographic border will turn into a black hole. (see also Three Roads to Quantum Gravity, Von Lee Simolin, Basic Books, 2002) This may be stuff for an fortune ;) -- /\/\ichael Ranner mranner@inode.at - mranner@jawa.at - mranner@bugat.at ----------------------------------------------------- BSD Usergroup Austria - http://www.bugat.at/ -----BEGIN GEEK CODE BLOCK----- GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS++++$ 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? ------END GEEK CODE BLOCK------ From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 09:37:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3082916A4CE for ; Fri, 17 Sep 2004 09:37:25 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75F8E43D5E for ; Fri, 17 Sep 2004 09:37:24 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (host5.bedc.ondsl.gr [62.103.39.229])i8H9bK6X023120; Fri, 17 Sep 2004 12:37:21 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i8H9bDUT095303; Fri, 17 Sep 2004 12:37:13 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)i8H9bCNX095302; Fri, 17 Sep 2004 12:37:12 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Fri, 17 Sep 2004 12:37:12 +0300 From: Giorgos Keramidas To: gerarra@tin.it Message-ID: <20040917093712.GB94990@orion.daedalusnetworks.priv> References: <4146316C00007833@ims3a.cp.tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <4146316C00007833@ims3a.cp.tin.it> cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 09:37:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-09-17 03:37, gerarra@tin.it wrote: > >If we put your patch in but as a KASSERT then anyone ruinning with > >debugging turned on > >(and no-one in their right mind would write a kernel module without > >turning on debugging, right?) > >will immediatly find the problem. > > What you can't understand is that having a limit about arguments is wrong > (it's not documented too). Why limiting to 8 and not to 20? or 65? i don't > understand... As you have noted in a previous post it's probably more efficient to have a static limit than a fully dynamic implementation. I'm sure we can find a good way to document this and warn the developer who's about to shoot his feet off about potential problems. Would you feel that this limitation of syscall() is not really so important or dangerous if we documented the 8-argument limit, described a good way to pass more arguments and added a KASSERT in trap.c that is only enabled for kernels compiled with INVARIANTS turned on? % Index: lib/libc/sys/syscall.2 % =================================================================== % RCS file: /home/ncvs/src/lib/libc/sys/syscall.2,v % retrieving revision 1.11 % diff -u -r1.11 syscall.2 % --- lib/libc/sys/syscall.2 10 Sep 2003 19:24:33 -0000 1.11 % +++ lib/libc/sys/syscall.2 17 Sep 2004 09:35:44 -0000 % @@ -56,14 +56,26 @@ % interface has the specified % .Fa number % with the specified arguments. % +If non-zero, the number of arguments that a system call can have in % +.Fx % +should be at most 8. % Symbolic constants for system calls can be found in the header file % .In sys/syscall.h . % The % .Fn __syscall % form should be used when one or more of the arguments is a % 64-bit argument to ensure that argument alignment is correct. % -This system call is useful for testing new system calls that % +.Pp % +The % +.Fn syscall % +and % +.Fn __syscall % +functions are useful for testing new system calls that % do not have entries in the C library. % +If new system calls require more than 8 arguments you can always wrap % +these arguments in a % +.Vt struct % +and pass a pointer to the new system call. % .Sh RETURN VALUES % The return values are defined by the system call being invoked. % In general, a 0 return value indicates success. % % Index: sys/i386/i386/trap.c % =================================================================== % RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v % retrieving revision 1.269 % diff -u -r1.269 trap.c % --- sys/i386/i386/trap.c 31 Aug 2004 07:34:53 -0000 1.269 % +++ sys/i386/i386/trap.c 17 Sep 2004 09:21:55 -0000 % @@ -965,6 +965,9 @@ % callp = &p->p_sysent->sv_table[code]; % % narg = callp->sy_narg & SYF_ARGMASK; % +#ifdef INVARIANTS % + KASSERT(0 <= narg && narg <= 8, ("invalid number of syscall args")); % +#endif % % /* % * copyin and the ktrsyscall()/ktrsysret() code is MP-aware > In my opinion a patch would be better (and even quicker respect KASSERT). A KASSERT() wrapped in #ifdef INVARIANTS has zero overhead for normal, non-debugging kernels. The developers who are responsible for writing and testing new system calls should use INVARIANTS anyway, so they'll quickly catch the mistake. - - Giorgos -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBSrBI1g+UGjGGA7YRAk7RAJ9mfyFTYEzZNK5mDel0lqUom+UayACgpwU1 BF+ypfahuqM4ADVIx6HzO9I= =HLEr -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 09:46:54 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 298B916A4CE; Fri, 17 Sep 2004 09:46:54 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE72B43D53; Fri, 17 Sep 2004 09:46:53 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i8H9krvA021051; Fri, 17 Sep 2004 02:46:53 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i8H9kr4P021050; Fri, 17 Sep 2004 02:46:53 -0700 (PDT) (envelope-from dillon) Date: Fri, 17 Sep 2004 02:46:53 -0700 (PDT) From: Matthew Dillon Message-Id: <200409170946.i8H9kr4P021050@apollo.backplane.com> To: Giorgos Keramidas References: <4146316C00007833@ims3a.cp.tin.it> <20040917093712.GB94990@orion.daedalusnetworks.priv> cc: freebsd-hackers@freebsd.org cc: gerarra@tin.it Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 09:46:54 -0000 :pass more arguments and added a KASSERT in trap.c that is only enabled for :kernels compiled with INVARIANTS turned on? :... : :A KASSERT() wrapped in #ifdef INVARIANTS has zero overhead for normal, :non-debugging kernels. The developers who are responsible for writing and :testing new system calls should use INVARIANTS anyway, so they'll quickly :catch the mistake. : :- - Giorgos KASSERT()'s are only compiled in if INVARIANTS is turned on anyway. If you don't have INVARIANTS turned on, all your KASSERT's go poof. Look at the #define KASSERT in sys/systm.h. I strongly recommend that all kernels always be compiled with INVARIANTS turned on. Even production kernels. I believe GENERIC defaults to INVARIANTS turned on. I'm not sure what is done during release cycles but presumably INVARIANTS is left on for the release build as well (if it isn't it should be). -Matt From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 11:24:16 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DB2F16A4CE for ; Fri, 17 Sep 2004 11:24:16 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BE4D43D3F for ; Fri, 17 Sep 2004 11:24:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-64-170-123-106.dsl.snfc21.pacbell.net [64.170.123.106])i8HBOCNm241798; Fri, 17 Sep 2004 07:24:13 -0400 Message-ID: <414AC95C.9000900@elischer.org> Date: Fri, 17 Sep 2004 04:24:12 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: gerarra@tin.it References: <4146316C000082CE@ims3a.cp.tin.it> In-Reply-To: <4146316C000082CE@ims3a.cp.tin.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 11:24:16 -0000 gerarra@tin.it wrote: > >>Some architectures are limited in the numer of arguments that they allow >>to be >>passed as direct values in a syscall. It is considerred pretty bad style >>to >>use too many. If one wants to pass more data then it is preferable to have >>a structure and pass a POINTER to it. >> > > > I wonder why you repeat obvious things... Because you are not listenning maybe? (as just about everyone on IRC has commented, so it's not just me. I'm just he guy who decided to answer you..). > > >>Suggesting that the linit of 8 be upped however is a lot different from > > coming > >>out of nowhere claining that there is a big problem with buffer over-runs >>(which are interpretted as security flaws) >> > > > You don't seem so practice in security. Let me say one thing. A lot of exploits > are done for parts initially "not exploitable". The fact you and me haven't > found a way to do that doesn't mean it can't be done... LISTEN! YOU CAN NOT CHANGE THE NUMBER OF ARGUMENTS ON A SYSCALL UNLESS YOU ARE ROOT ALREADY! OK? if you can then there are much more interesting targets to go after than that.. > > >>Nowhere did you suggest that your aim is to increase the number >>of arguments acceptable to a syscall but rather you presented the problem >>as >>a consistency problem. >> > > > Maybe you need to read again my first advisory. And maybe the whole topic... You did you give an advisory. you gave a misinformed misleading email about something that is not a problem. > > >>As a matter of style ond consistency the way that I perceive the developers >>as >>taking in our discussions is that 8 is far more than enough and that >>a debug failure for > 8 would be just fine. >> > > > IMHO is not a good patch, but if you want... > > >>If you can show your patch and it is of a high quality then it will be > > a > >>lot >>more useful to your cause than making a lot of misleading and misdirected >>claims on the mailing lists, and wasting everyone's time for a problem > > that > >>really doesn't exist.. > > > The problem exists. Even a good "You can't add more than 8 arguments to > your syscall (without wrapping in struct)" in some handbook could be useful. > I don't thing I'm wasting time of everyone, that's just a bug report and > the fact *you* thing is not a problem doesn't mean it doesn't exist. Asking for this fact to be documented somewhere is a far cry from your initial "advisory. What you SHOULD have done is as follows. "In a private project I am doing I need to add a syscall with more than 8 arguments. In order to allow me to do this I needed to add the following patch. .. [shows patch].. Since this patch is of no real cost and adds functionality, could it please be incorporated. I have submitted it in pr kern/xyzzy" That would have gotten you a lot more positive response than a false advisory. (though you would have probably been told by most people to use copyin/copyout and a structure because the syscall interface is one of the parts of the system that is under current scrutiny for improvement and optimisation and people aretupid a likely to consider mor ethan 8 arguments as not a necessity if it slows things down at all. I've been doing this for 30 years and on BSD for 15 years so I DO know what I am talking about when I say that what you pointed out is understood as NOT A SECURITY ISSUE by everyone concerned. It's like complaining that the seats on a jumbo cannot withstand 800C temperature... if you have 800C on the seats you have bigger problems to worry about. so if you decide to rephrse what you want we'll listen to you. if you want to go around making false bug reports then that's ok too but we won't listen.. it's your choice. > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 12:55:30 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBF4716A4CE for ; Thu, 16 Sep 2004 12:55:30 +0000 (GMT) Received: from carteiro.parati.com (200.175.3.79.tbprof.gvt.net.br [200.175.3.79]) by mx1.FreeBSD.org (Postfix) with SMTP id 03E9743D1F for ; Thu, 16 Sep 2004 12:55:29 +0000 (GMT) (envelope-from cantarella@senffnet.com.br) Received: (qmail 532 invoked from network); 16 Sep 2004 12:55:57 -0000 Received: from unknown (HELO parati.com) (172.16.5.177) by carteiro.senffnet with SMTP; 16 Sep 2004 12:55:57 -0000 Received: (qmail 22366 invoked by uid 510); 14 Sep 2004 08:54:02 -0000 Received: from unknown (HELO 200.140.233.95) (200.203.188.135) by mail.parati.com with SMTP; 14 Sep 2004 08:54:02 -0000 Received: from phpmailer ([200.140.233.95]) by 200.140.233.95 with HTTP (UebiMiau); Tue, 14 Sep 2004 08:54:02 +0000 Date: Tue, 14 Sep 2004 08:54:02 +0000 To: freebsd-hackers@freebsd.org From: Cantarella Message-ID: <7ea4ce2e54aa7d07618278640e7be260@200.140.233.95> X-Priority: 3 X-Mailer: UebiMiau [PHPMailer version 1.70] Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 17 Sep 2004 12:08:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Editing and compiling FreeBSD source X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Cantarella List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2004 12:55:31 -0000 This is my first e-mail for this list. I am interested in studing to better understand FreeBSD´s source code. With 'make buildkernel' and 'make installkernel' is it possible to compile the changes that I have made? The changes are simple (just some printf). I am just beginning this trip through FreeBSD´s source code. -- ------------------- Cesar Cantarella ________________________________________________ Message sent using UebiMiau 2.7.8 From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 02:04:46 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E041716A4CE for ; Fri, 17 Sep 2004 02:04:46 +0000 (GMT) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA4A043D5C for ; Fri, 17 Sep 2004 02:04:46 +0000 (GMT) (envelope-from mwm-dated-1096248274.a40ab9@mired.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 8FC1A1256AF for ; Thu, 16 Sep 2004 19:04:45 -0700 (PDT) Received: from mired.org (mwm@idiom [216.240.32.1]) by idiom.com (8.12.11/8.12.11) with SMTP id i8H1OYqv018629 for ; Thu, 16 Sep 2004 18:24:34 -0700 (PDT) (envelope-from mwm-dated-1096248274.a40ab9@mired.org) Received: (qmail 68982 invoked by uid 100); 17 Sep 2004 01:24:34 -0000 Received: by guru.mired.org (tmda-sendmail, from uid 100); Thu, 16 Sep 2004 20:24:33 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16714.15569.122973.367346@guru.mired.org> Date: Thu, 16 Sep 2004 20:24:33 -0500 To: gerarra@tin.it In-Reply-To: <4146316C00007823@ims3a.cp.tin.it> References: <20040917002301.GB73372@hub.freebsd.org> <4146316C00007823@ims3a.cp.tin.it> X-Mailer: VM 7.17 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer X-Mailman-Approved-At: Fri, 17 Sep 2004 12:08:03 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 02:04:47 -0000 > Nobody can write a syscall with more than 8 arguments and this is conceptually > wrong. In my opinion this is a mistake, no assumptions might be done on I'd argue that a syscall with 9 or more arguments is conceptually wrong in the first place. Anything with that many knobs needs to be an object, not a simple list of parameters. In other words, you should bundle the parameters up into a struct, and pass a pointer to the struct. Take a look at namei (which used to have a very long argument list) for an example of what I mean. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 10:45:15 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8ECF216A4CE for ; Fri, 17 Sep 2004 10:45:15 +0000 (GMT) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id C804743D49 for ; Fri, 17 Sep 2004 10:45:14 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from orion.daedalusnetworks.priv (host5.bedc.ondsl.gr [62.103.39.229])i8HAj5sx028535; Fri, 17 Sep 2004 13:45:08 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i8HAirSN066598; Fri, 17 Sep 2004 13:44:53 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost)i8HAireq066580; Fri, 17 Sep 2004 13:44:53 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 17 Sep 2004 13:44:53 +0300 From: Giorgos Keramidas To: Matthew Dillon Message-ID: <20040917104453.GB21013@orion.daedalusnetworks.priv> References: <4146316C00007833@ims3a.cp.tin.it> <20040917093712.GB94990@orion.daedalusnetworks.priv> <200409170946.i8H9kr4P021050@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409170946.i8H9kr4P021050@apollo.backplane.com> X-Mailman-Approved-At: Fri, 17 Sep 2004 12:08:03 +0000 cc: freebsd-hackers@freebsd.org cc: gerarra@tin.it Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 17 Sep 2004 10:45:15 -0000 On 2004-09-17 02:46, Matthew Dillon wrote: > :A KASSERT() wrapped in #ifdef INVARIANTS has zero overhead for normal, > :non-debugging kernels. The developers who are responsible for writing and > :testing new system calls should use INVARIANTS anyway, so they'll quickly > :catch the mistake. > > I strongly recommend that all kernels always be compiled with INVARIANTS > turned on. Even production kernels. I believe GENERIC defaults to > INVARIANTS turned on. In -CURRENT it's enabled for all platforms: : $ grep 'INVARIANTS[[:space:]]' */conf/GENERIC : alpha/conf/GENERIC:options INVARIANTS #Enable calls of extra sanity checking : amd64/conf/GENERIC:options INVARIANTS # Enable calls of extra sanity checking : i386/conf/GENERIC:options INVARIANTS # Enable calls of extra sanity checking : pc98/conf/GENERIC:options INVARIANTS # Enable calls of extra sanity checking : powerpc/conf/GENERIC:options INVARIANTS #Enable calls of extra sanity checking : sparc64/conf/GENERIC:options INVARIANTS # Enable calls of extra sanity checking > I'm not sure what is done during release cycles but presumably > INVARIANTS is left on for the release build as well (if it isn't it > should be). I'm not sure either. I've been running HEAD for a long time; for an informed answer I'd have to ask the RE people. - Giorgos From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 18:31:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E743416A4CE for ; Fri, 17 Sep 2004 18:31:35 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id A27B043D54 for ; Fri, 17 Sep 2004 18:31:35 +0000 (GMT) (envelope-from mymuss@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so46757rnk for ; Fri, 17 Sep 2004 11:31:22 -0700 (PDT) Received: by 10.38.13.52 with SMTP id 52mr172262rnm; Fri, 17 Sep 2004 11:31:21 -0700 (PDT) Received: by 10.38.72.66 with HTTP; Fri, 17 Sep 2004 11:31:21 -0700 (PDT) Message-ID: Date: Fri, 17 Sep 2004 21:31:21 +0300 From: Andrew Novikov To: Cantarella In-Reply-To: <7ea4ce2e54aa7d07618278640e7be260@200.140.233.95> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable References: <7ea4ce2e54aa7d07618278640e7be260@200.140.233.95> cc: freebsd-hackers@freebsd.org Subject: Re: Editing and compiling FreeBSD source X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Andrew Novikov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2004 18:31:36 -0000 Hi, On Tue, 14 Sep 2004 08:54:02 +0000, Cantarella wrote: >=20 > This is my first e-mail for this list. > I am interested in studing to better understand FreeBSD=B4s source cod= e. > With 'make buildkernel' and 'make installkernel' is it possible to > compile the changes that I have made? > The changes are simple (just some printf). I am just beginning this > trip through FreeBSD=B4s source code. yes, as long as your changes were made under /usr/src/sys/ > -- > ------------------- > Cesar Cantarella --=20 Sincerely, Andrew From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 00:02:53 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDD2316A4CF for ; Sat, 18 Sep 2004 00:02:53 +0000 (GMT) Received: from pony2pub.arc.nasa.gov (pony2pub.arc.nasa.gov [128.102.31.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC3E843D5C for ; Sat, 18 Sep 2004 00:02:53 +0000 (GMT) (envelope-from jtoung@arc.nasa.gov) Received: from mrcrab.nas.nasa.gov ([129.99.139.47] verified) by pony2pub.arc.nasa.gov (CommuniGate Pro SMTP 4.1.8) with ESMTP id 13701936 for freebsd-hackers@freebsd.org; Fri, 17 Sep 2004 17:02:53 -0700 Content-Type: text/plain; charset="us-ascii" From: Jerry Toung To: freebsd-hackers@freebsd.org Date: Fri, 17 Sep 2004 17:02:58 -0700 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200409171702.58905.jtoung@arc.nasa.gov> Subject: add-symbol-file X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jtoung@arc.nasa.gov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 00:02:53 -0000 Hello list, Could somebody tell me why I can't "list" the source code of this kld? I built the module with COPTS=3D-g, it is loaded in the kernel and I run = kgdb in=20 /usr/obj/...../MYKERNEL. Everything seems to go well, except kgdb still=20 doesn't like it. However if I run kldsyms, it only loads acpi.ko.debug an= d I=20 can list it. Thank you in advance, Jerry PC203# kgdb kernel.debug /usr/home/guest/crash/vmcore.2 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.s= o:=20 Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain conditi= ons. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for detail= s. This GDB was configured as "i386-marcel-freebsd". Ready to go. Enter 'tr' to connect to the remote target with /dev/cuaa0, 'tr /dev/cuaa1' to connect to a different port or 'trf portno' to connect to the remote target with the firewire interface. portno defaults to 5556. Type 'getsyms' after connection to load kld symbols. If you're debugging a local system, you can use 'kldsyms' instead to load the kld symbols. That's a less obnoxious interface. doadump () at pcpu.h:159 (kgdb) add-symbol-file /usr/local/src/nren-6.0current/osr_src/if_osr.ko=20 0xc24b3184 -s .data 0xc24b6900 -s .bss 0xc24b6cc0 add symbol table from file "/usr/local/src/nren-6.0current/osr_src/if_osr= =2Eko"=20 at .text_addr =3D 0xc24b3184 .data_addr =3D 0xc24b6900 .bss_addr =3D 0xc24b6cc0 (y or n) y Reading symbols from /usr/local/src/nren-6.0current/osr_src/if_osr.ko...d= one. (kgdb) list *0xc24b3184 No source file for address 0xc24b3184. (kgdb) kldstat During symbol reading, Incomplete CFI data; unspecified registers at=20 0xc05ff7d1. Id Refs Address Size Name 1 4 0xc0400000 5d63e4 kernel 2 14 0xc09d7000 54784 acpi.ko 3 1 0xc2326000 6000 if_osr.ko (kgdb)=20 From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 02:42:41 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E95416A4CE for ; Sat, 18 Sep 2004 02:42:41 +0000 (GMT) Received: from keylime.silverwraith.com (keylime.silverwraith.com [69.55.228.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E647C43D3F for ; Sat, 18 Sep 2004 02:42:40 +0000 (GMT) (envelope-from lists-freebsd@silverwraith.com) Received: from keylime.silverwraith.com ([69.55.228.10]) by keylime.silverwraith.com with esmtp (Exim 4.41 (FreeBSD)) id 1C8VBO-000Jrh-Hv; Fri, 17 Sep 2004 19:42:38 -0700 Received: (from avleen@localhost)i8I2gc5X076359; Fri, 17 Sep 2004 19:42:38 -0700 (PDT) (envelope-from lists-freebsd@silverwraith.com) X-Authentication-Warning: keylime.silverwraith.com: avleen set sender to lists-freebsd@silverwraith.com using -f Date: Fri, 17 Sep 2004 19:42:38 -0700 From: Avleen Vig To: Frank Mayhar Message-ID: <20040918024238.GA54961@silverwraith.com> References: <20040916194526.GA3364@VARK.homeunix.com> <200409162350.i8GNoFVU068129@realtime.exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409162350.i8GNoFVU068129@realtime.exit.com> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: ZFS X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 02:42:41 -0000 On Thu, Sep 16, 2004 at 04:50:15PM -0700, Frank Mayhar wrote: > I think that the one thing we can say is that there's pretty much zero > chance that we can predict what the future will bring, "number of particles > in the observable universe" notwithstanding. Personally, I think that an > apparently infinite address space is a _good_ thing. At least we won't run > out soon, right? :-) IPv4, anyone? :-) You can *never* have enough numbers! -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet: irc.mindspring.com (Earthlink user access only) From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 02:52:19 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C0EC16A4CE for ; Sat, 18 Sep 2004 02:52:19 +0000 (GMT) Received: from keylime.silverwraith.com (keylime.silverwraith.com [69.55.228.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A64443D1F for ; Sat, 18 Sep 2004 02:52:19 +0000 (GMT) (envelope-from lists-freebsd@silverwraith.com) Received: from keylime.silverwraith.com ([69.55.228.10]) by keylime.silverwraith.com with esmtp (Exim 4.41 (FreeBSD)) id 1C8VKk-000Mew-Kq; Fri, 17 Sep 2004 19:52:18 -0700 Received: (from avleen@localhost)i8I2qIHp087094; Fri, 17 Sep 2004 19:52:18 -0700 (PDT) (envelope-from lists-freebsd@silverwraith.com) X-Authentication-Warning: keylime.silverwraith.com: avleen set sender to lists-freebsd@silverwraith.com using -f Date: Fri, 17 Sep 2004 19:52:18 -0700 From: Avleen Vig To: viro@parcelfarce.linux.theplanet.co.uk Message-ID: <20040918025217.GB54961@silverwraith.com> References: <4146316C000077FD@ims3a.cp.tin.it> <20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: gerarra@tin.it Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 02:52:19 -0000 On Fri, Sep 17, 2004 at 12:59:36AM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote: > > Inside the kernel? i can define a syscall accepting 30 args and it could > > send in panic freebsd kernel. I think it's a problem and a patch 'must' > > occur. > > You could also define a syscall with no arguments and have it call > panic(9). So what? The difference is, that calling panic(9) is not a bug, it's a designed mechanism to panic a kernel. The behaviour reported is NOT designed behaviour (at least, no-one has said it is). Therefore, if the man wants to write a patch to fix unintended behaviour, what's wrong with that? -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet: irc.mindspring.com (Earthlink user access only) From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 03:05:34 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FD6B16A4CE for ; Sat, 18 Sep 2004 03:05:34 +0000 (GMT) Received: from www.linux.org.uk (parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92AE243D55 for ; Sat, 18 Sep 2004 03:05:33 +0000 (GMT) (envelope-from viro@www.linux.org.uk) Received: from viro by www.linux.org.uk with local (Exim 4.33) id 1C8VXY-0001zu-15; Sat, 18 Sep 2004 04:05:32 +0100 Date: Sat, 18 Sep 2004 04:05:31 +0100 From: viro@parcelfarce.linux.theplanet.co.uk To: Avleen Vig Message-ID: <20040918030531.GA23987@parcelfarce.linux.theplanet.co.uk> References: <4146316C000077FD@ims3a.cp.tin.it> <20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk> <20040918025217.GB54961@silverwraith.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040918025217.GB54961@silverwraith.com> User-Agent: Mutt/1.4.1i Sender: cc: freebsd-hackers@freebsd.org cc: gerarra@tin.it Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 03:05:34 -0000 On Fri, Sep 17, 2004 at 07:52:18PM -0700, Avleen Vig wrote: > The difference is, that calling panic(9) is not a bug, it's a designed > mechanism to panic a kernel. > The behaviour reported is NOT designed behaviour (at least, no-one has > said it is). > > Therefore, if the man wants to write a patch to fix unintended > behaviour, what's wrong with that? Extra code on a time-critical path with no sane use whatsoever. Note that anyone who adds a syscall (or a library function, for that matter) with that many arguments deserves public humiliation for terminal lack of taste, so it's not going to help anything that wouldn't be worth rm -rf... From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 04:32:35 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07E6A16A4CE for ; Sat, 18 Sep 2004 04:32:35 +0000 (GMT) Received: from skippyii.compar.com (webpos.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45FBB43D53 for ; Sat, 18 Sep 2004 04:32:34 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [69.193.82.185])i8I4bws9040513; Sat, 18 Sep 2004 00:38:00 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: , "Avleen Vig" References: <4146316C000077FD@ims3a.cp.tin.it><20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk><20040918025217.GB54961@silverwraith.com> <20040918030531.GA23987@parcelfarce.linux.theplanet.co.uk> Date: Sat, 18 Sep 2004 00:29:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: freebsd-hackers@freebsd.org cc: gerarra@tin.it Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 04:32:35 -0000 > On Fri, Sep 17, 2004 at 07:52:18PM -0700, Avleen Vig wrote: > > The difference is, that calling panic(9) is not a bug, it's a designed > > mechanism to panic a kernel. > > The behaviour reported is NOT designed behaviour (at least, no-one has > > said it is). > > > > Therefore, if the man wants to write a patch to fix unintended > > behaviour, what's wrong with that? > > Extra code on a time-critical path with no sane use whatsoever. Note > that anyone who adds a syscall (or a library function, for that matter) > with that many arguments deserves public humiliation for terminal lack > of taste, so it's not going to help anything that wouldn't be worth > rm -rf... I disagree. It really comes down to how secure you want FreeBSD to be, and the attitude of "we don't need to protect against this case because anyone who does this is asking for trouble anyway" is one of the main reason why security holes exist in products today. (Someone else had brought this up much earlier on in the thread.) An article posted today on Slashdot ( http://www.onlamp.com/pub/a/security/2004/09/16/open_source_security_myths.html ) points out that this attitude as a key reason why OSS code isn't neccessarily more secure than commercial counterparts, even though there are more eyes on the source. We have to realize the fact that there *are* insecure FreeBSD installations out there, and because of the OSS nature of FreeBSD, the availability of the source code and public mailing lists like this one (which highlight possible security holes) makes the development of exploits much, much easier. The argument of "extra code on a time-critical path" is valid, but only if we're concerned about building the fastest BSD out there. However, we can provide a choice to system administrators by wrapping these sanity checks with a runtime if-check of a sysctl value, or a compile-time #define, much like we use for WITNESS or INVARIANTS today. I'm reminded of the old adage of "good, fast, cheap -- choose two". There's nothing preventing us from implementing all three and leaving the choice of which two to use up to the end-user. -- Matt Emmerton From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 04:43:20 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9558316A4CE for ; Sat, 18 Sep 2004 04:43:20 +0000 (GMT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13E1443D54 for ; Sat, 18 Sep 2004 04:43:20 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id EBC182BD7B for ; Sat, 18 Sep 2004 14:43:17 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 109DB51221; Sat, 18 Sep 2004 14:13:16 +0930 (CST) Date: Sat, 18 Sep 2004 14:13:16 +0930 From: Greg 'groggy' Lehey To: Jerry Toung Message-ID: <20040918044315.GE67689@wantadilla.lemis.com> References: <200409171702.58905.jtoung@arc.nasa.gov> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="10jrOL3x2xqLmOsH" Content-Disposition: inline In-Reply-To: <200409171702.58905.jtoung@arc.nasa.gov> User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: freebsd-hackers@freebsd.org Subject: Re: add-symbol-file X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 04:43:20 -0000 --10jrOL3x2xqLmOsH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Format recovered--see http://www.lemis.com/email/email-format.html] Important output wrapped. On Friday, 17 September 2004 at 17:02:58 -0700, Jerry Toung wrote: > Hello list, > Could somebody tell me why I can't "list" the source code of this kld? > I built the module with COPTS=3D-g, it is loaded in the kernel and I run = kgdb in > /usr/obj/...../MYKERNEL. Everything seems to go well, except kgdb still > doesn't like it. However if I run kldsyms, it only loads acpi.ko.debug an= d I > can list it. It looks like you're not doing it the way it was intended. As it says: > Type 'getsyms' after connection to load kld symbols. This does the add-symbol-file for you. Take a look at gdb(4) for more details. > If you're debugging a local system, you can use 'kldsyms' instead > to load the kld symbols. That's a less obnoxious interface. > doadump () at pcpu.h:159 > (kgdb) add-symbol-file /usr/local/src/nren-6.0current/osr_src/if_osr.ko > 0xc24b3184 -s .data 0xc24b6900 -s .bss 0xc24b6cc0 I'm assuming that this was broken by your MUA, and it's not the way you put it in, which must have been: > (kgdb) add-symbol-file /usr/local/src/nren-6.0current/osr_src/if_osr.ko 0= xc24b3184 -s .data 0xc24b6900 -s .bss 0xc24b6cc0 Where did you get these addresses from? They're all outside the bounds of the kld as shown below. > (kgdb) kldstat > During symbol reading, Incomplete CFI data; unspecified registers at > 0xc05ff7d1. > Id Refs Address Size Name > 1 4 0xc0400000 5d63e4 kernel > 2 14 0xc09d7000 54784 acpi.ko > 3 1 0xc2326000 6000 if_osr.ko In any case, I'm not sure that you need getsyms any more. It used to be needed to get round various gdb restrictions. What happens if you don't do anything? If that doesn't work, how about running getsyms, as suggested? Please let me know either way what happens. Greg -- When replying to this message, please take care not to mutilate the original text. =20 For more information, see http://www.lemis.com/email.html See complete headers for address and phone numbers. --10jrOL3x2xqLmOsH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFBS7zjIubykFB6QiMRAp8kAJ9I/CjGn+fs0sgyI4XgucJbqxi62ACffjY5 tjnij7PkWHCGY/KXAhNeqTg= =Hr7y -----END PGP SIGNATURE----- --10jrOL3x2xqLmOsH-- From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 05:44:11 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E86016A4CE for ; Sat, 18 Sep 2004 05:44:11 +0000 (GMT) Received: from skippyii.compar.com (old.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ECBF43D41 for ; Sat, 18 Sep 2004 05:44:00 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [69.193.82.185])i8I5lOs9044467; Sat, 18 Sep 2004 01:48:01 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <006201c49d42$0c751aa0$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: "Mike Meyer" References: <4146316C000077FD@ims3a.cp.tin.it><20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk><20040918025217.GB54961@silverwraith.com><20040918030531.GA23987@parcelfarce.linux.theplanet.co.uk><001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca> <16715.50688.830652.474272@guru.mired.org> Date: Sat, 18 Sep 2004 01:39:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: viro@parcelfarce.linux.theplanet.co.uk cc: gerarra@tin.it cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 05:44:11 -0000 ----- Original Message ----- From: "Mike Meyer" To: "Matt Emmerton" Cc: ; "Avleen Vig" ; ; Sent: Saturday, September 18, 2004 1:22 AM Subject: Re: FreeBSD Kernel buffer overflow > In <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca>, Matt Emmerton typed: > > I disagree. It really comes down to how secure you want FreeBSD to be, and > > the attitude of "we don't need to protect against this case because anyone > > who does this is asking for trouble anyway" is one of the main reason why > > security holes exist in products today. (Someone else had brought this up > > much earlier on in the thread.) > > You haven't been paying close enough attention to the discussion. To > exploit this "security problem" you have to be root. If it's an > external attacker, you're already owned. I'm well aware of that fact. That's still not a reason to protect against the problem. If your leaky bucket has 10 holes in it, would you at least try and plug some of them? -- Matt Emmerton From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 06:25:53 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC1D816A4CE for ; Sat, 18 Sep 2004 06:25:53 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81F3D43D1D for ; Sat, 18 Sep 2004 06:25:53 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i8I6Pejb000735; Fri, 17 Sep 2004 23:25:46 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409180625.i8I6Pejb000735@gw.catspoiler.org> Date: Fri, 17 Sep 2004 23:25:40 -0700 (PDT) From: Don Lewis To: matt@gsicomp.on.ca In-Reply-To: <006201c49d42$0c751aa0$1200a8c0@gsicomp.on.ca> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: viro@parcelfarce.linux.theplanet.co.uk cc: mwm@mired.org cc: gerarra@tin.it cc: freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 06:25:54 -0000 On 18 Sep, Matt Emmerton wrote: > > ----- Original Message ----- > From: "Mike Meyer" > To: "Matt Emmerton" > Cc: ; "Avleen Vig" > ; ; > > Sent: Saturday, September 18, 2004 1:22 AM > Subject: Re: FreeBSD Kernel buffer overflow > > >> In <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca>, Matt Emmerton > typed: >> > I disagree. It really comes down to how secure you want FreeBSD to be, > and >> > the attitude of "we don't need to protect against this case because > anyone >> > who does this is asking for trouble anyway" is one of the main reason > why >> > security holes exist in products today. (Someone else had brought this > up >> > much earlier on in the thread.) >> >> You haven't been paying close enough attention to the discussion. To >> exploit this "security problem" you have to be root. If it's an >> external attacker, you're already owned. > > I'm well aware of that fact. That's still not a reason to protect against > the problem. > > If your leaky bucket has 10 holes in it, would you at least try and plug > some of them? If an attacker is allowed to install arbitrary syscalls, he might as well install one that is easier to exploit. struct write2kernel_args { void *ubuf; void *kbuf; size_t nbyte; }; void write2kernel(td, uap) struct thread *td; struct write2kernel_args *uap; { copyin(uap->ubuf, uap->kbuf, nbyte); } From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 07:25:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 061CD16A4CE for ; Sat, 18 Sep 2004 07:25:55 +0000 (GMT) Received: from skippyii.compar.com (ns1.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AF0E43D41 for ; Sat, 18 Sep 2004 07:25:54 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [69.193.82.185])i8I7VJs9049656; Sat, 18 Sep 2004 03:31:20 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <002001c49d50$540e8a00$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: "Devon H. O'Dell" , "Mike Meyer" References: Date: Sat, 18 Sep 2004 03:22:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: viro@parcelfarce.linux.theplanet.co.uk cc: gerarra@tin.it cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 07:25:55 -0000 ----- Original Message ----- From: "Devon H. O'Dell" To: "Matt Emmerton" ; "Mike Meyer" Cc: ; ; Sent: Saturday, September 18, 2004 4:01 AM Subject: Re: FreeBSD Kernel buffer overflow > --------- Original Message -------- > From: Matt Emmerton > To: Mike Meyer > Cc: viro@parcelfarce.linux.theplanet.co.uk, gerarra@tin.it, > freebsd-hackers@freebsd.org > Subject: Re: FreeBSD Kernel buffer overflow > Date: 18/09/04 05:41 > > > > > > > ----- Original Message ----- > > From: "Mike Meyer" <mwm@mired.org> > > To: "Matt Emmerton" <matt@gsicomp.on.ca> > > Cc: <viro@parcelfarce.linux.theplanet.co.uk>; "Avleen Vig" > > <lists-freebsd@silverwraith.com>; > <freebsd-hackers@freebsd.org>; > > <gerarra@tin.it> > > Sent: Saturday, September 18, 2004 1:22 AM > > Subject: Re: FreeBSD Kernel buffer overflow > > > > > > > In <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca>, Matt > Emmerton > > <matt@gsicomp.on.ca> typed: > > > > I disagree. It really comes down to how secure you want FreeBSD > to be, > > and > > > > the attitude of "we don't need to protect against this case > because > > anyone > > > > who does this is asking for trouble anyway" is one of the > main reason > > why > > > > security holes exist in products today. (Someone else had > brought this > > up > > > > much earlier on in the thread.) > > > > > > You haven't been paying close enough attention to the discussion. To > > > exploit this "security problem" you have to be root. If > it's an > > > external attacker, you're already owned. > > > > I'm well aware of that fact. That's still not a reason to protect against > > the problem. > > > > If your leaky bucket has 10 holes in it, would you at least try and plug > > some of them? > > > > -- > > Matt Emmerton > > So should we stop the command ``shutdown -h now'' from working for root? > After all, he can DoS the system with it? > > How about this: let's disallow root from loading kernel modules! That way > this can't ever happen. > > Even better: Why don't we just not boot into a usable environment! Then we > have NO security holes. > > You guys are failing to see: ROOT HAS OMNIPOTENT POWER. SOMEBODY MUST HAVE > OMNIPOTENT POWER. THIS IS NOT A BUG. THERE IS NOTHING TO SEE HERE, MOVE ON. > > Not to be sarcastic, but you guys are missing the problem. The problem was > that someone was unaware of a kernel API. When you start programming for the > kernel, you need to make sure that the code is secure. If you think this is > a problem, take a look at init(8) and learn about securelevels. > > What happened: someone was unfamiliar with the syscall API. They crashed > their system. They screamed wildly, believing they'd found a buffer > overflow, when they'd merely overloaded the function stack and screwed up > the call. This caused the system to reboot. Solution: make it more clear > that syscalls take only 8 arguments. Make it clear that you can pass > arguments in a struct to a syscall. Make it clear that many/most syscalls do > this anyway. If there's beef on this, take it to doc@. Mike and I discussed this offline. Can someone just step up to work on and commit the KASSERT code which handles the problem and end the thread? The only reason I piped up was because nothing had been done yet, and suggested two alternate ways of hardening the system that could be enabled/disabled by the system administrator, instead of being always enabled (like a KASSERT, which always incurs a run-time check and thus could hurt performance.) -- Matt Emmerton From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 09:02:29 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25AAC16A4CE; Sat, 18 Sep 2004 09:02:29 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6EDA43D2D; Sat, 18 Sep 2004 09:02:28 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 280DEACAFE; Sat, 18 Sep 2004 11:02:27 +0200 (CEST) Date: Sat, 18 Sep 2004 11:02:27 +0200 From: Pawel Jakub Dawidek To: Giorgos Keramidas Message-ID: <20040918090227.GX30151@darkness.comp.waw.pl> References: <4146316C00007833@ims3a.cp.tin.it> <20040917093712.GB94990@orion.daedalusnetworks.priv> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j6SHqnckpA+VQtNZ" Content-Disposition: inline In-Reply-To: <20040917093712.GB94990@orion.daedalusnetworks.priv> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-hackers@freebsd.org cc: gerarra@tin.it Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 09:02:29 -0000 --j6SHqnckpA+VQtNZ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 17, 2004 at 12:37:12PM +0300, Giorgos Keramidas wrote: +> % +#ifdef INVARIANTS +> % + KASSERT(0 <=3D narg && narg <=3D 8, ("invalid number of syscal= l args")); +> % +#endif Maybe: KASSERT(0 <=3D narg && narg <=3D sizeof(args) / sizeof(args[0]), ("invalid number of syscall args")); So if we decide to increase/decrease it someday, we don't have to remember about this KASSERT(). --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --j6SHqnckpA+VQtNZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBS/mjForvXbEpPzQRAuCYAJ4hISL5xYMiDagPT4RVMBTqiif8ngCg5nhz Wu+K33ypmpSkYevUksLNXCQ= =1cXj -----END PGP SIGNATURE----- --j6SHqnckpA+VQtNZ-- From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 09:19:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1470216A4CE; Sat, 18 Sep 2004 09:19:06 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF7D743D41; Sat, 18 Sep 2004 09:19:05 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i8I9ItWl001012; Sat, 18 Sep 2004 02:18:59 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409180918.i8I9ItWl001012@gw.catspoiler.org> Date: Sat, 18 Sep 2004 02:18:55 -0700 (PDT) From: Don Lewis To: pjd@FreeBSD.org In-Reply-To: <20040918090227.GX30151@darkness.comp.waw.pl> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-hackers@FreeBSD.org cc: gerarra@tin.it cc: keramida@FreeBSD.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 09:19:06 -0000 On 18 Sep, Pawel Jakub Dawidek wrote: > On Fri, Sep 17, 2004 at 12:37:12PM +0300, Giorgos Keramidas wrote: > +> % +#ifdef INVARIANTS > +> % + KASSERT(0 <= narg && narg <= 8, ("invalid number of syscall args")); > +> % +#endif > > Maybe: > KASSERT(0 <= narg && narg <= sizeof(args) / sizeof(args[0]), > ("invalid number of syscall args")); > > So if we decide to increase/decrease it someday, we don't have to remember > about this KASSERT(). What keeps the attacker from installing two syscalls, the first of which pokes NOPs over the KASSERT code, and the second of which accepts too many arguments? If you think we really need this bit of extra security, why not just prevent the syscall with too many arguments from being registered by syscall_register()? At least that keeps the check out of the most frequently executed path. From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 09:31:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F90E16A4CF; Sat, 18 Sep 2004 09:31:14 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 146D443D46; Sat, 18 Sep 2004 09:31:14 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id F2C10ACC5F; Sat, 18 Sep 2004 11:31:12 +0200 (CEST) Date: Sat, 18 Sep 2004 11:31:12 +0200 From: Pawel Jakub Dawidek To: Don Lewis Message-ID: <20040918093112.GY30151@darkness.comp.waw.pl> References: <20040918090227.GX30151@darkness.comp.waw.pl> <200409180918.i8I9ItWl001012@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vTRmFbgCnKZxKP6J" Content-Disposition: inline In-Reply-To: <200409180918.i8I9ItWl001012@gw.catspoiler.org> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-hackers@FreeBSD.org cc: gerarra@tin.it cc: keramida@FreeBSD.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 09:31:14 -0000 --vTRmFbgCnKZxKP6J Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 18, 2004 at 02:18:55AM -0700, Don Lewis wrote: +> On 18 Sep, Pawel Jakub Dawidek wrote: +> > On Fri, Sep 17, 2004 at 12:37:12PM +0300, Giorgos Keramidas wrote: +> > +> % +#ifdef INVARIANTS +> > +> % + KASSERT(0 <=3D narg && narg <=3D 8, ("invalid number of s= yscall args")); +> > +> % +#endif +> >=20 +> > Maybe: +> > KASSERT(0 <=3D narg && narg <=3D sizeof(args) / sizeof(args[0]), +> > ("invalid number of syscall args")); +> >=20 +> > So if we decide to increase/decrease it someday, we don't have to reme= mber +> > about this KASSERT(). +>=20 +> What keeps the attacker from installing two syscalls, the first of which +> pokes NOPs over the KASSERT code, and the second of which accepts too +> many arguments? First of all, this is not protection from an attacker, but help for bad programmers. +> If you think we really need this bit of extra security, why not just +> prevent the syscall with too many arguments from being registered by +> syscall_register()? At least that keeps the check out of the most +> frequently executed path. Good point, this is much better place for it. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --vTRmFbgCnKZxKP6J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBTABgForvXbEpPzQRArg0AJ9Yzybv1ii9WvDeqaFvIWP5+/C1gACfQ0g9 jOhOseOQ8oP14LxHpVYxPeA= =pVnL -----END PGP SIGNATURE----- --vTRmFbgCnKZxKP6J-- From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 10:10:31 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1A5E16A4CE for ; Sat, 18 Sep 2004 10:10:31 +0000 (GMT) Received: from vsmtp1.tin.it (vsmtp1.tin.it [212.216.176.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DE5043D54 for ; Sat, 18 Sep 2004 10:10:14 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp1.tin.it (7.0.027) id 414B11F200042DDD for freebsd-hackers@freebsd.org; Sat, 18 Sep 2004 12:10:14 +0200 Received: from [192.168.70.181] by ims3a.cp.tin.it with HTTP; Sat, 18 Sep 2004 12:10:14 +0200 Date: Sat, 18 Sep 2004 12:10:14 +0200 Message-ID: <4146316C0000A1A7@ims3a.cp.tin.it> In-Reply-To: <006201c49d42$0c751aa0$1200a8c0@gsicomp.on.ca> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 10:10:32 -0000 >> In <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca>, Matt Emmerton > typed: >> > I disagree. It really comes down to how secure you want FreeBSD to be, >and >> > the attitude of "we don't need to protect against this case because >anyone >> > who does this is asking for trouble anyway" is one of the main reaso= n >why >> > security holes exist in products today. (Someone else had brought this >up >> > much earlier on in the thread.) >> >> You haven't been paying close enough attention to the discussion. To >> exploit this "security problem" you have to be root. If it's an >> external attacker, you're already owned. > >I'm well aware of that fact. That's still not a reason to protect again= st >the problem. > >If your leaky bucket has 10 holes in it, would you at least try and plug= >some of them? > In my post I told that this is *NOT* exploitable but if somebody finds a method? what you can say? In underground comunities it's not so rare, pat= ching is better than having a new exploits for freebsd. I was very deluded by this approach to potential security problem... (I repeat: *POTENTIAL*). rookie From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 10:21:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CCB516A4CE for ; Sat, 18 Sep 2004 10:21:47 +0000 (GMT) Received: from vsmtp3.tin.it (vsmtp3alice.tin.it [212.216.176.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id C60A143D31 for ; Sat, 18 Sep 2004 10:21:46 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp3.tin.it (7.0.027) id 414B175C00040907 for freebsd-hackers@freebsd.org; Sat, 18 Sep 2004 12:21:46 +0200 Received: from [192.168.70.181] by ims3a.cp.tin.it with HTTP; Sat, 18 Sep 2004 12:21:46 +0200 Date: Sat, 18 Sep 2004 12:21:46 +0200 Message-ID: <4146316C0000A1E3@ims3a.cp.tin.it> In-Reply-To: <20040918090227.GX30151@darkness.comp.waw.pl> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 10:21:47 -0000 >-- Messaggio originale -- >Date: Sat, 18 Sep 2004 11:02:27 +0200 >From: Pawel Jakub Dawidek >To: Giorgos Keramidas >Cc: freebsd-hackers@freebsd.org >Cc: gerarra@tin.it >Subject: Re: FreeBSD Kernel buffer overflow > > >On Fri, Sep 17, 2004 at 12:37:12PM +0300, Giorgos Keramidas wrote: >+> % +#ifdef INVARIANTS >+> % + KASSERT(0 <=3D narg && narg <=3D 8, ("invalid number of sys= call >args")); >+> % +#endif > >Maybe: >KASSERT(0 <=3D narg && narg <=3D sizeof(args) / sizeof(args[0]), > ("invalid number of syscall args")); > >So if we decide to increase/decrease it someday, we don't have to rememb= er >about this KASSERT(). Maybe better: #define ARGS_MAGIC 8 ... int args[ARGS_MAGIC]; .... #ifdef INVARIANTS KASSERT(0 <=3D narg && narg <=3D ARGS_MAGIC, ("invalid number of syscall = args")); #endif (preprocession work) rookie From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 10:24:04 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60A5A16A4CE for ; Sat, 18 Sep 2004 10:24:04 +0000 (GMT) Received: from vsmtp14.tin.it (vsmtp14.tin.it [212.216.176.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24B7443D1D for ; Sat, 18 Sep 2004 10:24:04 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp14.tin.it (7.0.027) id 414B1A580003C4BE for freebsd-hackers@freebsd.org; Sat, 18 Sep 2004 12:24:04 +0200 Received: from [192.168.70.181] by ims3a.cp.tin.it with HTTP; Sat, 18 Sep 2004 12:24:04 +0200 Date: Sat, 18 Sep 2004 12:24:04 +0200 Message-ID: <4146316C0000A1ED@ims3a.cp.tin.it> In-Reply-To: <200409180918.i8I9ItWl001012@gw.catspoiler.org> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 10:24:04 -0000 >What keeps the attacker from installing two syscalls, the first of which= >pokes NOPs over the KASSERT code, and the second of which accepts too >many arguments? > >If you think we really need this bit of extra security, why not just >prevent the syscall with too many arguments from being registered by >syscall_register()? At least that keeps the check out of the most >frequently executed path. This is not intended like a security check, just like a prevention agains= t accidental buffer overflow (like my proof of concept). This is a quite si= mple concept, take care. rookie From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 13:34:13 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA1E616A4CE for ; Sat, 18 Sep 2004 13:34:13 +0000 (GMT) Received: from vsmtp2.tin.it (vsmtp2alice.tin.it [212.216.176.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A03A43D48 for ; Sat, 18 Sep 2004 13:34:13 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp2.tin.it (7.0.027) id 414B13EE0004E624 for freebsd-hackers@freebsd.org; Sat, 18 Sep 2004 15:34:13 +0200 Received: from [192.168.70.225] by ims3a.cp.tin.it with HTTP; Sat, 18 Sep 2004 15:34:11 +0200 Date: Sat, 18 Sep 2004 15:34:11 +0200 Message-ID: <4146316C0000A4AF@ims3a.cp.tin.it> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 13:34:13 -0000 Here i report a patch different from Giorgos' one. The approch is complet= ely different: working on syscall_register() function in kern/kern_syscalls.c= file. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > cat kern_syscalls.diff --- kern_syscalls.c Sat Sep 18 14:37:53 2004 +++ kern_syscalls2.c Sat Sep 18 14:37:53 2004 @@ -73,6 +73,11 @@ sysent[*offset].sy_call !=3D (sy_call_t *= )lkmressys) return EEXIST; +#if (__i386__) && (INVARIANTS) + KASSERT(new_sysent->nargs >=3D 0 && new_sysent->nargs <=3D i386_S= YS_ARGS, + "invalid number of syscalls"); +#endif + *old_sysent =3D sysent[*offset]; sysent[*offset] =3D *new_sysent; return 0; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > cat trap.diff --- trap.c Sat Sep 18 14:38:00 2004 +++ trap2.c Sat Sep 18 14:38:00 2004 @@ -902,7 +902,7 @@ u_int sticks; int error; int narg; - int args[8]; + int args[i386_SYS_ARGS]; u_int code; /* =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > cat cdefs.diff --- cdefs.h Sat Sep 18 14:37:38 2004 +++ cdefs2.h Sat Sep 18 14:37:38 2004 @@ -467,4 +467,6 @@ #endif #endif +#define i386_SYS_ARGS 8 + #endif /* !_SYS_CDEFS_H_ */ The main improvement is that it doesn't affect handler performance (even in INVARIANTS compiled kernels) and check is done once. It could be enoug= h clear. You can download tgz in http://www.gufi.org/~rookie/args-diff.tar.= gz goodbye, rookie From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 13:41:14 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 952CE16A4CE for ; Sat, 18 Sep 2004 13:41:14 +0000 (GMT) Received: from vsmtp12.tin.it (vsmtp12.tin.it [212.216.176.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BA8543D31 for ; Sat, 18 Sep 2004 13:41:14 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp12.tin.it (7.0.027) id 414B19D30004A18E for freebsd-hackers@freebsd.org; Sat, 18 Sep 2004 15:41:14 +0200 Received: from [192.168.70.225] by ims3a.cp.tin.it with HTTP; Sat, 18 Sep 2004 15:41:14 +0200 Date: Sat, 18 Sep 2004 15:41:14 +0200 Message-ID: <4146316C0000A4CF@ims3a.cp.tin.it> In-Reply-To: <4146316C0000A4AF@ims3a.cp.tin.it> From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: RE: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 13:41:14 -0000 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > >> cat kern_syscalls.diff >--- kern_syscalls.c Sat Sep 18 14:37:53 2004 >+++ kern_syscalls2.c Sat Sep 18 14:37:53 2004 >@@ -73,6 +73,11 @@ > sysent[*offset].sy_call !=3D (sy_call_t = *)lkmressys) > return EEXIST; > >+#if (__i386__) && (INVARIANTS) >+ KASSERT(new_sysent->nargs >=3D 0 && new_sysent->nargs <=3D i386_= SYS_ARGS, >+ "invalid number of syscalls"); >+#endif >+ > *old_sysent =3D sysent[*offset]; > sysent[*offset] =3D *new_sysent; > return 0; Sorry, a little problem here. There correct text chunk: > cat kern_syscalls.diff --- kern_syscalls.c Sat Sep 18 14:37:53 2004 +++ kern_syscalls2.c Sat Sep 18 14:37:53 2004 @@ -73,6 +73,11 @@ sysent[*offset].sy_call !=3D (sy_call_t *= )lkmressys) return EEXIST; +#if (__i386__) && (INVARIANTS) + KASSERT(new_sysent->sy_nargs >=3D 0 && new_sysent->sy_nargs <=3D = i386_SYS_ARGS, + "invalid number of syscalls"); +#endif + *old_sysent =3D sysent[*offset]; sysent[*offset] =3D *new_sysent; return 0; (tgz is correct) rookie From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 13:42:18 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FD9E16A4CE for ; Sat, 18 Sep 2004 13:42:18 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8645043D49 for ; Sat, 18 Sep 2004 13:42:17 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i8IDfnmi088940; Sat, 18 Sep 2004 09:41:49 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i8IDfm2q088937; Sat, 18 Sep 2004 09:41:49 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 18 Sep 2004 09:41:48 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: gerarra@tin.it In-Reply-To: <4146316C0000A4AF@ims3a.cp.tin.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Avoiding programmer invariant violations (was: Re: FreeBSD Kernel buffer overflow) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 13:42:18 -0000 On Sat, 18 Sep 2004 gerarra@tin.it wrote: > Here i report a patch different from Giorgos' one. The approch is > completely different: working on syscall_register() function in > kern/kern_syscalls.c file. I'd suggest that we need to look at this in two ways: (1) There's a compile-time INVARIANT that needs to be maintained by developers in adding new system calls. When building the kernel, it would be useful to have a compile-time assertion that causes a kernel compile to fail if an invalid system call is defined. I.e., when init_sysent.c is generated, it should build in __CTASSERT's that all argument counts are consistent with the requirements of the hardware architecture being built for. (2) There's a run-time INVARIANT issue for loadable modules built by third parties who may not understand the limits on arguments on system calls for various architectures. This can be handled by a check in the system call registration code, although since that's a non-critical performance path, I suggest testing the invariant even if INVARIANTS isn't compiled in. In some ways, I'd rather handle this at compile-time for the module, but I think the infrastructure for hooking up system calls at compile-time for modules will make that more difficult as compared to statically compiled system calls. Note that the discussion so far has not addressed the compile-time issue: which is a much better time to perform the tests -- it's something we can test when the kernel is compiled, so why not?. It also hasn't addressed non-i386 systems, such as amd64, which have similar or identical concerns. With all due respect to the submitter, I think bugtraq was not the forum to post this issue to, as that forum is typically preferred for exploitable vulnerabilities. A follow-up post to clarify that the initial post described a possible avenue for programmer error when extending the kernel, rather than an immediately exploitable vulnerability, might reduce confusion. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 13:58:15 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76E7E16A4CE for ; Sat, 18 Sep 2004 13:58:15 +0000 (GMT) Received: from vsmtp14.tin.it (vsmtp14.tin.it [212.216.176.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32FC343D4C for ; Sat, 18 Sep 2004 13:58:15 +0000 (GMT) (envelope-from gerarra@tin.it) Received: from ims3a.cp.tin.it (192.168.70.103) by vsmtp14.tin.it (7.0.027) id 414B1A58000494F2 for freebsd-hackers@freebsd.org; Sat, 18 Sep 2004 15:58:15 +0200 Received: from [192.168.70.227] by ims3a.cp.tin.it with HTTP; Sat, 18 Sep 2004 15:58:15 +0200 Date: Sat, 18 Sep 2004 15:58:15 +0200 Message-ID: <4146316C0000A50A@ims3a.cp.tin.it> In-Reply-To: From: gerarra@tin.it To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Subject: RE: Avoiding programmer invariant violations (was: Re: FreeBSD Kernel buffer overflow) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 13:58:15 -0000 >I'd suggest that we need to look at this in two ways: > >(1) There's a compile-time INVARIANT that needs to be maintained by > developers in adding new system calls. When building the kernel, it= > would be useful to have a compile-time assertion that causes a kerne= l > compile to fail if an invalid system call is defined. I.e., when > init_sysent.c is generated, it should build in __CTASSERT's that all= > argument counts are consistent with the requirements of the hardware= > architecture being built for. > >(2) There's a run-time INVARIANT issue for loadable modules built by thi= rd > parties who may not understand the limits on arguments on system cal= ls > for various architectures. This can be handled by a check in the > system call registration code, although since that's a non-critical > performance path, I suggest testing the invariant even if INVARIANTS= > isn't compiled in. In some ways, I'd rather handle this at > compile-time for the module, but I think the infrastructure for > hooking up system calls at compile-time for modules will make that > more difficult as compared to statically compiled system calls. > Completely agree >Note that the discussion so far has not addressed the compile-time issue= : > >which is a much better time to perform the tests -- it's something we ca= n >test when the kernel is compiled, so why not?. It also hasn't addressed= >non-i386 systems, such as amd64, which have similar or identical concern= s. I was thinking exactly to it while coding patch, but I'm not so experienc= ed with SPARC and/or other architectures to do that >With all due respect to the submitter, I think bugtraq was not the forum= >to post this issue to, as that forum is typically preferred for >exploitable vulnerabilities. A follow-up post to clarify that the initi= al >post described a possible avenue for programmer error when extending the= >kernel, rather than an immediately exploitable vulnerability, might redu= ce >confusion. You're completely right again. I posted on bugtraq beacause somebody else= could get a good idea to break code, something I not thought...(so I post= this email in hackers@ to let other undestand mine wasn't a exploitable bug report; nobody told "exploitable bug user -> root" or something like that). So what we I have to do? remove INVARIANTS dependency? thanks, rookie From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 17 19:49:09 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFE3E16A4CE for ; Fri, 17 Sep 2004 19:49:08 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10C7743D3F for ; Fri, 17 Sep 2004 19:49:08 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.gr (patr530-b239.otenet.gr [212.205.244.247]) i8HJn4Qc023284; Fri, 17 Sep 2004 22:49:05 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i8HJkmGN001154; Fri, 17 Sep 2004 22:46:48 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i8HJkmNQ001153; Fri, 17 Sep 2004 22:46:48 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 17 Sep 2004 22:46:48 +0300 From: Giorgos Keramidas To: Andrew Novikov Message-ID: <20040917194648.GA1106@gothmog.gr> References: <7ea4ce2e54aa7d07618278640e7be260@200.140.233.95> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Phone: +30-2610-312145 Mobile: +30-6944-116520 X-Mailman-Approved-At: Sat, 18 Sep 2004 15:39:16 +0000 cc: freebsd-hackers@freebsd.org cc: Cantarella Subject: Re: Editing and compiling 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: Fri, 17 Sep 2004 19:49:09 -0000 On 2004-09-17 21:31, Andrew Novikov wrote: > On Tue, 14 Sep 2004 08:54:02 +0000, cantarella@senffnet.com.br wrote: > > This is my first e-mail for this list. > > I am interested in studing to better understand FreeBSD?s source code. > > With 'make buildkernel' and 'make installkernel' is it possible to > > compile the changes that I have made? > > The changes are simple (just some printf). I am just beginning this > > trip through FreeBSD?s source code. > > yes, as long as your changes were made under /usr/src/sys/ If the changes are trivial (i.e. just an extra printf() call, as suggested above) you might even get away with something faster: # cd /usr/src # make -DNOCLEAN buildkernel or even, by directly using "make" in the object directory, i.e.: # cd /usr/obj/usr/src/sys/SOLERO # make && make install Before you start taking such shortcuts though, you should definitely get acquainted with the build process of FreeBSD. The Handbook contains an entire chapter on building and installing from the sources. Please read it carefully. As many times as it takes... Regards, Giorgos From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 05:35:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DC3116A4CE for ; Sat, 18 Sep 2004 05:35:06 +0000 (GMT) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 278A143D45 for ; Sat, 18 Sep 2004 05:35:06 +0000 (GMT) (envelope-from mwm-dated-1096348930.0b5064@mired.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 09DA512A668 for ; Fri, 17 Sep 2004 22:35:06 -0700 (PDT) Received: from mired.org (mwm@idiom [216.240.32.1]) by idiom.com (8.12.11/8.12.11) with SMTP id i8I5MBwt063741 for ; Fri, 17 Sep 2004 22:22:11 -0700 (PDT) (envelope-from mwm-dated-1096348930.0b5064@mired.org) Received: (qmail 31829 invoked by uid 100); 18 Sep 2004 05:22:10 -0000 Received: by guru.mired.org (tmda-sendmail, from uid 100); Sat, 18 Sep 2004 00:22:09 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16715.50688.830652.474272@guru.mired.org> Date: Sat, 18 Sep 2004 00:22:08 -0500 To: "Matt Emmerton" In-Reply-To: <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca> References: <4146316C000077FD@ims3a.cp.tin.it> <20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk> <20040918025217.GB54961@silverwraith.com> <20040918030531.GA23987@parcelfarce.linux.theplanet.co.uk> <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca> X-Mailer: VM 7.17 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer X-Mailman-Approved-At: Sat, 18 Sep 2004 15:39:16 +0000 cc: viro@parcelfarce.linux.theplanet.co.uk cc: gerarra@tin.it cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 05:35:06 -0000 In <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca>, Matt Emmerton typed: > I disagree. It really comes down to how secure you want FreeBSD to be, and > the attitude of "we don't need to protect against this case because anyone > who does this is asking for trouble anyway" is one of the main reason why > security holes exist in products today. (Someone else had brought this up > much earlier on in the thread.) You haven't been paying close enough attention to the discussion. To exploit this "security problem" you have to be root. If it's an external attacker, you're already owned. That leaves trojans. Those are always a problem for OSS - and for proprietary software. With OSS, you have the option of auditing the code yourself, though that has been beaten (by Ritchie, I believe *). Personally, I trust the FreeBSD committers to not trojan my system - and if they were going to, there are *so* many easier ways to do it. Should I ever decide to run a third party kernel module, I may well audit the code for that module. But I take that risk everytime I install software - whether it's from ports, commercial, or just grabbed off the web. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 05:36:04 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B69516A4CE for ; Sat, 18 Sep 2004 05:36:04 +0000 (GMT) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2640943D31 for ; Sat, 18 Sep 2004 05:36:04 +0000 (GMT) (envelope-from mwm-dated-1096349461.79c5e2@mired.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 74A3A12A7BC for ; Fri, 17 Sep 2004 22:36:03 -0700 (PDT) Received: from mired.org (mwm@idiom [216.240.32.1]) by idiom.com (8.12.11/8.12.11) with SMTP id i8I5V1f7076762 for ; Fri, 17 Sep 2004 22:31:01 -0700 (PDT) (envelope-from mwm-dated-1096349461.79c5e2@mired.org) Received: (qmail 31984 invoked by uid 100); 18 Sep 2004 05:31:01 -0000 Received: by guru.mired.org (tmda-sendmail, from uid 100); Sat, 18 Sep 2004 00:31:00 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16715.51219.709030.281400@guru.mired.org> Date: Sat, 18 Sep 2004 00:30:59 -0500 To: Cantarella In-Reply-To: <7ea4ce2e54aa7d07618278640e7be260@200.140.233.95> References: <7ea4ce2e54aa7d07618278640e7be260@200.140.233.95> X-Mailer: VM 7.17 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer X-Mailman-Approved-At: Sat, 18 Sep 2004 15:39:16 +0000 cc: freebsd-hackers@freebsd.org Subject: Re: Editing and compiling 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: Sat, 18 Sep 2004 05:36:04 -0000 In <7ea4ce2e54aa7d07618278640e7be260@200.140.233.95>, Cantarella typed: >=20 > This is my first e-mail for this list. > I am interested in studing to better understand FreeBSD=B4s source= code. > With 'make buildkernel' and 'make installkernel' is it possible to= > compile the changes that I have made? > The changes are simple (just some printf). I am just beginning thi= s > trip through FreeBSD=B4s source code. That will work, but it's the painfull way to do it. The old way is easier to do development with: 1) cd /usr/src/sys/i386/conf 2) config YOURCONFIG 3) cd ../../compile/YOURCONFIG 4) make depend 5) make install You only have to go back to step 1 if you touch the config file. You only have to go back to step 4 if you add #include statements to a source file. Most of the time, you simply redo the "make install", and it only recompiles what you've changed and relinks the kernel. buildkernel and installkernel will recompile everything every time. This won't remake kernel modules - but you can do "make's" in /usr/src/sys/modules/* to deal with those. =09=09=09http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more informatio= n. From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 05:58:04 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED15016A4CE for ; Sat, 18 Sep 2004 05:58:04 +0000 (GMT) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF4CA43D41 for ; Sat, 18 Sep 2004 05:58:04 +0000 (GMT) (envelope-from mwm-dated-1096350585.3c22e6@mired.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id 55E4212A785 for ; Fri, 17 Sep 2004 22:58:04 -0700 (PDT) Received: from mired.org (mwm@idiom [216.240.32.1]) by idiom.com (8.12.11/8.12.11) with SMTP id i8I5nj5q008782 for ; Fri, 17 Sep 2004 22:49:46 -0700 (PDT) (envelope-from mwm-dated-1096350585.3c22e6@mired.org) Received: (qmail 32941 invoked by uid 100); 18 Sep 2004 05:49:45 -0000 Received: by guru.mired.org (tmda-sendmail, from uid 100); Sat, 18 Sep 2004 00:49:44 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16715.52344.47229.746257@guru.mired.org> Date: Sat, 18 Sep 2004 00:49:44 -0500 To: "Matt Emmerton" In-Reply-To: <006201c49d42$0c751aa0$1200a8c0@gsicomp.on.ca> References: <4146316C000077FD@ims3a.cp.tin.it> <20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk> <20040918025217.GB54961@silverwraith.com> <20040918030531.GA23987@parcelfarce.linux.theplanet.co.uk> <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca> <16715.50688.830652.474272@guru.mired.org> <006201c49d42$0c751aa0$1200a8c0@gsicomp.on.ca> X-Mailer: VM 7.17 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer X-Mailman-Approved-At: Sat, 18 Sep 2004 15:39:16 +0000 cc: viro@parcelfarce.linux.theplanet.co.uk cc: gerarra@tin.it cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 05:58:05 -0000 In <006201c49d42$0c751aa0$1200a8c0@gsicomp.on.ca>, Matt Emmerton typed: > ----- Original Message ----- > From: "Mike Meyer" > To: "Matt Emmerton" > Cc: ; "Avleen Vig" > ; ; > > Sent: Saturday, September 18, 2004 1:22 AM > Subject: Re: FreeBSD Kernel buffer overflow > > > > In <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca>, Matt Emmerton > typed: > > > I disagree. It really comes down to how secure you want FreeBSD to be, > and > > > the attitude of "we don't need to protect against this case because > anyone > > > who does this is asking for trouble anyway" is one of the main reason > why > > > security holes exist in products today. (Someone else had brought this > up > > > much earlier on in the thread.) > > > > You haven't been paying close enough attention to the discussion. To > > exploit this "security problem" you have to be root. If it's an > > external attacker, you're already owned. > > I'm well aware of that fact. That's still not a reason to protect against > the problem. > > If your leaky bucket has 10 holes in it, would you at least try and plug > some of them? In this case, you're trying to plug holes in a bucket that doesn't have a bottom. Not only that - once you fix the bottom, the holes will be fixed as well. If this qualifies as a security hole, then so does /bin/sh being executable by root. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 06:04:42 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE93216A4CE for ; Sat, 18 Sep 2004 06:04:42 +0000 (GMT) Received: from smp500.sitetronics.com (sitetronics.com [82.192.77.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C75443D1D for ; Sat, 18 Sep 2004 06:04:42 +0000 (GMT) (envelope-from dodell@sitetronics.com) Received: from [127.0.0.1] (helo=UebiMiau) by smp500.sitetronics.com with asmtp (Exim 4.24) id 1C8YII-000AGa-OV; Sat, 18 Sep 2004 08:01:58 +0200 Received: from client 82.161.57.57 for UebiMiau2.7 (webmail client); Sat, 18 Sep 2004 8:01:58 -0000 Date: Sat, 18 Sep 2004 8:01:58 -0000 From: "Devon H. O'Dell" To: "Matt Emmerton" , "Mike Meyer" X-Priority: 3 X-Mailer: UebiMiau 2.7.2 X-Original-IP: 82.161.57.57 Content-Transfer-Encoding: 8bit X-MSMail-Priority: Medium Importance: Medium Content-Type: text/plain; charset="iso-8859-1"; MIME-Version: 1.0 Message-Id: X-Mailman-Approved-At: Sat, 18 Sep 2004 15:39:16 +0000 cc: viro@parcelfarce.linux.theplanet.co.uk cc: "freebsd-hackers@freebsd.org"@FreeBSD.ORG cc: "gerarra@tin.it"@FreeBSD.ORG Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Devon H. O'Dell" List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 06:04:42 -0000 --------- Original Message -------- From: Matt Emmerton To: Mike Meyer Cc: viro@parcelfarce.linux.theplanet.co.uk, gerarra@tin.it, freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow Date: 18/09/04 05:41 > > > ----- Original Message ----- > From: "Mike Meyer" <mwm@mired.org> > To: "Matt Emmerton" <matt@gsicomp.on.ca> > Cc: <viro@parcelfarce.linux.theplanet.co.uk>; "Avleen Vig" > <lists-freebsd@silverwraith.com>; <freebsd-hackers@freebsd.org>; > <gerarra@tin.it> > Sent: Saturday, September 18, 2004 1:22 AM > Subject: Re: FreeBSD Kernel buffer overflow > > > > In <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca>, Matt Emmerton > <matt@gsicomp.on.ca> typed: > > > I disagree. It really comes down to how secure you want FreeBSD to be, > and > > > the attitude of "we don't need to protect against this case because > anyone > > > who does this is asking for trouble anyway" is one of the main reason > why > > > security holes exist in products today. (Someone else had brought this > up > > > much earlier on in the thread.) > > > > You haven't been paying close enough attention to the discussion. To > > exploit this "security problem" you have to be root. If it's an > > external attacker, you're already owned. > > I'm well aware of that fact. That's still not a reason to protect against > the problem. > > If your leaky bucket has 10 holes in it, would you at least try and plug > some of them? > > -- > Matt Emmerton So should we stop the command ``shutdown -h now'' from working for root? After all, he can DoS the system with it? How about this: let's disallow root from loading kernel modules! That way this can't ever happen. Even better: Why don't we just not boot into a usable environment! Then we have NO security holes. You guys are failing to see: ROOT HAS OMNIPOTENT POWER. SOMEBODY MUST HAVE OMNIPOTENT POWER. THIS IS NOT A BUG. THERE IS NOTHING TO SEE HERE, MOVE ON. Not to be sarcastic, but you guys are missing the problem. The problem was that someone was unaware of a kernel API. When you start programming for the kernel, you need to make sure that the code is secure. If you think this is a problem, take a look at init(8) and learn about securelevels. What happened: someone was unfamiliar with the syscall API. They crashed their system. They screamed wildly, believing they'd found a buffer overflow, when they'd merely overloaded the function stack and screwed up the call. This caused the system to reboot. Solution: make it more clear that syscalls take only 8 arguments. Make it clear that you can pass arguments in a struct to a syscall. Make it clear that many/most syscalls do this anyway. If there's beef on this, take it to doc@. --Devon From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 18:08:48 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B06516A4CE for ; Sat, 18 Sep 2004 18:08:48 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id F25AE43D31 for ; Sat, 18 Sep 2004 18:08:47 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i8II8doH002297; Sat, 18 Sep 2004 11:08:44 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409181808.i8II8doH002297@gw.catspoiler.org> Date: Sat, 18 Sep 2004 11:08:39 -0700 (PDT) From: Don Lewis To: gerarra@tin.it In-Reply-To: <4146316C0000A4AF@ims3a.cp.tin.it> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 18:08:48 -0000 On 18 Sep, gerarra@tin.it wrote: > Here i report a patch different from Giorgos' one. The approch is completely > different: working on syscall_register() function in kern/kern_syscalls.c > file. > > ============================== > >> cat kern_syscalls.diff > --- kern_syscalls.c Sat Sep 18 14:37:53 2004 > +++ kern_syscalls2.c Sat Sep 18 14:37:53 2004 > @@ -73,6 +73,11 @@ > sysent[*offset].sy_call != (sy_call_t *)lkmressys) > return EEXIST; > > +#if (__i386__) && (INVARIANTS) > + KASSERT(new_sysent->nargs >= 0 && new_sysent->nargs <= i386_SYS_ARGS, > + "invalid number of syscalls"); > +#endif > + > *old_sysent = sysent[*offset]; > sysent[*offset] = *new_sysent; > return 0; Why panic the machine at this point? Just refuse to install the syscall and return an error. From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 19:18:27 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DCF316A4CE for ; Sat, 18 Sep 2004 19:18:27 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id CD52E43D31 for ; Sat, 18 Sep 2004 19:18:23 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 17443 invoked by uid 0); 18 Sep 2004 19:14:36 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.98.7) by mail.freebsd.org.cn with SMTP; 18 Sep 2004 19:14:36 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id AD8A01322A6; Sun, 19 Sep 2004 03:18:20 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02213-03; Sun, 19 Sep 2004 03:18:15 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id B8EFF130E15; Sun, 19 Sep 2004 03:18:14 +0800 (CST) Date: Sun, 19 Sep 2004 03:18:14 +0800 From: Xin LI To: gerarra@tin.it Message-ID: <20040918191814.GA3716@frontfree.net> References: <006201c49d42$0c751aa0$1200a8c0@gsicomp.on.ca> <4146316C0000A1A7@ims3a.cp.tin.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <4146316C0000A1A7@ims3a.cp.tin.it> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.3-delphij FreeBSD 5.3-delphij #4: Mon Sep 13 12:44:05 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.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, 18 Sep 2004 19:18:27 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 18, 2004 at 12:10:14PM +0200, gerarra@tin.it wrote: >=20 > In my post I told that this is *NOT* exploitable but if somebody finds a > method? what you can say? In underground comunities it's not so rare, pat= ching > is better than having a new exploits for freebsd. I was very deluded by > this approach to potential security problem... > (I repeat: *POTENTIAL*). You have some different idea from ours. However, I think it might be useful to clarify our idea. 1. A kernel must trust itself in order for it to be efficient. It is not bad to have sanity checks, but checking it repeatly will pose a performance pain. With this in mind, the correct approach might be to have sanity check in the entry point, rather than having it everywhere. This is say, a input procedure must have everything in a sanity state in its early stage and, in addition, same check should not be done in elsewhere because it just repeatly check what is guaranteed to be true, in a production kernel this is not quite useful and even in a debug kernel it is not perferred approach because we don't have to explicitly have if(1=3D=3D1) or something like this. 2. As many people in this discussion has pointed out, it is necessary to have root access in order to alter a system call. That is say, that in order to successfully exploit this "vulnerablity" you have to be root first, and we have infinite "exploits" in this situation, because the attacker already got the ultimate power. We don't need to fear someone who already killed us, right? 3. Security is determined by the weakest tach. With this in concern, let's think about the following scenario: Every system calls have correct sanity check in their entry point while foo() have not. Someone has injected foo() with another way to have some code in kernel. The kernel code exploited the issue you mentioned. But is it actually wrong with the issue? Isn't it the weakest tach within the foo() system call? Shouldn't it be fixed? Hope this is helpful for the debate, and hope I have expressed my idea correctly. With these consideration, I think it is not very necessary to have the sanity check of parameter numbers for a system call entry because it need root access already and if the gain of root is considered harmful, then it's not the sanity of parameter numbers check but the actual problem should be fixed.=20 Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBTIn2/cVsHxFZiIoRAo5OAJ9B/m04M0U0yNniCySmfFX623HpygCdE0Gl z4l9EdaFv56bvGSN3mGIoHo= =fP2n -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS--