From owner-freebsd-arch Sun Oct 17 3:24:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0A03D1506F for ; Sun, 17 Oct 1999 03:24:12 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA00611 for ; Sun, 17 Oct 1999 12:24:10 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA67917 for freebsd-arch@freebsd.org; Sun, 17 Oct 1999 12:24:09 +0200 (MET DST) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 9CAD41506F for ; Sun, 17 Oct 1999 03:23:54 -0700 (PDT) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id LAA85069 for arch@FreeBSD.org; Sun, 17 Oct 1999 11:54:30 +0200 (CEST) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Sun, 17 Oct 1999 11:54:19 +0200 From: Marcel Moolenaar Message-ID: <38099CCB.99EE1C97@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3808BC30.2699465B@scc.nl>, <199910162136.PAA01266@harmony.village.org> Subject: Re: make world issues Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [taken of -arch] Warner Losh wrote: > Personally, I would have included backward compatibiltiy shims in libc > for the signal stuff for a while, but that appears to have been hard > to do... The problem I have with such a workaround (in general) is that it is difficult (in general) to know when you can remove the shims. Adding the shims is not the real problem. When the shims are there, they are either forgotten or alternatively, removing them starts long-threaded discussions which end up with the shims being kept because the persons in favor of removing them are generally less fanatical than the persons who are against its removal. When the shims are there long enough, no active developer knows why they are there in the first place and also decides to keep them because he/she fears world breakage and/or backward compatibility breakage. In the mean time other shims can be created with the workaround as precedent. Before you know it everybody is using shims without actually knowing why and you end up with a bloated set of libraries that, because of the shims and other compatibility stuff, are hard to maintain and bug-sensitive. Reverting such a situation is always more difficult than preventing it. In short: lot's of speculation :-) -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 17 11:59:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4F39514E57 for ; Sun, 17 Oct 1999 11:59:16 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA03716 for ; Sun, 17 Oct 1999 20:59:15 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA69192 for freebsd-arch@freebsd.org; Sun, 17 Oct 1999 20:59:14 +0200 (MET DST) Received: from dt050n71.san.rr.com (dt050n71.san.rr.com [204.210.31.113]) by hub.freebsd.org (Postfix) with ESMTP id 8225C14E57 for ; Sun, 17 Oct 1999 11:59:07 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt050n71.san.rr.com (8.9.3/8.8.8) with ESMTP id LAA09781; Sun, 17 Oct 1999 11:58:48 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <380A1C68.BF17ED9F@gorean.org> Date: Sun, 17 Oct 1999 11:58:48 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT-0927 i386) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar Cc: arch@freebsd.org Subject: Re: make world issues References: <3808BC30.2699465B@scc.nl>, <199910162136.PAA01266@harmony.village.org> <38099CCB.99EE1C97@scc.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marcel Moolenaar wrote: > > [taken of -arch] > > Warner Losh wrote: > > > Personally, I would have included backward compatibiltiy shims in libc > > for the signal stuff for a while, but that appears to have been hard > > to do... > > The problem I have with such a workaround (in general) is that it is > difficult (in general) to know when you can remove the shims. The simple solution for that problem was already suggested by someone else, but may have been lost in the noise. You require a define to incorporate the shims. Make the define a stock part of the "make upgrade," or whatever we want to call it from 2.2.x/3.x to 4.x, and put it in UPDATING so that -current -> later -current upgraders can also use it. While they're there they're harmless, and/or necessary, and once your system is all upgraded they go away on the next kernel rebuild. With proper comments in the code as to what they are there for, and a recommended time of nuking (say, one year after 4.0-Release) all of the admittedly possible scenarios you mention vanish. I've done exactly this on some other projects I've worked on and never had a problem with it. Doug -- "Stop it, I'm gettin' misty." - Mel Gibson as Porter, "Payback" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Oct 17 12:16:51 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4DB6D1504C for ; Sun, 17 Oct 1999 12:16:36 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA03830 for ; Sun, 17 Oct 1999 21:16:36 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA69268 for freebsd-arch@freebsd.org; Sun, 17 Oct 1999 21:16:35 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2156A14BD3 for ; Sun, 17 Oct 1999 12:16:27 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA03441; Sun, 17 Oct 1999 13:16:25 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA04821; Sun, 17 Oct 1999 13:16:02 -0600 (MDT) Message-Id: <199910171916.NAA04821@harmony.village.org> To: Doug Subject: Re: make world issues Cc: Marcel Moolenaar , arch@freebsd.org In-reply-to: Your message of "Sun, 17 Oct 1999 11:58:48 PDT." <380A1C68.BF17ED9F@gorean.org> References: <380A1C68.BF17ED9F@gorean.org> <3808BC30.2699465B@scc.nl>, <199910162136.PAA01266@harmony.village.org> <38099CCB.99EE1C97@scc.nl> Date: Sun, 17 Oct 1999 13:16:01 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <380A1C68.BF17ED9F@gorean.org> Doug writes: : The simple solution for that problem was already suggested by someone : else, but may have been lost in the noise. You require a define to : incorporate the shims. Make the define a stock part of the "make : upgrade," or whatever we want to call it from 2.2.x/3.x to 4.x, and put : it in UPDATING so that -current -> later -current upgraders can also use : it. While they're there they're harmless, and/or necessary, and once : your system is all upgraded they go away on the next kernel rebuild. I like this. It can even be completely automated. It is a big PITA to have to rebuild a kernel before building world. : With proper comments in the code as to what they are there for, and a : recommended time of nuking (say, one year after 4.0-Release) all of the : admittedly possible scenarios you mention vanish. I've done exactly this : on some other projects I've worked on and never had a problem with it. In a past live, I've shot obsolete APIs in the head with what in FreeBSD would be expressed as #include /* * Allow osignal stuff until FreeBSD 5, which will be one major * release after they are added. */ #if __FreeBSD_version < 500000 extern int osignalbaz(int, ...); #else #error Please delete stale code. #endif This automatically kills osignalbaz when FreeBSD 5 is created and also tells the reader that this was explicitly limited to version < 5. The comments add to this and tell why the magic number 5 was picked. We've never really supported going from major release n to n + 2 in one step, although that has worked from 1.x -> 3.early. I'm not sure that it will still work, however. Combining this technique with the one above would ensure that the code disappears in the future. When the OI library had an API that went out of use, we deleted the code. When I was doing things on the OI library, I didn't use the #else clause above, that just occuring to me as I'm tying here. The argument that shims are evil and will last forever is one of ignorance of techniques to automatically kill them in the future. It is my perception of setting on the sidelines that each time Marcel has been given brief and a simple solution he's come up with a different excuse about why he hasn't provided backwards compatibility. It would be more honest to just say "I don't want to provide backwards compatibility, so you are SOL unless you or someone else wants to do it." There is precidence for this (witness CAM, which even change device names), but what I see as a constantly changing excuse rubs me the wrong way. I believe this will cause the problem to fester rather than being dealt with, imho. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 2: 9:53 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A8EF114D10 for ; Mon, 18 Oct 1999 02:09:46 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA14698 for ; Mon, 18 Oct 1999 11:09:44 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA75837 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 11:09:38 +0200 (MET DST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B6EFC14BC3; Mon, 18 Oct 1999 02:09:23 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA43443; Mon, 18 Oct 1999 11:09:10 +0200 (CEST) (envelope-from des) To: Justin Wells Cc: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> From: Dag-Erling Smorgrav Date: 18 Oct 1999 11:09:09 +0200 In-Reply-To: Dag-Erling Smorgrav's message of "18 Oct 1999 10:56:51 +0200" Message-ID: Lines: 28 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > I'm starting to think that secure levels should be implemented as > bitmasks, with one bit for each operation or group of operation to be > allowed or denied (0 = allow, 1 = deny). The if statement above could > be rewritten as: > > if (securemask & SEC_MOUNT) > return (EPERM); > > Using a simple bitmask might be too simple though (it would restrict > us to 32 or 64 distinct operations), so we might want to hide the > actual implementation behind a function call or macro: > > if (!sec_permitted(SEC_MOUNT)) > return (EPERM); I'm thinking this might be -arch material. Do we want to do this? I think it can be done rather painlessly, and backwards compatibility with kern.securelevel should be easy to provide. The same mechanism can be used to implement process- or user-level capabilities, maybe leading us to merge (the hypothetical) sec_permitted() with suser(). After all, they're just two different ways of asking "is this ol' joe even *allowed* to do this?" DES (patches... must... write... patches...) -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 3:31:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9022814BCF for ; Mon, 18 Oct 1999 03:31:14 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA15969 for ; Mon, 18 Oct 1999 12:31:13 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA76232 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 12:31:11 +0200 (MET DST) Received: from fticom.dipt.donetsk.ua (fticom.dipt.donetsk.ua [194.44.136.12]) by hub.freebsd.org (Postfix) with ESMTP id AA5CB14BCF for ; Mon, 18 Oct 1999 03:30:55 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from tkito.dipt.donetsk.ua (tkito.dipt.donetsk.ua [195.184.193.193]) by fticom.dipt.donetsk.ua with SMTP id NAA20521; Mon, 18 Oct 1999 13:30:52 +0300 (EEST) Received: (qmail 8297 invoked by uid 0); 18 Oct 1999 10:33:46 -0000 Received: from koi.pop.donbass.net by localhost with POP3 (fetchmail-5.0.0) for oleg@localhost (multi-drop); Mon, 18 Oct 1999 13:33:46 +0300 (EEST) Received: from hub.freebsd.org (hub.FreeBSD.ORG [204.216.27.18]) by fticom.dipt.donetsk.ua with ESMTP id MAA16338; Mon, 18 Oct 1999 12:10:43 +0300 (EEST) Received: by hub.freebsd.org (Postfix, from userid 538) id BBD0E14CB5; Mon, 18 Oct 1999 02:09:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 693F21CD472; Mon, 18 Oct 1999 02:09:28 -0700 (PDT) (envelope-from owner-freebsd-security) Received: by hub.freebsd.org (bulk_mailer v1.12); Mon, 18 Oct 1999 02:09:28 -0700 Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id B6EFC14BC3; Mon, 18 Oct 1999 02:09:23 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA43443; Mon, 18 Oct 1999 11:09:10 +0200 (CEST) (envelope-from des) To: Justin Wells Cc: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> From: Dag-Erling Smorgrav Date: 18 Oct 1999 11:09:09 +0200 In-Reply-To: Dag-Erling Smorgrav's message of "18 Oct 1999 10:56:51 +0200" Message-ID: Lines: 28 X-Mailer: Gnus v5.7/Emacs 20.4 X-Loop: FreeBSD.org X-UIDL: f922d3e8b4e6bbb238663dff175180f9 X-Fetchmail-Warning: recipient address freebsd-security@freebsd.org didn't match any local name Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav writes: > I'm starting to think that secure levels should be implemented as > bitmasks, with one bit for each operation or group of operation to be > allowed or denied (0 = allow, 1 = deny). The if statement above could > be rewritten as: > > if (securemask & SEC_MOUNT) > return (EPERM); > > Using a simple bitmask might be too simple though (it would restrict > us to 32 or 64 distinct operations), so we might want to hide the > actual implementation behind a function call or macro: > > if (!sec_permitted(SEC_MOUNT)) > return (EPERM); I'm thinking this might be -arch material. Do we want to do this? I think it can be done rather painlessly, and backwards compatibility with kern.securelevel should be easy to provide. The same mechanism can be used to implement process- or user-level capabilities, maybe leading us to merge (the hypothetical) sec_permitted() with suser(). After all, they're just two different ways of asking "is this ol' joe even *allowed* to do this?" DES (patches... must... write... patches...) -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 7:27:21 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BDEC914DE3 for ; Mon, 18 Oct 1999 07:27:15 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA23163 for ; Mon, 18 Oct 1999 16:27:15 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA77657 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 16:27:15 +0200 (MET DST) Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id 0B7981516B for ; Mon, 18 Oct 1999 07:26:34 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from bone.nectar.com (bone.nectar.com [10.0.0.105]) by gw.nectar.com (Postfix) with ESMTP id 492BDC008 for ; Mon, 18 Oct 1999 09:26:29 -0500 (CDT) Received: from bone.nectar.com (localhost [127.0.0.1]) by bone.nectar.com (Postfix) with ESMTP id D1DDB1DA3 for ; Mon, 18 Oct 1999 09:26:33 -0500 (CDT) X-Mailer: exmh version 2.1.0 09/18/1999 X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-rsa.txt X-PGP-DSSfprint: AB2F 8D71 A4F4 467D 352E 8A41 5D79 22E4 71A2 8C73 X-PGP-DHfprint: 2D50 12E5 AB38 60BA AF4B 0778 7242 4460 1C32 F6B1 X-PGP-DH-DSSkey: http://www.nectar.com/nectar-dh-dss.txt From: Jacques Vidrine To: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X In-reply-to: References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Oct 1999 09:26:33 -0500 Message-Id: <19991018142633.D1DDB1DA3@bone.nectar.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [I meant for this to go to -arch instead of -security] On 18 October 1999 at 10:56, Dag-Erling Smorgrav wrote: [snip] > I'm starting to think that secure levels should be implemented as > bitmasks, with one bit for each operation or group of operation to be > allowed or denied (0 = allow, 1 = deny). The if statement above could > be rewritten as: > > if (securemask & SEC_MOUNT) > return (EPERM); > > Using a simple bitmask might be too simple though (it would restrict > us to 32 or 64 distinct operations), so we might want to hide the > actual implementation behind a function call or macro: > > if (!sec_permitted(SEC_MOUNT)) > return (EPERM); I've been thinking about something similar for suser, so that all uses of superuser privileges can be audited. For example, some hypothetical suser2 API that takes as one argument a constant specifying the category: int setuid(...) { ... error = suser2(p, SUSER_CREDS) ... } only for this to be truly useful, all calls to suser would have to be changed to suser2. This is the same kind of thing that DES is demonstrating above with the hypothetical sec_permitted. Chatting with DES on IRC, it seems to me that all this stuff (jail, auditing, securelevel) needs to fit together. Further, I feel like most (all) calls to suser or what have you in the top of the kernel could be covered if we made the granularity == syscall. This would break some abstraction, but if our hypothetical new suser or sec_permitted ``knew'' it was being called in the top of the kernel and ``knew'' what the current syscall was, our operations could just be table lookups. And especially for suser, we could tweak securelevel and jail stuff without having to modify the call to suser. -- Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 7:50:10 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 18CAE14BDD for ; Mon, 18 Oct 1999 07:50:07 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA23649 for ; Mon, 18 Oct 1999 16:50:06 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA77798 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 16:50:06 +0200 (MET DST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5BBBD14BC2 for ; Mon, 18 Oct 1999 07:49:14 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA44341; Mon, 18 Oct 1999 16:49:01 +0200 (CEST) (envelope-from des) To: Jacques Vidrine Cc: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> <19991018142633.D1DDB1DA3@bone.nectar.com> From: Dag-Erling Smorgrav Date: 18 Oct 1999 16:49:00 +0200 In-Reply-To: Jacques Vidrine's message of "Mon, 18 Oct 1999 09:26:33 -0500" Message-ID: Lines: 52 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jacques Vidrine writes: > Further, I feel like most (all) calls to suser or what have you in > the top of the kernel could be covered if we made the granularity == > syscall. This would break some abstraction, but if our hypothetical > new suser or sec_permitted ``knew'' it was being called in the top of > the kernel and ``knew'' what the current syscall was, our operations > could just be table lookups. And especially for suser, we could > tweak securelevel and jail stuff without having to modify the call > to suser. With all due respect, *yuck* :) What EE suggested was to define a new SYSCTL macro to make defining new security sysctls trivial. You'd do something like this: static int sec_syscall_mount = 1; SYSCTL_SECURITY(mount, &sec_syscall_mount, "Allow mounting filesystems"); int mount(p, uap) /* ... */ { /* ... */ if (usermount == 0 && (error = suser(p))) return (error); if (sec_syscall_mount) return (EPERM); /* ... */ } This is *very* rough; I don't think I'd actually use an explicitly defined int like above; I'd rather use some kind of automagically- defined symbolic constant and a function call / macro for checking if it's set or not. This demonstrates the general idea, though; the rest is implementation details :) The sysctl knob would be named ``kern.security.mount'' or something, and be one-way; its initial value would be 1, and you'd be allowed to set it to 0 but not set it back to 1. The current sysctl_kern_securelevel() would be rewritten to twiddle the appropriate knobs, so that setting kern.securelevel would still have the expected effect. Going the other way (translating security settings into a meaningful kern.securelevel value) is not as trivial, though, so userland programs which rely on *checking* the value of kern.securelevel (as oppsoed to just *setting* it) may break. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 8:22: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 36A9D14BF9 for ; Mon, 18 Oct 1999 08:22:00 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA24093 for ; Mon, 18 Oct 1999 17:21:59 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA78024 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 17:21:58 +0200 (MET DST) Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id C940814BF9 for ; Mon, 18 Oct 1999 08:21:49 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from bone.nectar.com (bone.nectar.com [10.0.0.105]) by gw.nectar.com (Postfix) with ESMTP id 8E281C008; Mon, 18 Oct 1999 10:21:43 -0500 (CDT) Received: from bone.nectar.com (localhost [127.0.0.1]) by bone.nectar.com (Postfix) with ESMTP id 609F71DA3; Mon, 18 Oct 1999 10:21:47 -0500 (CDT) X-Mailer: exmh version 2.1.0 09/18/1999 X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-rsa.txt X-PGP-DSSfprint: AB2F 8D71 A4F4 467D 352E 8A41 5D79 22E4 71A2 8C73 X-PGP-DHfprint: 2D50 12E5 AB38 60BA AF4B 0778 7242 4460 1C32 F6B1 X-PGP-DH-DSSkey: http://www.nectar.com/nectar-dh-dss.txt From: Jacques Vidrine To: Dag-Erling Smorgrav Cc: freebsd-arch@freebsd.org In-reply-to: References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> <19991018142633.D1DDB1DA3@bone.nectar.com> Subject: Re: kern.securelevel and X Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Oct 1999 10:21:47 -0500 Message-Id: <19991018152147.609F71DA3@bone.nectar.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18 October 1999 at 16:49, Dag-Erling Smorgrav wrote: > With all due respect, *yuck* :) Well I expected gagging, but I thought there might be some details :-) > What EE suggested was to define a new SYSCTL macro to make defining > new security sysctls trivial. You'd do something like this: [snip] That's fine for system-wide stuff, but I'd like to see the ability to tweak this same stuff per-process. I see a system-wide data structure to hold this type of configuration information. Each process should also have a pointer to the system-wide structure (or NULL) that can be overridden by a system call such as jail. Or we could hang this stuff off of the jail structure or something like it. Sorry this is so rough. I've got to fly. -- Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 8:29:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 524D614E57 for ; Mon, 18 Oct 1999 08:29:51 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA24156 for ; Mon, 18 Oct 1999 17:29:50 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA78076 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 17:29:50 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 99CDA14E40 for ; Mon, 18 Oct 1999 08:29:12 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id JAA05938 for ; Mon, 18 Oct 1999 09:29:11 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id JAA04506 for ; Mon, 18 Oct 1999 09:28:43 -0600 (MDT) Message-Id: <199910181528.JAA04506@harmony.village.org> To: arch@freebsd.org Subject: re: make world issues Date: Mon, 18 Oct 1999 09:28:43 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ufff. I just re-read my last message where I was overly harsh to Marcel about his new signal scheme. I overreacted to what he said and, for various personal reasons, didn't exercise proper judgement about what I was sending out. I would like to appologize publicly to Marcel right now for catching the brunt of my frustration with other things in my life right now. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 9:31:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7274614D50 for ; Mon, 18 Oct 1999 09:31:13 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA24860 for ; Mon, 18 Oct 1999 18:30:42 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA78346 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 18:30:41 +0200 (MET DST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 98D5B14E57 for ; Mon, 18 Oct 1999 09:30:26 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id SAA44692; Mon, 18 Oct 1999 18:30:21 +0200 (CEST) (envelope-from des) To: Jacques Vidrine Cc: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> <19991018142633.D1DDB1DA3@bone.nectar.com> <19991018152147.609F71DA3@bone.nectar.com> From: Dag-Erling Smorgrav Date: 18 Oct 1999 18:30:20 +0200 In-Reply-To: Jacques Vidrine's message of "Mon, 18 Oct 1999 10:21:47 -0500" Message-ID: Lines: 41 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jacques Vidrine writes: > On 18 October 1999 at 16:49, Dag-Erling Smorgrav wrote: > > What EE suggested was to define a new SYSCTL macro to make defining > > new security sysctls trivial. You'd do something like this: > [snip] > That's fine for system-wide stuff, but I'd like to see the ability > to tweak this same stuff per-process. Yes, I was coming to that 8) > I see a system-wide data > structure to hold this type of configuration information. Each process > should also have a pointer to the system-wide structure (or NULL) that > can be overridden by a system call such as jail. Or we could hang > this stuff off of the jail structure or something like it. Why are you so obsessed with jail(2)? There is no reason for this to be jail(2)-specific. As I told you on IRC: 03:21 #bsdcode Nectar> DES: securelevel == systemwide, jail == process based 03:22 #bsdcode ---------> nectar: no, you're not ambitious enough 8) What you want is process-level capabilities, which are inherited from parent to child. Init(8) starts out with all capabilities enabled; its child processes can then give up capabilities they do not need, but never gain any back. User-level capabilities can be implemented with relative ease by modifying setusercontext() et al. to tune capabilities according to login.conf. This is not entirely trivial to implement; one has to be very careful not to open huge security holes (by not revoking capabilities when one should). The safest path is probably to introduce a new syscall, e.g. setuid2(), which preserves capabilities, and have the legacy setuid() revoke *all* capabilities, so that programs which rely on setuid() to drop privileges will not suddenly become security liabilities. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 9:51:45 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B278714BC5 for ; Mon, 18 Oct 1999 09:51:39 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA25164 for ; Mon, 18 Oct 1999 18:51:37 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA78462 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 18:51:37 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id ECE1F15143 for ; Mon, 18 Oct 1999 09:50:12 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id JAA12439; Mon, 18 Oct 1999 09:50:06 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpdAAAqoaymy; Mon Oct 18 09:50:03 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id JAA01262; Mon, 18 Oct 1999 09:49:55 -0700 (MST) From: Terry Lambert Message-Id: <199910181649.JAA01262@usr07.primenet.com> Subject: Re: make world issues To: marcel@scc.nl (Marcel Moolenaar) Date: Mon, 18 Oct 1999 16:49:55 +0000 (GMT) Cc: arch@freebsd.org In-Reply-To: <38086629.848BC1BF@scc.nl> from "Marcel Moolenaar" at Oct 16, 99 01:48:57 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If you make a change (like the signal changes) > > that isn't backward compatible, then you can't bootstrap properly > > because you can't execute what you build. > > You said a couple of lines above: > > \begin{quote} > > Because when cross-compiling, you don't execute anything that you > > build for the target system. > \end{quote} > > I don't have anything to add to that :-) You can't cross-compile a newer version for the same architecture on an older version. For one thing, this is not cross-compilation. For another, given the compiler changes, the fact that when you set DESTDIR you (inappropriately) override a number of definitions, including the include and library paths, such that it's not possible to use the new compiler on an older system in order to do a "make world". I first discovered this trying to use gcc2.93 quite a while ago, and the problem with the build system remains uncorrected. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 10: 6:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C5F2014C18 for ; Mon, 18 Oct 1999 10:06:08 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA25313 for ; Mon, 18 Oct 1999 19:06:05 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA78555 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 19:06:04 +0200 (MET DST) Received: from critter.freebsd.dk (picasso.transbay.net [209.133.53.6]) by hub.freebsd.org (Postfix) with ESMTP id 18BFB14C33 for ; Mon, 18 Oct 1999 10:05:47 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id TAA06155; Mon, 18 Oct 1999 19:05:32 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-reply-to: Your message of "Fri, 15 Oct 1999 01:21:04 -0000." <199910150121.SAA20401@usr01.primenet.com> Date: Mon, 18 Oct 1999 19:05:32 +0200 Message-ID: <6153.940266332@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199910150121.SAA20401@usr01.primenet.com>, Terry Lambert writes: >Here's an argument I haven't heard before, and then a response to >Julian: > > >Question 1: How will I netboot my non-FreeBSD OS that > requires block devices using an NFS mounted > / containing that OS's /dev, if FreeBSD can > not support block devices in its FS? No, it will not affect this. The open of a special node happens on the client side, and stat(2) will return the right thing. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 10: 9:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1298014CBB for ; Mon, 18 Oct 1999 10:09:08 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA25341 for ; Mon, 18 Oct 1999 19:09:07 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA78577 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 19:09:07 +0200 (MET DST) Received: from critter.freebsd.dk (picasso.transbay.net [209.133.53.6]) by hub.freebsd.org (Postfix) with ESMTP id E5C6E14E13 for ; Mon, 18 Oct 1999 10:08:26 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id TAA06175 for ; Mon, 18 Oct 1999 19:08:21 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-reply-to: Your message of "Thu, 14 Oct 1999 16:56:25 PDT." Date: Mon, 18 Oct 1999 19:08:21 +0200 Message-ID: <6173.940266501@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Jul ian Elischer writes: >On Thu, 14 Oct 1999, Terry Lambert wrote: > >> First of all, thanks to everyone for such a focussed discussion. >> >> I have some comments on Poul's comments, and would at least like >> to argue for a "legacy mode", even if it is not enabled by default, >> so long as it can be enabled (and implied) without a kernel recompile >> (but perhaps requiring a kernel module), for standards compliance >> reasons, if no other. > >I have mentionned before, and I will mention again, that if a standard >disk layer is implemented, then it would be quite easy to implement >a block buffered interface to the raw disks, purely within the disk layer. But why bother, if nobody needs it ? >> 5) Programs that have to deal with CDROM's containing multiple >> sessions. >> >> This is an issues, since not all data is 2048 byte blocks, but >> can in fact be 2352, or a physical sector size of 2048, 2336, or >> 2340 bytes. This will only get more complicated as DVD and other >> standards evolve and come online. This is not an issue, since the app needs to know what it is doing anyway. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 10:27:58 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D094714A2D for ; Mon, 18 Oct 1999 10:27:55 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA25570 for ; Mon, 18 Oct 1999 19:27:55 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA78735 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 19:27:53 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id EE09714A2D for ; Mon, 18 Oct 1999 10:26:49 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id KAA23845; Mon, 18 Oct 1999 10:26:34 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpdAAALJaqGU; Mon Oct 18 10:26:31 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id KAA03157; Mon, 18 Oct 1999 10:26:26 -0700 (MST) From: Terry Lambert Message-Id: <199910181726.KAA03157@usr07.primenet.com> Subject: Re: The eventual fate of BLOCK devices. To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Oct 1999 17:26:25 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-arch@freebsd.org In-Reply-To: <6153.940266332@critter.freebsd.dk> from "Poul-Henning Kamp" at Oct 18, 99 07:05:32 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Here's an argument I haven't heard before, and then a response to > >Julian: > > > > > >Question 1: How will I netboot my non-FreeBSD OS that > > requires block devices using an NFS mounted > > / containing that OS's /dev, if FreeBSD can > > not support block devices in its FS? > > No, it will not affect this. The open of a special node > happens on the client side, and stat(2) will return the > right thing. So you are saying that the mknod won't go away, just that the nodes will not have the expected behaviour in FreeBSD. I think that if the nodes are still possible, they ought not to be duncels; at least there should be a compatability mode where they are not. I think the cost is a single "if" test on the "b"-ness of a device && the ioctl() function pointer being non-NULL (ie. the LKM is loaded. I get uncomfortable when functionality is permanently removed; the removal of block devices, as opposed to their being made optional, feels too much like when we lost the ISODE and X.25 code for lack of rigor when the new networking APIs and model were turned on. I truly think that if such a big change is going to be made, that it's up to the person making the change to be rigorous in case we find a hole in our foot two or three months down the road. I think that so long as the block nodes will remain, that the single "if (x && y)" and ioctl() code, even as an LKM, is a small overhead for the people removing the code to bear, with the benefit that we don't really lose functionality, and that people who wish to "bloat" their kernel back up can do so in order to not lose block device functionality. I keep hearing that an ioctl() to reenable the functionality would be trivial, but it doesn't seem that trivial to me, considering the coherency issues, so I would definitely prefer that it be implemented by someone who feel that it _is_ trivial, rather than me (I'm certain that I'd blow the coherency issues out of all proportion, with a sidebar implementation, and I'm not positive that others wouldn't as well, but I know I would). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 10:36:41 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BE9F114E40 for ; Mon, 18 Oct 1999 10:36:39 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA25678 for ; Mon, 18 Oct 1999 19:36:38 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA78810 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 19:36:38 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id E2E1814E40 for ; Mon, 18 Oct 1999 10:36:22 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id KAA26646; Mon, 18 Oct 1999 10:35:55 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpdAAAjfay6Z; Mon Oct 18 10:35:47 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id KAA03508; Mon, 18 Oct 1999 10:35:46 -0700 (MST) From: Terry Lambert Message-Id: <199910181735.KAA03508@usr07.primenet.com> Subject: Re: The eventual fate of BLOCK devices. To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Oct 1999 17:35:46 +0000 (GMT) Cc: freebsd-arch@freebsd.org In-Reply-To: <6173.940266501@critter.freebsd.dk> from "Poul-Henning Kamp" at Oct 18, 99 07:08:21 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is my last set of words on this subject... > >> I have some comments on Poul's comments, and would at least like > >> to argue for a "legacy mode", even if it is not enabled by default, > >> so long as it can be enabled (and implied) without a kernel recompile > >> (but perhaps requiring a kernel module), for standards compliance > >> reasons, if no other. > > > >I have mentionned before, and I will mention again, that if a standard > >disk layer is implemented, then it would be quite easy to implement > >a block buffered interface to the raw disks, purely within the disk layer. > > But why bother, if nobody needs it ? I think this is an invalid assumption. It is needed in order to comply with POSIX, if for no other reason. The idea that, if someone can't think of a use for something, and another person can, but that use is not seen as valid by the original someone, is a Very Bad Precedent. BSD is a research OS, and a research OS _must_ not, by its nature, limit the directions of future work. But even a research OS should be prepared to at least have a seperate mode in which it complies with standards. I would like to suggest that someone contact John Dyson, so that he can tell us how the FreeBSD Oracle port operates, and whether it needs block devices. I know that the IBCS2 emulation under which Sybase can run on FreeBSD _does_ need this. I also believe that Solaris emulation requires this for their packaging tools to operate properly under emulation. I would argue that people need the functionality. But even were you to prove that people didn't need the functionality now, given a willingness to bloat large amounts of user space code in order to cope with the lack of a traditional kernel service, you will not be able to prove that the functionality won't be needed at some future point. > >> 5) Programs that have to deal with CDROM's containing multiple > >> sessions. > >> > >> This is an issues, since not all data is 2048 byte blocks, but > >> can in fact be 2352, or a physical sector size of 2048, 2336, or > >> 2340 bytes. This will only get more complicated as DVD and other > >> standards evolve and come online. > > This is not an issue, since the app needs to know what it is doing > anyway. This would be the provenance of a filesystem, not an application, in my example. The reasoning behind this is to present, as files, raw audio and DVD data to a variety of applications which would *NOT* need to have the knowledge of the data format, other than as a linear array of bytes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 13:45:58 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 93B9215138 for ; Mon, 18 Oct 1999 13:45:51 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA27732 for ; Mon, 18 Oct 1999 22:45:49 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA79611 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 22:45:48 +0200 (MET DST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 94B7115154 for ; Mon, 18 Oct 1999 13:44:41 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id NAA90334; Mon, 18 Oct 1999 13:44:34 -0700 (PDT) Date: Mon, 18 Oct 1999 13:44:34 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-Reply-To: <199910181726.KAA03157@usr07.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's something that needs to be solved before Block devices can go away: Fsck on / in single user mode is presently done of the block device so that if fsck changes any blocks that are presently cached by the filesystem, they get updated for the filesystem. This ensures that should the filesystem then decide to read further data from the disk, that his data is consistent with that it has in memory. Changing this to be a simple char device will just not work correctly in the cases where there is minor cleanup required in the directories already loaded into memory. Until this is solved, block devices cannot be removed and certainly they cannot be replaced by char device. note: you need to corrupt the inodes in ways that they still appear valid to test this. (i.e. clri won't work) julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 17: 8:52 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 63D4B15398 for ; Mon, 18 Oct 1999 17:08:47 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id CAA29692 for ; Tue, 19 Oct 1999 02:08:46 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA81224 for freebsd-arch@freebsd.org; Tue, 19 Oct 1999 02:08:45 +0200 (MET DST) Received: from critter.freebsd.dk (picasso.transbay.net [209.133.53.6]) by hub.freebsd.org (Postfix) with ESMTP id 19F4E15395 for ; Mon, 18 Oct 1999 17:08:32 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id CAA00988 for ; Tue, 19 Oct 1999 02:08:21 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. In-reply-to: Your message of "Mon, 18 Oct 1999 13:44:34 PDT." Date: Tue, 19 Oct 1999 02:08:21 +0200 Message-ID: <986.940291701@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Jul ian Elischer writes: > >Here's something that needs to be solved before Block devices can go away: > >Fsck on / in single user mode is presently done of the block device >so that if fsck changes any blocks that are presently cached by the >filesystem, they get updated for the filesystem. No it isn't. Search for MNT_RELOAD in ufs/ffs. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Oct 18 21:28:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 771C115CE3 for ; Mon, 18 Oct 1999 21:28:17 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA01406 for ; Tue, 19 Oct 1999 06:28:15 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA81864 for freebsd-arch@freebsd.org; Tue, 19 Oct 1999 06:28:15 +0200 (MET DST) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id BED6415CE3 for ; Mon, 18 Oct 1999 21:28:06 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40352>; Tue, 19 Oct 1999 14:23:41 +1000 Content-return: prohibited Date: Tue, 19 Oct 1999 14:27:48 +1000 From: Peter Jeremy Subject: Re: kern.securelevel and X In-reply-to: To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@ALCATEL.COM.AU Message-Id: <99Oct19.142341est.40352@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> <19991018142633.D1DDB1DA3@bone.nectar.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-19 00:49:00 +1000, Dag-Erling Smorgrav wrote: >What EE suggested was to define a new SYSCTL macro to make defining >new security sysctls trivial. You'd do something like this: > >static int sec_syscall_mount = 1; >SYSCTL_SECURITY(mount, &sec_syscall_mount, "Allow mounting filesystems"); The disadvantage of this approach is kernel bloat: Each sysctl adds around 50 bytes of data overhead on an i386 (and about twice this on an Alpha). A single bitmap (which could still be a sysctl) of allowed syscalls would be substantially smaller and allow most of the permission checking inside trap.c:syscall(). (I agree that the userland would be more complex, but that isn't permanently resident). Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 19 1:55:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CB5CC16323 for ; Tue, 19 Oct 1999 01:55:45 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA04298 for ; Tue, 19 Oct 1999 10:55:45 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA82661 for freebsd-arch@freebsd.org; Tue, 19 Oct 1999 10:55:44 +0200 (MET DST) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id AD51A16323 for ; Tue, 19 Oct 1999 01:55:34 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA04290; Tue, 19 Oct 1999 10:55:27 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA82640; Tue, 19 Oct 1999 10:55:25 +0200 (MET DST) Date: Tue, 19 Oct 1999 10:55:25 +0200 From: Eivind Eklund To: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X Message-ID: <19991019105525.A82390@bitbox.follo.net> References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> <19991018142633.D1DDB1DA3@bone.nectar.com> <99Oct19.142341est.40352@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <99Oct19.142341est.40352@border.alcanet.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Oct 19, 1999 at 02:27:48PM +1000, Peter Jeremy wrote: [On using sysctl's for securelevel-style capabilities that can be dropped] > The disadvantage of this approach is kernel bloat: Each sysctl adds > around 50 bytes of data overhead on an i386 (and about twice this on > an Alpha). A single bitmap (which could still be a sysctl) of allowed > syscalls would be substantially smaller and allow most of the permission > checking inside trap.c:syscall(). First of all, I do not believe that the syscalls provide an adequate mapping to which things you want to protect against. I think you need different knobs if this is to be at all useful. Hardly any of the present securelevel restrictions map to syscalls. Second, looking at the syscall list, I find the following syscalls you might want to block (and which are not already handled by securelevel (with better semantics)): 14 STD POSIX { int mknod(char *path, int mode, int dev); } 21 STD BSD { int mount(char *type, char *path, int flags, \ caddr_t data); } 22 STD BSD { int unmount(char *path, int flags); } 23 STD POSIX { int setuid(uid_t uid); } 26 STD BSD { int ptrace(int req, pid_t pid, caddr_t addr, \ int data); } 36 STD BSD { int sync(void); } 44 STD BSD { int profil(caddr_t samples, size_t size, \ size_t offset, u_int scale); } 45 STD BSD { int ktrace(const char *fname, int ops, int facs, \ int pid); } 55 STD BSD { int reboot(int opt); } 56 STD POSIX { int revoke(char *path); } 61 STD BSD { int chroot(char *path); } 63 COMPAT BSD { int getkerninfo(int op, char *where, size_t *size, \ int arg); } getkerninfo getkerninfo_args int 85 STD BSD { int swapon(char *name); } 88 COMPAT BSD { int sethostname(char *hostname, u_int len); } \ sethostname sethostname_args int 96 STD BSD { int setpriority(int which, int who, int prio); } 134 STD BSD { int shutdown(int s, int how); } 143 COMPAT BSD { int sethostid(long hostid); } 148 STD BSD { int quotactl(char *path, int cmd, int uid, \ caddr_t arg); } 163 STD BSD { int setdomainname(char *domainname, int len); } 166 STD BSD { int rtprio(int function, pid_t pid, \ struct rtprio *rtp); } 203 STD BSD { int mlock(const void *addr, size_t len); } 327 STD POSIX { int sched_setparam (pid_t pid, \ const struct sched_param *param); } 335 STD BSD { int utrace(const void *addr, size_t len); } 338 STD BSD { int jail(struct jail *jail); } We're talking of 23 syscalls that I can see as being relevant for a block. At 50 bytes each, this is 1150 bytes. Of course, for a sysctl based implementation, you would use a different granularity (better fit to reaching particular goals), so it would be less. I don't think this is worth the extra syscall overhead, particularly as the syscalls you would want to block are not on the critical path, while the overhead would be (including cache memory loss). If the kernel bloat is seen as a problem, we could hide it behind a kernel option (though I'm not particularly happy about adding more kernel options). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 19 10:39:23 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id DD91B14F30 for ; Tue, 19 Oct 1999 10:39:10 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA12300 for ; Tue, 19 Oct 1999 19:39:09 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA86742 for freebsd-arch@freebsd.org; Tue, 19 Oct 1999 19:39:09 +0200 (MET DST) Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id 407C21740F for ; Tue, 19 Oct 1999 10:36:06 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from spawn.nectar.com (localhost [127.0.0.1]) by gw.nectar.com (Postfix) with ESMTP id D8DCFC008; Tue, 19 Oct 1999 12:35:53 -0500 (CDT) To: des@flood.ping.uio.no Cc: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X From: Jacques Vidrine In-Reply-To: References: <19991018152147.609F71DA3@bone.nectar.com> X-Mailer: Mew version 1.94 on XEmacs 21.1 (20 Minutes to Nikko) X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-rsa.txt X-PGP-DSSfprint: AB2F 8D71 A4F4 467D 352E 8A41 5D79 22E4 71A2 8C73 X-PGP-DHfprint: 2D50 12E5 AB38 60BA AF4B 0778 7242 4460 1C32 F6B1 X-PGP-DH-DSSkey: http://www.nectar.com/nectar-dh-dss.txt Date: Tue, 19 Oct 1999 12:35:53 -0500 Message-Id: <19991019173553.D8DCFC008@gw.nectar.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18 Oct 1999 18:30:20 +0200, Dag-Erling Smorgrav wrote: > Why are you so obsessed with jail(2)? There is no reason for this to > be jail(2)-specific. As I told you on IRC: > > 03:21 #bsdcode Nectar> DES: securelevel == systemwide, jail == process based > 03:22 #bsdcode ---------> nectar: no, you're not ambitious enough 8) I suppose that is fair: you misunderstood my remark, and I didn't get yours (I thought you were being sarcastic). What I was trying to indicate is that one facet of jail is analogous to securelevel (both limit the operations available to even the superuser). Both securelevel and that particular facet of jail should, IMHO, share a common implementation. Just so you don't accuse me of obsessing again :-) let me explain further. The jail system call as it exists in -CURRENT actually does three different things: it calls chroot, it restricts TCP/IP IPC, and it restricts certain operations. These three things don't necessarily belong together. It is the last aspect that I am comparing to securelevel, and that I've been talking about. Excuse me for using an existing system call as a reference point :-P I pretty much agree with the rest of your message. Off to see Markm talk about FreeBSD security. :-) Later, Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Oct 19 16:15:22 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C11811807D for ; Tue, 19 Oct 1999 16:15:10 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA16159 for ; Wed, 20 Oct 1999 01:15:05 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA87921 for freebsd-arch@freebsd.org; Wed, 20 Oct 1999 01:15:04 +0200 (MET DST) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id DC45B1808D for ; Tue, 19 Oct 1999 16:14:24 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40349>; Wed, 20 Oct 1999 09:09:51 +1000 Content-return: prohibited Date: Wed, 20 Oct 1999 09:14:13 +1000 From: Peter Jeremy Subject: Re: kern.securelevel and X In-reply-to: <19991019105525.A82390@bitbox.follo.net> To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct20.090951est.40349@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> <19991018142633.D1DDB1DA3@bone.nectar.com> <99Oct19.142341est.40352@border.alcanet.com.au> <19991019105525.A82390@bitbox.follo.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-19 18:55:25 +1000, Eivind Eklund wrote: >On Tue, Oct 19, 1999 at 02:27:48PM +1000, Peter Jeremy wrote: >[On using sysctl's for securelevel-style capabilities that can be > dropped] >> The disadvantage of this approach is kernel bloat: Each sysctl adds >> around 50 bytes of data overhead on an i386 (and about twice this on >> an Alpha). A single bitmap (which could still be a sysctl) of allowed >> syscalls would be substantially smaller and allow most of the permission >> checking inside trap.c:syscall(). Maybe I should have thought through this more completely... >First of all, I do not believe that the syscalls provide an adequate >mapping to which things you want to protect against. Agreed - in most cases, a high `securelevel' requires restricting the functionality of a syscall, rather than totally blocking the syscall. >Second, looking at the syscall list, I find the following syscalls you >might want to block I hadn't worked through this. If it's only 20-30 system calls, then the sysctl approach is probably reasonable. I was concerned that we might be talking about adding this to the majority of syscalls. > (and which are not already handled by securelevel >(with better semantics)): I thought that one of the ideas here was to dump the existing securelevel and replace it with a more fine-grained approach (similar to capabilities). >If the kernel bloat is seen as a problem, In this case, it's probably not a problem. IMHO, we should consider the bloat factor when looking at new features - we're not trying to emulate Windoze2000. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 20 9:41:34 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 982EC14A06 for ; Wed, 20 Oct 1999 09:41:30 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA29319 for ; Wed, 20 Oct 1999 18:41:25 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA91074 for freebsd-arch@freebsd.org; Wed, 20 Oct 1999 18:41:24 +0200 (MET DST) Received: from mojave.worldwide.lemis.com (picasso.transbay.net [209.133.53.6]) by hub.freebsd.org (Postfix) with ESMTP id 7385F14A15 for ; Wed, 20 Oct 1999 09:34:18 -0700 (PDT) (envelope-from grog@lemis.com) Received: (grog@localhost) by mojave.worldwide.lemis.com (8.9.3/8.6.12) id AAA00364; Mon, 18 Oct 1999 00:34:19 -0700 (PDT) Message-ID: <19991018203339.27470@mojave.worldwide.lemis.com> Date: Mon, 18 Oct 1999 20:33:39 +1300 From: Greg Lehey To: Marcel Moolenaar , arch@freebsd.org Subject: Re: make world issues References: <380716A4.20961526@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <380716A4.20961526@scc.nl>; from Marcel Moolenaar on Fri, Oct 15, 1999 at 01:57:24PM +0200 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, 15 October 1999 at 13:57:24 +0200, Marcel Moolenaar wrote: > Some flaws in the "make world" became apparent when the sigset_t > datatype changed. One of the biggest problems right now is that we don't > have an upgrade path from -stable to -current. Especially with 4.0 being > released early next year. I want to start a discussion here on how to > properly implement make world. I start of with known issues/problems and > some points that are not necessarily problems. Following that I give an > indication of what I'm thinking about by summing a number of design > "points" that I have in mind. I finish with the notion that you can help > :-) > > Known issues/problems: > P1. the upgrade path is broken. > P2. aout to elf seems to be broken too. > P3. no cross compilation. > P4. buildworld must be performed as root. > P5. sys.mk pollution. > > Questionable issues: > P6. no kernel is made as part of world. I don't have a problem separating world and kernel. But building the klds should be part of building the kernel, not making the world. This is just for the record: I think peter is looking at this, and it may get fixed soon. But if you are planning to restructure the build, it's a point to bear in mind. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Oct 20 9:44:17 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 18D6714A2F for ; Wed, 20 Oct 1999 09:44:14 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA29351 for ; Wed, 20 Oct 1999 18:44:13 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA91089 for freebsd-arch@freebsd.org; Wed, 20 Oct 1999 18:44:13 +0200 (MET DST) Received: from mojave.worldwide.lemis.com (picasso.transbay.net [209.133.53.6]) by hub.freebsd.org (Postfix) with ESMTP id 4AD7B14D61 for ; Wed, 20 Oct 1999 09:34:18 -0700 (PDT) (envelope-from grog@lemis.com) Received: (grog@localhost) by mojave.worldwide.lemis.com (8.9.3/8.6.12) id UAA00342; Mon, 18 Oct 1999 20:28:10 +1300 (NZDT) Message-ID: <19991018202740.50929@mojave.worldwide.lemis.com> Date: Mon, 18 Oct 1999 20:27:40 +1300 From: Greg Lehey To: Julian Elischer , Poul-Henning Kamp Cc: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. References: <447.939897820@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: ; from Julian Elischer on Thu, Oct 14, 1999 at 05:04:58PM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 14 October 1999 at 17:04:58 -0700, Julian Elischer wrote: > On Thu, 14 Oct 1999, Poul-Henning Kamp wrote: > >> Unless we have significant new information to the contrary, I will >> commence the bdev removal after November 1st 1999. > > This is I think a bit "pushy" for such an important step. > How about: "We will ask for a declaration of the right thing to do > from Core, specifically, DG as Arbiter, (not as DG) on Novenber 1. > So all arguments either way should be completed by that time." > > All sides involved should agree to let the matter rest after the decision > has been reached. I must say that I'm concerned about the evidence of Danish axes in this discussion. I do think that dg should get involved (probably as dg), though I suppose Kirk's support for the idea makes it more likely to happen. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Oct 21 1:34: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 537A414F2A for ; Thu, 21 Oct 1999 01:34:00 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA11884 for ; Thu, 21 Oct 1999 10:34:00 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA94370 for freebsd-arch@freebsd.org; Thu, 21 Oct 1999 10:33:59 +0200 (MET DST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5746014BB8; Thu, 21 Oct 1999 01:33:44 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA52611; Thu, 21 Oct 1999 10:33:42 +0200 (CEST) (envelope-from des) To: hackers@freebsd.org Subject: Finer-grained securelevel: proof of concept From: Dag-Erling Smorgrav Date: 21 Oct 1999 10:33:41 +0200 Message-ID: Lines: 8 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Patches are available from http://www.freebsd.org/~des/. This is strictly proof-of-concept; the patches demonstrate that fine-grained security knobs can be implemented with minimal code impact. No documentation is provided, RTFS. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 22 7:29:26 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A555514C9E for ; Fri, 22 Oct 1999 07:29:21 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA11915 for ; Fri, 22 Oct 1999 16:29:20 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA00261 for freebsd-arch@freebsd.org; Fri, 22 Oct 1999 16:29:19 +0200 (MET DST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4CA0914E1D; Fri, 22 Oct 1999 07:25:53 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id KAA52739; Fri, 22 Oct 1999 10:25:52 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 22 Oct 1999 10:25:52 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-arch@freebsd.org, freebsd-security@freebsd.org Subject: VFS, vnodes, and ACLs: Thoughts and Questions on integrating , POSIX.1e ACLs into FreeBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm in the process of reviewing the POSIX.1e draft to being implementing ACLs. As you're probably aware, all other major UNIX distributions have extended ACL support available, if not turned on in the default file system. For those that have been following the POSIX.1e list recently, I've posted a summary of some of the ways they get them into the FS (IRIX: has general purpose attribute support; Solaris: an extra inode and file structure for each ACL; Linux: an extra block pointer in the inode) -- and now I have some questions about adding this support to FreeBSD. The first question has to do with integration into the vnode as vnops. The closest current vnops are vop_getattr and vop_setattr -- getting and setting standard file attributes (mode, size, modification dates, et al). It makes sense conceptually that the ACLs might be included in this attribute information, as a substructure or pointer or the like. However, because ACL support across different file systems is nebulous and likely to be inconsistent for a long time (if not forever), it makes sense to think of getting and setting ACLs as vnops themselves -- for this purpose on an experimental kernel I have introduced vop_getacl and vop_setacl. This allows the ACLs to be exposed in their own right to the layering and file system behavior -- file systems that don't implement ACLs or don't know about them return EOPNOSUPP, and a layered file system could easily choose to intecept ACL changes explicitely and implement tham in a union or the like. If the vnode interface is aware of ACLs, this raises the format and semantics of ACL structures exposed in vnops, as they should/must be consistently interpreted and implemented. My temptation is to make POSIX.1e ACLs part of the vnode-aware types -- the interface seems to be standard across the various UNIX implementations, and in this sense it's similar to the mode, uid, gid values in vattr that we also expose non-opaquely. For reference, here's a simplified view of how most platforms have chosen to represent ACLs for their kernel syscall interface: They either define an acl_t structure referring to an array of ACL entries (acl_entry_t), or they directly pass around arrays of acl_entry_t's via syscalls. For example, the LINUX (and Solaris) ACL syscalls look like this: int acl(const char *pathp, int cmd, int aclcnt, acl_entry_t *aclentp); int facl(int filedes, int cmd, int aclcnt, acl_entry_t *aclentp); typedef struct acl_entry_t { int a_type; uid_t a_id; mode_t a_perm; } acl_entry_t; The various POSIX.1e interfaces refer instead to acl_t's which are presumed to store references to acl_entry_t's, so you could also imagine a syscall interface referring to an acl_t structure, and without the count variable. typedef struct acl_t { int entries; int size; acl_entry_t *entp; } acl_t; This provides a general ACL structure with a pointer to an array of acl_entry_t's, or individual "this user/group gets this right". The other approach to doing this might be the approach of: typedef struct acl_t { int entries; int size; acl_entry_t ent[3]; }; /* 3 is the minimum entries in an ACL */ This is where the aclcnt argument could come into play. Which would remove indirection in the vnode-aware structure and therefore perhaps be "nicer". Either way, it looks like acl_t's would be the best type (in whatever form) to pass ACLs around in the kernel with, as they can contain data describing the array of acl_entry_t's, and not just the entries as a direct array would do. This vnode approach then moves the responsibility for implementing ACLs to individual file systems -- a layer could choose to take advantage of some existing mechanism (extrended attributes) to store them. There's also the issue of evaluation -- right now, my understanding is that the vnode call vop_open is implemented by each file system, which may return EPERM if it desires. POSIX.1e describes an evaluation procedure for ACLs -- preusmably providing a set of common functions all file systems (optionally) can use for ACL evaluation makes sense -- this would mean (for example) that the same ACL evaluation routines could be used in FFS and MFS without replicating code all over the place. The other option is to treat ACLs as opaque and fs-specific, but that makes layering a lot less useful for implementing ACLs. On the other hand, it would also force us to follow the POSIX.1e model for ACLs, which while popular might benefit from improvement? Anyhow, thoughts on the topic would be much appreciated. I have not yet tried to address the issue of integrating ACL storage into various file systems. A first bet might be NFS as (apparently) there are NFS extensions for passing ACLs from ACL-aware servers (such as Solaris, IRIX, and presumably Linux sometime soon as they're talking about it on their acl-develop mailing list). Another choice might be Coda/AFS which both support ACLs, albeit not POSIX.1e-style ACLs. Some conversion between the two could be done for the purposes of inspecting ACLs, although I think not setting (AFS groups work quite a bit differently than POSIX-style groups, as they allow users to create them on the fly and modify them as they see fit). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Oct 22 8:50:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9A7A414C31 for ; Fri, 22 Oct 1999 08:49:54 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA12808 for ; Fri, 22 Oct 1999 17:49:50 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA00609 for freebsd-arch@freebsd.org; Fri, 22 Oct 1999 17:49:49 +0200 (MET DST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3F12814C2A; Fri, 22 Oct 1999 08:49:09 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA53171; Fri, 22 Oct 1999 11:48:46 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 22 Oct 1999 11:48:46 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: scott Cc: freebsd-arch@freebsd.org, freebsd-security@freebsd.org Subject: Re: VFS, vnodes, and ACLs: Thoughts and Questions on integrating , POSIX.1e ACLs into FreeBSD In-Reply-To: <19991022112650.A93123@chronis.pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've put the mailing lists back in the CC for my response because I include references to specifications, web pages, etc, below that answer some other people's questions also. On Fri, 22 Oct 1999, scott wrote: > On Fri, Oct 22, 1999 at 10:25:52AM -0400, Robert Watson wrote: > > > > I'm in the process of reviewing the POSIX.1e draft to being implementing > > ACLs. As you're probably aware, all other major UNIX distributions have > > extended ACL support available, if not turned on in the default file > > system. For those that have been following the POSIX.1e list recently, > > I've posted a summary of some of the ways they get them into the FS (IRIX: > > has general purpose attribute support; Solaris: an extra inode and file > > structure for each ACL; Linux: an extra block pointer in the inode) -- and > > now I have some questions about adding this support to FreeBSD. > > > > while I don't have the expertise to answer your questions, I am very > interested in the topic of ACL's for the filesystem, and am wondering > you can supply me with pointers to the posix.1e ACL specification and > discussions. > > I'd love to see a *good* ACL for freebsd. In particular, the admin > should be able to disallow symlinking in world writable directories, > choose what users and on what tty's can execute what set*id programs, > etc. > > I'm glad to see you taking an interest in this, and if I can get up to > speed on the standard you are referring to and some of the fs source > code, I'll certainly help out with ACL's for freebsd in any way I can. You can find information on the FreeBSD POSIX.1e implementation at http://www.watson.org/fbsd-hardening/posix1e/ Currently only information on our auditing implementation is online; we have most of a MAC implementation that I'll put online shortly, and ACLs are the next one we're working on. The spec does not define ACL rights for all the things you discuss for directories, but does provide an extensible environment for rights, so it's possible to fit them into the framework in a consistent way. At this point I'm in the design phase for FreeBSD ACLs and any advice and suggestions is greatly welcome--I'm a competent C and kernel programmer, but this is my first in-depth interaction with VFS/vnodes, so it's a learning experience for me also. There's a link from the page to a general POSIX.1e page including downloads of the specs (although redistribution is limited by our agreement with IEEEE). POSIX.1e defines standard interfaces for ACLs, Capabilities, MAC, Information Labels, and Auditing. It's a withdrawn draft, but some components are quite implementable, and are being implemented by a number of folk. There's also a posix1e mailing list for cross-platform and portability discussions that can be subscribed to by sending mail containing "subscribe posix1e" to majordomo@cyrus.watson.org. The posting address is posix1e@cyrus.watson.org. A web-accessible archive is available courtesy securityfocus.com -- it doesn't go back all the way to the beginning of the list, but includes a lot of the interesting recent discussions on MAC, ACLs, etc, including some reviews of ACL implementations on different platforms from a design perspective. I also have a complete archive available via anonymous imap from server cyrus.watson.org, mailbox lists.sec.posix1e Please let me know if you have any trouble accessing web pages, mailing lists, etc, and I'll see what I can do. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Oct 23 23: 8:39 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id AC0AF14DF6 for ; Sat, 23 Oct 1999 23:08:36 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id IAA06190 for ; Sun, 24 Oct 1999 08:08:35 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA09260 for freebsd-arch@freebsd.org; Sun, 24 Oct 1999 08:08:34 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 96C5C14DF6 for ; Sat, 23 Oct 1999 23:08:19 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA26549 for ; Sun, 24 Oct 1999 00:08:18 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA34462 for ; Sun, 24 Oct 1999 00:08:47 -0600 (MDT) Message-Id: <199910240608.AAA34462@harmony.village.org> To: arch@freebsd.org Subject: Racing interrupts Date: Sun, 24 Oct 1999 00:08:47 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Consider the following situation. There is a driver talking to a device. An unmasked interrupt happens and the device is now gone. How does the driver know to stop what it is doing and respond to this disappearance in a sane way? This sort of situation comes up in the pccard code. When someone ejects the card, an interrupt fires. If I were to remove the device from the tree in the interrupt handler, I can invalidate the softc that the driver is still using by freeing it. At that point the driver is running out of freed memory and all bets are off. I can schedule a timeout to happen in 0 clock ticks so that it is then "safe" to remove the device, but the hardware is either gone or very close to being gone when the first interrupt happens, so we've moved the problem from memory corruption to a hardware hang. It would be nice if there was some way to ref/unref the use of softc so I could remove the device right away, but defer the actual removal of the device and softc until the last deref of softc. This strikes me as a major PITA and may still result in a hardware hang. It is my understanding that the pccard hardware still still exist for a period of time after the card is ejected (since it takes some period of time to move from the pins that caused the interrupt to the power/control/data pins being disabled). I don't know if this is true, or if true what the period of time is. What I really want is a kernel signal mechanism which will start a rundown of the driver thread which is not allowed to touch hardware, but can only free resources used by the driver. We have lots of tight loops in drivers in the kernel and it seems unwise to pessimize those so that this race can be dealt with... Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message