Re: DPT revision....(broken drivers in -STABLE)
> I'm curious -- what kinds of cards are supported by this routine? > Does this include the DPT SmartRAID V, as well as the older SmartRAID > IV? I've got an anonymous ftp server I need to rebuild -- it had > previously been running Slackware Linux, but as the kernel got > updated, the source for the driver didn't, so I scrapped it and am > rebuilding with FreeBSD. The Linux driver for the V and VI cards is (according to a reliable source) pretty awful. > Anyway, my thought was actually to scrap the DPT card (because it > was my understanding that the FreeBSD drivers for the SmartRAID V > were only "beta" quality), and simply use vinum instead. However, if > this card is better supported than I first thought, then I'll be glad > to keep it. ;-) I have theoretically production-quality drivers from Adaptec which I will be committing as soon as I have time to test them (a few days, I hope). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yarrow & /dev/random
< said: > You probably don't want to chose RC6 or MARS because their authors > will probably patent them if they lose, and then you'll have to back > off using them fast. If they were going to be patented, the application has already been filed, so you might as well assume that they are patented. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yarrow & /dev/random
Jeroen writes: > > > Twofish in abrest Davies-Meyer mode is going to blow away BF-CBC-256 > > > pseudo 256 bit block cipher Davies-Meyer performance wise, because of > > > the key agility. > > But Twofish is not neccessarily the best choice. Yes, it's being > pushed by Bruce Schneier but that's for marketing purposes, not > for technical merits. I think that's a little negative -- all of the authors got to make their speil for how their cipher was the best. All the candidates are pushing their respective ciphers. > Iff you are going with a 128-bit-block blockcipher you ought to > select the most conservative one and that currently isn't Twofish > IMO. Anderson argues that Serpent is a conservative design, and makes a reasonable case for this, however as a result Serpent is a tad slow compared to others, and perhaps might lose as a result. I don't see that it makes much difference either way. You probably don't want to chose RC6 or MARS because their authors will probably patent them if they lose, and then you'll have to back off using them fast. Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yarrow & /dev/random
Mark Murray wrote: [...] > > Crypto construct-wise I don't think you can treat BF-CBC of a 256 bit > > plaintext with a 256 bit key as a virtual 256 bit block cipher > > operation. I suspect the result will be weaker than 256 bits because > > of the internal structure of BF-CBC. > > I'm not sure I understand this? 256-bit Davies-Meyer is considered secure if a blockcipher with a 256-bit block is being used. Encrypting 256 bits in CBC mode is not the same as a blockcipher with a 256-bit block. For one, it will not obfuscate certain plaintext patterns. Consider what happens if the first 64 bits of two plaintext blocks are equal... Using the current construct allows for a variety of attacks on the compression function of the constructed hash. > > If you want 256 bit hash (and it is desirable for AES) you could use > > what Jeroen suggested: abrest Davies-Meyer, and a 128 bit block > > cipher. Or we could wait for the AES hash mode. > > That is doable; But we don't have any 128-bit block blockciphers in the kernel? > at the moment I only have SHA1, MD5, DES and Blowfish > available in FreeBSD's kernel crypto API; I'd need a lot more evidence > before I feen I can pull in any more :-) You could argue that AES belongs in the kernel as soon as it is selected. You could then go ahead and import Serpent now (as the most conservative possible choice of AES) with the comment that it will be replaced with the real AES later. Waiting for the AES hash mode requires a lot of patience. I suspect a 256-bit hash will accompany the next-generation DSA but that will take at least a year or so... In any case, the currently available building blocks are not sufficient and I doubt you will encounter much objections against importing another cipher. Have you actually asked or is it more of a perceived objection? > > Twofish in abrest Davies-Meyer mode is going to blow away BF-CBC-256 > > pseudo 256 bit block cipher Davies-Meyer performance wise, because of > > the key agility. But Twofish is not neccessarily the best choice. Yes, it's being pushed by Bruce Schneier but that's for marketing purposes, not for technical merits. Iff you are going with a 128-bit-block blockcipher you ought to select the most conservative one and that currently isn't Twofish IMO. [...] > > The quality of the de-skewing function, conservative assumptions about > > distribution of entropy across samples and conservativeness of the > > entropy estimates don't help. It's the yarrow output function which > > blows it. > > Yeah; that monotonically-increasing counter bothers me slightly. Why? How would it affect security if one assumes the blockcipher is secure? Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_\_| \ _|/' \/ (_)>(_) (_)(_) (_)(_)' _\o_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: official devfs patch for review
On Sunday, August 27, 2000, Boris Popov wrote: > No, not all bits are incorporated. At least you've missed two > important things. First: > > # cd /dev/fd > # ls > 0 1 2 > # cd .. > # ls > 0 1 2 > > And second - directory names supplied by readdir() function > contains junk characters at the end. I'm going to commit some fdescfs-related patches sometime soon next week. If you're not using the fdescfs code already, I can probably integrate my work into devfs, since that was the point of my work on fdescfs. -- |Chris Costello <[EMAIL PROTECTED]> |All new: The software is not compatible with previous versions. `--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: official devfs patch for review
On Sat, 26 Aug 2000, Poul-Henning Kamp wrote: > This incorporates the functional bits from the patch Boris posted > here earlier as I've been able to extract them from his patch. No, not all bits are incorporated. At least you've missed two important things. First: # cd /dev/fd # ls 0 1 2 # cd .. # ls 0 1 2 And second - directory names supplied by readdir() function contains junk characters at the end. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DPT revision....(broken drivers in -STABLE)
At 10:18 PM -0400 2000/8/23, Matthew N. Dodd wrote: > I don't remember seeing a verbose boot log posted so I can't really say > whats wrong. There is no difference b/t the -CURRENT and 4-STABLE > versions of dpt_pci.c so I'm not sure what could be causing the > problem. Of course it may be that the cards don't work in -CURRENT > either. I'm curious -- what kinds of cards are supported by this routine? Does this include the DPT SmartRAID V, as well as the older SmartRAID IV? I've got an anonymous ftp server I need to rebuild -- it had previously been running Slackware Linux, but as the kernel got updated, the source for the driver didn't, so I scrapped it and am rebuilding with FreeBSD. Anyway, my thought was actually to scrap the DPT card (because it was my understanding that the FreeBSD drivers for the SmartRAID V were only "beta" quality), and simply use vinum instead. However, if this card is better supported than I first thought, then I'll be glad to keep it. ;-) -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: reducing sbsize: lost count, uid = 1001
If this is a problem with sbsize, this should take care of any possibility
ever of there being a problem...
Index: kern/kern_proc.c
===
RCS file: /usr2/ncvs/src/sys/kern/kern_proc.c,v
retrieving revision 1.69
diff -u -r1.69 kern_proc.c
--- kern/kern_proc.c2000/07/04 11:25:22 1.69
+++ kern/kern_proc.c2000/08/26 23:50:40
@@ -190,25 +190,33 @@
* Change the total socket buffer size a user has used.
*/
int
-chgsbsize(uid, diff, max)
+chgsbsize(uid, hiwat, to, max)
uid_t uid;
- rlim_t diff;
+ u_long *hiwat;
+ u_long to;
rlim_t max;
{
struct uidinfo *uip;
+ rlim_t diff;
+ int s;
uip = uifind(uid);
- if (diff < 0)
- KASSERT(uip != NULL, ("reducing sbsize: lost count, uid = %d", uid));
+ KASSERT(to < *hiwat && uip != NULL,
+ ("reducing sbsize: lost count, uid = %d", uid));
if (uip == NULL)
uip = uicreate(uid);
+ s = splnet();
+ diff = to - *hiwat;
/* don't allow them to exceed max, but allow subtraction */
if (diff > 0 && uip->ui_sbsize + diff > max) {
(void)uifree(uip);
+ splx(s);
return (0);
}
uip->ui_sbsize += diff;
+ *hiwat = to;
(void)uifree(uip);
+ splx(s);
return (1);
}
Index: kern/uipc_socket2.c
===
RCS file: /usr2/ncvs/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.61
diff -u -r1.61 uipc_socket2.c
--- kern/uipc_socket2.c 2000/07/31 08:23:43 1.61
+++ kern/uipc_socket2.c 2000/08/26 23:36:25
@@ -420,7 +420,6 @@
struct socket *so;
struct proc *p;
{
- rlim_t delta;
/*
* p will only be NULL when we're in an interrupt
@@ -428,8 +427,7 @@
*/
if ((u_quad_t)cc > (u_quad_t)sb_max * MCLBYTES / (MSIZE + MCLBYTES))
return (0);
- delta = (rlim_t)cc - sb->sb_hiwat;
- if (p && !chgsbsize(so->so_cred->cr_uid, delta,
+ if (p && !chgsbsize(so->so_cred->cr_uid, &sb->sb_hiwat, cc,
p->p_rlimit[RLIMIT_SBSIZE].rlim_cur)) {
return (0);
}
@@ -450,8 +448,8 @@
{
sbflush(sb);
- (void)chgsbsize(so->so_cred->cr_uid, -(rlim_t)sb->sb_hiwat, RLIM_INFINITY);
- sb->sb_hiwat = sb->sb_mbmax = 0;
+ (void)chgsbsize(so->so_cred->cr_uid, &sb->sb_hiwat, 0, RLIM_INFINITY);
+ sb->sb_mbmax = 0;
}
/*
Index: kern/uipc_socket.c
===
RCS file: /usr2/ncvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.80
diff -u -r1.80 uipc_socket.c
--- kern/uipc_socket.c 2000/08/07 17:52:08 1.80
+++ kern/uipc_socket.c 2000/08/26 23:37:00
@@ -191,10 +191,10 @@
so->so_gencnt = ++so_gencnt;
if (so->so_rcv.sb_hiwat)
(void)chgsbsize(so->so_cred->cr_uid,
- -(rlim_t)so->so_rcv.sb_hiwat, RLIM_INFINITY);
+ &so->so_rcv.sb_hiwat, 0, RLIM_INFINITY);
if (so->so_snd.sb_hiwat)
(void)chgsbsize(so->so_cred->cr_uid,
- -(rlim_t)so->so_snd.sb_hiwat, RLIM_INFINITY);
+ &so->so_snd.sb_hiwat, 0, RLIM_INFINITY);
if (so->so_accf != NULL) {
if (so->so_accf->so_accept_filter != NULL &&
so->so_accf->so_accept_filter->accf_destroy != NULL) {
Index: kern/uipc_usrreq.c
===
RCS file: /usr2/ncvs/src/sys/kern/uipc_usrreq.c,v
retrieving revision 1.58
diff -u -r1.58 uipc_usrreq.c
--- kern/uipc_usrreq.c 2000/07/11 22:07:43 1.58
+++ kern/uipc_usrreq.c 2000/08/26 23:52:24
@@ -217,6 +217,7 @@
{
struct unpcb *unp = sotounpcb(so);
struct socket *so2;
+ u_long newhiwat;
if (unp == 0)
return EINVAL;
@@ -235,9 +236,10 @@
*/
so2->so_snd.sb_mbmax += unp->unp_mbcnt - so->so_rcv.sb_mbcnt;
unp->unp_mbcnt = so->so_rcv.sb_mbcnt;
- so2->so_snd.sb_hiwat += unp->unp_cc - so->so_rcv.sb_cc;
- (void)chgsbsize(so2->so_cred->cr_uid,
- (rlim_t)unp->unp_cc - so->so_rcv.sb_cc, RLIM_INFINITY);
+ newhiwat = so2->so_snd.sb_hiwat + unp->unp_cc -
+ so->so_rcv.sb_cc;
+ (void)chgsbsize(so2->so_cred->cr_uid, &so2->so_snd.sb_hiwat,
+ newhiwat, RLIM_INFINITY);
unp->unp_cc = so->so_rcv.sb_cc;
sowwakeup(so2);
break;
@@ -257,6 +259,7 @@
int error = 0;
struct unpcb *unp = sotounpcb(so);
struct socket *so2;
+ u_long newhiwat;
if (unp == 0) {
error = EINVAL;
@@ -342,10 +345,10 @@
so->so_snd.sb_mbmax -=
so2->so_rcv.sb_mbcnt -
Re: PATCH: devfs mkIII test & review please.
On Fri, 18 Aug 2000, Poul-Henning Kamp wrote: > Missing: > Rename > Subdirs. > Close some race conditions using guaranteed atomic operations. > Mountoption (ro ?) to prevent new devices from appearing in an instance. > All uses of cdevsw_add() needs to be use devfs_clone() instead. How should 3rd party KLDs implement cloning function ? For now it seems to be impossible to use a single binary for DEVFS and non-DEVFS case. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/secure/lib/libcrypto Makefile Makefile.inc
On Thu, 24 Aug 2000, Nickolay Dudorov wrote: > I usually run 'make -j32 buildworld' on my current > system. After this commit I can not do this. The next patch > permits to use '-j32' again. Since it can't really break things to do so, I added it :) Thanks. > N.Dudorov -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yarrow & /dev/random
Mark writes: > [...] > FreeBSD is using an earlier version of T'so's code; I beiieve he > improved it later, but it has no (or little) backtracking protection, > and can be too easily attacked "from both sides". OK, I agree that that's an area where yarrow offers better protection. But it's not like Ted's code is broken or anything. We would break things using /dev/random by switching as is to yarrow, so this is why I don't like it: we're trying to improve things (Yarrows protection aginst the attacks you describe), but in order to do this we're doing some other damage. We should at least do no damage: we're improving one thing and breaking something else. > > Crypto construct-wise I don't think you can treat BF-CBC of a 256 bit > > plaintext with a 256 bit key as a virtual 256 bit block cipher > > operation. I suspect the result will be weaker than 256 bits because > > of the internal structure of BF-CBC. > > I'm not sure I understand this? Well consider the behavior of the BF-CBC-256 construct as a block cipher. If we encrypt: X1 = (x1 || x2 || x3 || x4) where |x| is blowfish block size (64 bits) and |X1| is BF-CBC-256 pseudo-blocksize (256 bits). The encryption of X1 and X1' = (x1 || x2 || x3 || x4') are going to be the same in all blocks except the last: Y1 = (y1||y2||y3||y4) = E( X1 ) Y1' = (y1||y2||y3||y4') = E( X1' ) a block cipher would be considered broken if it exhibited that behavior. I don't immediately see how to transfer that to weakening the Davies-Meyer hash built using it -- but it certainly violates the stated requirements for the strength of the underlying block cipher. Probably you can do some kind of 2^64 work factor precomputation attack something. Bear in mind anything significantly short of 2^256 operations allowing you to compute hash collisions is going to be considered a break, and that gives quite a lot of scope for precomputation against CBC on a smaller block cipher given the hash output size. > > > ...unless we can somehow get /dev/random to be "secure enough". > > > > I think we have an obligation to attempt to make it no less secure > > than the current /dev/random; and of course we should try to make it > > as secure as we can in general. See below for my ideas of how you > > might do that. > > :-) I am of the opinion that a well-implemented Yarrow with lots of > entropy-harvesting to back it up can be as good as a simple hash-based > single-pool bit distiller. My argument is weakening, though. The distiller needs looking at -- it seems to be a bit hazy due to the unknown spread of correlations between input samples, but even if you presume god's distiller, getting outputs via the yarrow output function is going to destroy any hopes of getting information theoretic security. > > The solution as I see it is to modify yarrow to bypass the yarrow > > output function and grab raw de-skewing function output for > > /dev/random output. You'd also want to do what John Kelsey was > > suggesting and XOR the bypassed de-skewing function output with > > /dev/urandom output as an additional safety measure. > > I'll look that up; It sounds like quite a departure from yarrow to > me though; that makes me nervous. Well you leave most of yarrow alone, you just add the ability to reserve de-skewing function outputs for /dev/random. /dev/urandom still goes through the normal yarrow output function. > > But let's get this put in yarrow-160-a, rather than making our own > > variant -- then we can say we are using stock yarrow, and other yarrow > > users benefit. > > Ok - as long as "classic" yarrow has it. I agree, we need the peer review. > > entropy estimation and make good assumptions about entropy > > distribution I see no inherent reason why we can't generate OTP > > quality randomness from generic PC hardware. There is real entropy in > > that mouse swirl and keyboard input. > > ...there may not be a suitable monkey at the keyboard. What about > a server in an unattended colo? MHO - hardware RNG. Unattended servers are a problem alright. One thing you can do is if your server has any private keys -- and it generally will have if it's doing crypto -- is mix the private key into the random pool along with the curren time. As the attacker doesn't know your private key (if he does it's game over anyway), you get a /dev/urandom which is secure. (If you don't like the `feel' of putting your private key into /dev/urandom as a sample, run it through a one-way hash function first). The other thing you can do is mix in encrypted IVs people connecting to your server send you -- for example SSL, SSH, and PGP and so on tend to do this. It can't hurt because you're only mixing, and you can't destroy entropy with a good mixing function; and if you presume the collection of people who connect to you aren't colluding it helps. (If there is only one person communicating with you, it doesn't matter anyway, because they have their own plaintext.) We
Re: DPT revision....(broken drivers in -STABLE)
Jonathan Chen wrote:
> On Wed, Aug 23, 2000 at 01:51:16PM -0500, Visigoth wrote:
>
> > Sorry for the cross post but
> >
> > Would it be possible to revert the DPT commits made by peter on
> > Mon Aug 7 18:48:14 2000 in the RELENG_4 branch? It seems that the
> > dpt_attatch is failing in bus_alloc_resource(9) for the IRQ, and I have
> > production machines that need worlds built for some other updates as
> > well.. I would be happy to install a -CURRENT machine and help debug
> > until it works, but for right now, there is NO DPT support in -STABLE for
> > the DPT PM3334UW. I had a pr started, but haven't been able to get any
> > response from the current maintainer.
> >
> > I am going to install a -CURRENT machine with a DPT in it and
> > start the process of working on the issue, but it would be nice if we can
> > keep -STABLE stable... ;)
>
> I just updated on my -STABLE machine and ran into the same exact problem.
> I also have on the machine SMP with APIC. The fix for this problem is
> simple:
Argh! I have committed this now, both in -current and RELENG_4. Thanks!
> Index: dpt_pci.c
> ===
> RCS file: /export/ncvs/src/sys/dev/dpt/dpt_pci.c,v
> retrieving revision 1.17.2.1
> diff -u -r1.17.2.1 dpt_pci.c
> --- dpt_pci.c 2000/08/07 18:48:14 1.17.2.1
> +++ dpt_pci.c 2000/08/26 21:40:26
> @@ -106,7 +106,7 @@
> }
>
> rid = 0;
> - irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_ACTIVE);
> + irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_ACTIVE |
RF_SHAREABLE);
> if (!irq) {
> device_printf(dev, "No irq?!\n");
> error = ENOMEM;
>
> (Everybody in unison, say "Doh!")
> Since this didn't change in the past two months, I'm guessing this was
> caused by somebody else futzing with APIC. In any case, I don't see why
> the DPT card shouldn't be allowed to share IRQs, and I'm now running the
> latest -STABLE on my DPT card.
>
> PS. Sorrry Matt for foiling your evil plot to get a free RAID card. ;)
>
> --
> (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o)
> \\\_\Jonathan Chen [EMAIL PROTECTED] /_///
> <) No electrons were harmed during production of this message (>
> ~
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: DPT revision....(broken drivers in -STABLE)
On Wed, Aug 23, 2000 at 01:51:16PM -0500, Visigoth wrote:
> Sorry for the cross post but
>
> Would it be possible to revert the DPT commits made by peter on
> Mon Aug 7 18:48:14 2000 in the RELENG_4 branch? It seems that the
> dpt_attatch is failing in bus_alloc_resource(9) for the IRQ, and I have
> production machines that need worlds built for some other updates as
> well.. I would be happy to install a -CURRENT machine and help debug
> until it works, but for right now, there is NO DPT support in -STABLE for
> the DPT PM3334UW. I had a pr started, but haven't been able to get any
> response from the current maintainer.
>
> I am going to install a -CURRENT machine with a DPT in it and
> start the process of working on the issue, but it would be nice if we can
> keep -STABLE stable... ;)
I just updated on my -STABLE machine and ran into the same exact problem.
I also have on the machine SMP with APIC. The fix for this problem is
simple:
Index: dpt_pci.c
===
RCS file: /export/ncvs/src/sys/dev/dpt/dpt_pci.c,v
retrieving revision 1.17.2.1
diff -u -r1.17.2.1 dpt_pci.c
--- dpt_pci.c 2000/08/07 18:48:14 1.17.2.1
+++ dpt_pci.c 2000/08/26 21:40:26
@@ -106,7 +106,7 @@
}
rid = 0;
- irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_ACTIVE);
+ irq = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1, RF_ACTIVE |
+RF_SHAREABLE);
if (!irq) {
device_printf(dev, "No irq?!\n");
error = ENOMEM;
(Everybody in unison, say "Doh!")
Since this didn't change in the past two months, I'm guessing this was
caused by somebody else futzing with APIC. In any case, I don't see why
the DPT card shouldn't be allowed to share IRQs, and I'm now running the
latest -STABLE on my DPT card.
PS. Sorrry Matt for foiling your evil plot to get a free RAID card. ;)
--
(o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o)
\\\_\Jonathan Chen [EMAIL PROTECTED] /_///
<) No electrons were harmed during production of this message (>
~
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: yarrow & /dev/random
> > OK; what then? The existing MD5 based system is very attackable, and > > protects itself very poorly. > > My argument for linux is leave it as it is, and see if we can persuade > the yarrow authors to change yarrow so it does export a /dev/random > compatible API. If that happened, I'd follow suit. > Isn't freeBSD using the same Ted T'so code? It's "good enough" IMO > that there is no rush to change it until we can preserve it's API > semantics. The linux version has been switched to SHA1, though IMO > Dobbertin's pseudo collision attack on MD5 isn't broken in any > practical way for this purpose. People are just moving away from MD5 > in case someone manages to extend this attacks as conservative design. FreeBSD is using an earlier version of T'so's code; I beiieve he improved it later, but it has no (or little) backtracking protection, and can be too easily attacked "from both sides". > > My approach to this (and this is the first time I am stating this in > > such a wide forum) is to provide another device (say /dev/srandom) for > > folk who want to do their own randomness processing. This would provide > > a structure of data including the entropy, the system nanotime and the > > source, so the user can do his own hard work when he needs to, and the > > folk simply needing a stream of "good" random numbers can do do from > > /dev/random. > > You don't want people to have work hard -- they just want to retain > the /dev/random API which works and has understood semantics. Reading random events from the kernel to stir into a pot is not too far off what I am asking folk to do; it would be better to ask them to read N bits out of /dev/random, but N bits aren't always available; we have to compromise. Raw data is a pretty "pure" compromaise. > > Sooner or later someone is going to come up with a requirement for > > M-bit randoness on Yarrow-N, where M > N. What then? > > You could use the /dev/random API if your entropy requirements are > greater than the output size of /dev/urandom (implemented with yarrow > or otherwise). With the API we could add a call to ask the device > what it's output block size is. And/or we could define a value > exported from random.h for the bit strength of /dev/urandom, though > that risks missing changes over time. Hmm. sounds like we need a way of forcing some entropy back into /dev/random, or doing things with reseeds. Lets say we have a zener noise generator and a geiger counter, but these are connected to a device that the kernel (and thus /dev/random) cannot "harvest" (like say an async line or at the end of an SSH connection), I have make the current FreeBSD accept that input (in 8-byte chunks) followed by an explicit reseed. This is not a perfect solution to anything, but a user with high entropy needs has a simple method of "pumping" the driver, and as long as he reads at the same spead as he writes, he gets his deskewing. > > I can't help broken applications, but if we provide a better API, and > > get folk to use it, that everyone wins. > > The applications aren't broken. They are using the advertised > /dev/random API, and some people are proposing to pull the rug out of > under them and effectively symlink /dev/random to /dev/urandom. I'm trying to improve, not pull the rug :-). > As they may have relied on better than /dev/urandom for security, you > may break the security of their application. This is what I'm counting on a) yarrow and b) better harvesting for. > > I fixed that and made it Davies-Meyer. > > http://people.freebsd.org/~markm/randomdev.patch > > Looks good. API comment: you might want a hash_final implemented as a > memcpy because some hashes you swap in have this phase (MD5, SHA1 mix > in the length as a last step). Also other hash APIs often don't have > an hash_init which takes the magic constants as an argument. As > you're not using any constants (and relying on 0 as the magic constant > / Davies-Meyer IV) you could remove that. Then you'd have the classic > MD5 API which would make plugging other hashes in easy. Sounds sensible. Will do. > Crypto construct-wise I don't think you can treat BF-CBC of a 256 bit > plaintext with a 256 bit key as a virtual 256 bit block cipher > operation. I suspect the result will be weaker than 256 bits because > of the internal structure of BF-CBC. I'm not sure I understand this? > If you want 256 bit hash (and it is desirable for AES) you could use > what Joeren suggested: abrest Davies-Meyer, and a 128 bit block > cipher. Or we could wait for the AES hash mode. That is doable; at the moment I only have SHA1, MD5, DES and Blowfish available in FreeBSD's kernel crypto API; I'd need a lot more evidence before I feen I can pull in any more :-) > Twofish in abrest Davies-Meyer mode is going to blow away BF-CBC-256 > pseudo 256 bit block cipher Davies-Meyer performance wise, because of > the key agility. Understood :-). See above. > > ...unless we can somehow get /dev/r
Re: make buildworld (4->5) failed
On Sat, 26 Aug 2000, Alexey Zelkin wrote: > hi, > > Just experienced on 4.0-RELEASE and 4.1-STABLE (two days ago) following > error when tried to build current world. This was already fixed a few days ago. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yarrow & /dev/random
Mark writes: > > You really can't use yarrow to implement /dev/random as it is. > > [...] > > OK; what then? The existing MD5 based system is very attackable, and > protects itself very poorly. My argument for linux is leave it as it is, and see if we can persuade the yarrow authors to change yarrow so it does export a /dev/random compatible API. Isn't freeBSD using the same Ted T'so code? It's "good enough" IMO that there is no rush to change it until we can preserve it's API semantics. The linux version has been switched to SHA1, though IMO Dobbertin's pseudo collision attack on MD5 isn't broken in any practical way for this purpose. People are just moving away from MD5 in case someone manages to extend this attacks as conservative design. > My approach to this (and this is the first time I am stating this in > such a wide forum) is to provide another device (say /dev/srandom) for > folk who want to do their own randomness processing. This would provide > a structure of data including the entropy, the system nanotime and the > source, so the user can do his own hard work when he needs to, and the > folk simply needing a stream of "good" random numbers can do do from > /dev/random. You don't want people to have work hard -- they just want to retain the /dev/random API which works and has understood semantics. > > However it is not fair to impose that view on someone. People can > > have legitmate reasons to need more entropy. Another very concrete > > example is: say someone is using a yarrow-160 (3DES and SHA1) > > implementation and they want to use an AES cipher with a 256 bit key > > -- without the /dev/random API, you can't get 256 bit security, with > > it you can. > > Sooner or later someone is going to come up with a requirement for > M-bit randoness on Yarrow-N, where M > N. What then? You could use the /dev/random API if your entropy requirements are greater than the output size of /dev/urandom (implemented with yarrow or otherwise). With the API we could add a call to ask the device what it's output block size is. And/or we could define a value exported from random.h for the bit strength of /dev/urandom, though that risks missing changes over time. > > OTPs and some algorithms offer information theoretic security, or you > > may be using a larger key space symmetric construct than the yarrow > > output size (using 256 doesn't solve that -- then they want a 512 bit > > key). Worse people may already be using /dev/random for these > > assumptions, so you risk breaking existing code's security by > > replacing /dev/random with yarrow. > > I can't help broken applications, but if we provide a better API, and > get folk to use it, that everyone wins. The applications aren't broken. They are using the advertised /dev/random API, and some people are proposing to pull the rug out of under them and effectively symlink /dev/random to /dev/urandom. As they may have relied on better than /dev/urandom for security, you may break the security of their application. > > > If I construct a specific hash function, is this still a problem? > > > > No. Note my other comments on list about CBC-MAC are confused -- I > > misread your code. It appears to be a keyless hash function, and as > > Joeren noted it has some similarities to Davies-Meyer, but it's not > > quite the same for the reasons he noted. > > I fixed that and made it Davies-Meyer. > http://people.freebsd.org/~markm/randomdev.patch Looks good. API comment: you might want a hash_final implemented as a memcpy because some hashes you swap in have this phase (MD5, SHA1 mix in the length as a last step). Also other hash APIs often don't have an hash_init which takes the magic constants as an argument. As you're not using any constants (and relying on 0 as the magic constant / Davies-Meyer IV) you could remove that. Then you'd have the classic MD5 API which would make plugging other hashes in easy. Crypto construct-wise I don't think you can treat BF-CBC of a 256 bit plaintext with a 256 bit key as a virtual 256 bit block cipher operation. I suspect the result will be weaker than 256 bits because of the internal structure of BF-CBC. If you want 256 bit hash (and it is desirable for AES) you could use what Joeren suggested: abrest Davies-Meyer, and a 128 bit block cipher. Or we could wait for the AES hash mode. Twofish in abrest Davies-Meyer mode is going to blow away BF-CBC-256 pseudo 256 bit block cipher Davies-Meyer performance wise, because of the key agility. > > | So given that, it doesn't seem quite fair to pull the rug from under > > | /dev/random users and replace it with a PRNG with quite different > > | security assumptions. Users would have similar reasons to be upset if > > | someone removed their /dev/random and symlinked it to /dev/urandom. > > ...unless we can somehow get /dev/random to be "secure enough". I think we have an obligation to attempt to make it no less secure than the current /dev/rand
official devfs patch for review
There is an official DEVFS patch at http://phk.freebsd.dk/patch/devfs.patch This incorporates the functional bits from the patch Boris posted here earlier as I've been able to extract them from his patch. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
break in usr.bin/kdump
Hello, I've been tracking -CURRENT for a while.. Whenever I attempt to build the world I get the following break: # make buildworld ===> usr.bin/kdump cc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../. . -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/kdump/kdump.c sh /usr/src/usr.bin/kdump/mkioctls /usr/obj/usr/src/i386/usr/include > ioctl.c In file included from :67: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:80: warning: this is the location of the previous definition cc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../. . -I/usr/obj/usr/src/i386/usr/include -c ioctl.c In file included from ioctl.c:97: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:80: warning: this is the location of the previous definition In file included from ioctl.c:37: /usr/obj/usr/src/i386/usr/include/dev/usb/rio500_usb.h:35: redefinition of `struct RioCommand' *** Error code 1 Stop in /usr/src/usr.bin/kdump. *** Error code 1 # I do own one of the rio500 devices and have installed the rio500 audio package in the past (have since cleaned it..) I usually just comment out struct RioCommand from include/dev/usb/rio500_usb.h this goes away, feeling this was a common break but since it has been reoccuring I feel that I should mention it. Anyone have ideas to figure out why this is occuring on only this box? Thanks -- James To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions..
It seems Thomas Stromberg wrote: > On Sat, 26 Aug 2000, Mike Smith wrote: > > > This is not an "IDE RAID" controller. It's an IDE controller with some > > lame "RAID" software in the BIOS. We don't support this. > > Hopefully this thread will save the next poor soul who tries this. > > Just to put the final nail in the coffin.. I went ahead and > installed on an old WDMA2 drive of mine, and put /var and /usr on what > hopefully was a striped RAID. Well, I pulled the second drive > offline, and.. it still booted up beautifully. So the striping in bios > on the HPT-370 is indeed meaningless. C'est la vie. > > Now the question is, what ATA-100 RAID solutions are there that are fully > supported? I'd guess the Promise board, but the last time I guessed > (err.. last week), I got a supported chipset with an unsupported feature > :) Well, both the HPT270 and the Promise Fasttrak "RAID" gimmicks are SW in the BIOS, so there is no HW to support. You could use vinum to get the exact same behavior... > Just so I don't go do anything stupid, anyone secretly working on > drivers for this behind our backs, or is it as good as junk? He, I've got a patch submitted that should work with the promise ie it does the RAID stuff in the driver and reads the RAID setup from the BIOS/disks. I've yet to find out how/where HPT stores their info, but in case I find out, I will probably add support for these "BIOS RAID" setups... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yarrow & /dev/random
> You really can't use yarrow to implement /dev/random as it is. Even
> waiting for reseeds doesn't cut it. The issue is that everything goes
> through the yarrow output function, which restricts yarrow to offering
> computational security with at worst 2^n work factor to break because
> it offers known plaintext the 0 block as the first output is E_k( 0 ).
OK; what then? The existing MD5 based system is very attackable, and
protects itself very poorly.
My approach to this (and this is the first time I am stating this in
such a wide forum) is to provide another device (say /dev/srandom) for
folk who want to do their own randomness processing. This would provide
a structure of data including the entropy, the system nanotime and the
source, so the user can do his own hard work when he needs to, and the
folk simply needing a stream of "good" random numbers can do do from
/dev/random.
> > I am against the blocking model, as I believe that it goes against
> > what Yarrow is trying to do. If the Yarrow authors argued otherwise,
> > I'd listen.
>
> Niels and John Kelsey were against it to initially, on the grounds
> that computational security (160 bits -- or whatever the parameter is
> with the ciphers you have plugged in) is in fact "good enough" in
> practice even for 1024 bit RSA key generation.
>
> (The argument has some validity; in practice a brute force attack
> against RSA 1024 takes significantly less than 2^160 operations,
> though the memory requirements are higher).
I've heard that that is down to like 2^90 or a lot less...
> However it is not fair to impose that view on someone. People can
> have legitmate reasons to need more entropy. Another very concrete
> example is: say someone is using a yarrow-160 (3DES and SHA1)
> implementation and they want to use an AES cipher with a 256 bit key
> -- without the /dev/random API, you can't get 256 bit security, with
> it you can.
Sooner or later someone is going to come up with a requirement for
M-bit randoness on Yarrow-N, where M > N. What then?
> OTPs and some algorithms offer information theoretic security, or you
> may be using a larger key space symmetric construct than the yarrow
> output size (using 256 doesn't solve that -- then they want a 512 bit
> key). Worse people may already be using /dev/random for these
> assumptions, so you risk breaking existing code's security by
> replacing /dev/random with yarrow.
I can't help broken applications, but if we provide a better API, and
get folk to use it, that everyone wins.
> > If I construct a specific hash function, is this still a problem?
>
> No. Note my other comments on list about CBC-MAC are confused -- I
> misread your code. It appears to be a keyless hash function, and as
> Joeren noted it has some similarities to Davies-Meyer, but it's not
> quite the same for the reasons he noted.
I fixed that and made it Davies-Meyer.
http://people.freebsd.org/~markm/randomdev.patch
> The main argument is against not using constructs which haven't
> received lots of peer-review -- most crypto constructs are very
> fragile to small design changes.
Agreed.
> | So given that, it doesn't seem quite fair to pull the rug from under
> | /dev/random users and replace it with a PRNG with quite different
> | security assumptions. Users would have similar reasons to be upset if
> | someone removed their /dev/random and symlinked it to /dev/urandom.
...unless we can somehow get /dev/random to be "secure enough".
> and after more arguments, more formally argued:
:
:
> | Even if I have a mechanism to wait for a reseed after each output and
> | reserve that output for me, I get at best R*2^160 bits for R reseeds,
> | rather than the 2^{R*160} bits I wanted.
> |
> | Note the yarrow-160 API and design doesn't allow me to wait for and
> | reserve the output of a reseed in a multi-tasking OS -- /dev/random
> | does.
Hmm. Most convincing argument I have heard so far. How much of a
practical difference does that make, though. With ultra-conservative
entropy estimation (eg, I am stirring in nanotime(9), but not making
any randomness estimates from it, so the device is getting some "free"
entropy.)?
PC's are pretty low-entropy devices; users who need lots of random
bits (as opposed to a steady supply of random numbers) are arguably
going to need to go to extraordinary lengths to get them; their
own statistical analysis is almost certainly going to be required.
Software that I am (partially) aware of that uses /dev/random usually
doesn't trust it too much anyway (qv PGP) (OpenSSH is an exception),
and programmers often come up with elabrate schemes to compel the
os to provide their requisite bits.
Folk who are generating OTP's for anything other than personal use
would be insane to use anything other than custom hardware such as
the ubiquitous geiger-counter or zener noise generator.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
w
Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions..
On Sat, 26 Aug 2000, Thomas Stromberg wrote: >Hopefully this thread will save the next poor soul who tries this. Indeed. >Now the question is, what ATA-100 RAID solutions are there that are fully >supported? I'd guess the Promise board, but the last time I guessed >(err.. last week), I got a supported chipset with an unsupported feature >:) Currently the only IDE RAID cards supported are the 3Ware ones. For a list of supported RAID hardware one should always check: http://people.freebsd.org/~msmith/RAID/index.html >Just so I don't go do anything stupid, anyone secretly working on >drivers for this behind our backs, or is it as good as junk? You could turn off the fake RAID in the BIOS, use it strictly as an ATA100 controller and use the vinum software RAID driver to do some real RAID. Info on that is available from: http://www.vinumvm.org/ Another alternative, and the one that I have been using, is to order one of the Arena series external IDE RAID boxes from raidweb.com. They're pretty cool little pieces of hardware. I'm also using IBM 75GXPs with mine. Brandon D. Valentine -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: yarrow & /dev/random
Mark writes:
> > I'm hoping to persuade the yarrow designers of the importance of
> > supporting /dev/random semantics for the unix community acceptance.
> > John Kelsey and I had some discussions along the lines of feeding
> > /dev/random output into yarrow, which I notice someone on here
> > considered.
>
> By "/dev/random semantics", are you referring to a blocking model
> that "counts" entropy and blocks when it beieves it is "empty"?
Yes. See the mbox archive I just put up at:
http://www.cypherspace.org/~adam/yarrow.txt
and [1] below for my arguments of why I agree with Kris and Jeroen's
earlier comments.
You really can't use yarrow to implement /dev/random as it is. Even
waiting for reseeds doesn't cut it. The issue is that everything goes
through the yarrow output function, which restricts yarrow to offering
computational security with at worst 2^n work factor to break because
it offers known plaintext the 0 block as the first output is E_k( 0 ).
> I am against the blocking model, as I believe that it goes against
> what Yarrow is trying to do. If the Yarrow authors argued otherwise,
> I'd listen.
Niels and John Kelsey were against it to initially, on the grounds
that computational security (160 bits -- or whatever the parameter is
with the ciphers you have plugged in) is in fact "good enough" in
practice even for 1024 bit RSA key generation.
(The argument has some validity; in practice a brute force attack
against RSA 1024 takes significantly less than 2^160 operations,
though the memory requirements are higher).
However it is not fair to impose that view on someone. People can
have legitmate reasons to need more entropy. Another very concrete
example is: say someone is using a yarrow-160 (3DES and SHA1)
implementation and they want to use an AES cipher with a 256 bit key
-- without the /dev/random API, you can't get 256 bit security, with
it you can.
OTPs and some algorithms offer information theoretic security, or you
may be using a larger key space symmetric construct than the yarrow
output size (using 256 doesn't solve that -- then they want a 512 bit
key). Worse people may already be using /dev/random for these
assumptions, so you risk breaking existing code's security by
replacing /dev/random with yarrow.
> > - yarrow design specifically calls for a hash functoin and a block
> > cipher -- you may easily be violating some of it's security
> > assumptions by plugging in the above.
>
> If I construct a specific hash function, is this still a problem?
No. Note my other comments on list about CBC-MAC are confused -- I
misread your code. It appears to be a keyless hash function, and as
Joeren noted it has some similarities to Davies-Meyer, but it's not
quite the same for the reasons he noted.
The main argument is against not using constructs which haven't
received lots of peer-review -- most crypto constructs are very
fragile to small design changes.
Adam
[1]
==
Here's a cut and paste from discussions on yarrow list summarising my
view:
| we still have a community acceptance problem: there remains the
| possibility that /dev/random could produce unconditionally secure
| ouput [IFF entropy estimates are conservative]; if we replace this
| with something which _can not_ be unconditionally secure, we face
| complaints.
and:
| So given that, it doesn't seem quite fair to pull the rug from under
| /dev/random users and replace it with a PRNG with quite different
| security assumptions. Users would have similar reasons to be upset if
| someone removed their /dev/random and symlinked it to /dev/urandom.
and after more arguments, more formally argued:
| Let's imagine we have a radioactive decay card, and we run it's
| outputs through a software de-skewing function to hide biases due to
| detector dead time and the expected distribution being different to
| that which we desire. Say we're convinced that the de-skewing
| function makes each bit of output uniformly distributed, to the extent
| that we're confident in using it's outputs as a OTP.
|
| Now what Yarrow-160 does is it takes k bits of OTP output, resets a 64
| bit counter (C) to 0 and uses counter mode from there. You can't get
| at the OTP outputs.
|
|
| Now my issue is if I had access to the OTP I could have had as many
| uniformly distributed bits as I wanted subject to their rate of
| production. But going through the Yarrow-160 output function I can
| never get information theoretic security. If I use it niavely I'll
| get at best 2^160 bits of security if no reseeds occur, and I may
| share these bits across multiple applications and with other users.
|
| Even if I have a mechanism to wait for a reseed after each output and
| reserve that output for me, I get at best R*2^160 bits for R reseeds,
| rather than the 2^{R*160} bits I wanted.
|
| Note the yarrow-160 API and design doesn't allow me to wait for and
| reserve the o
devfs patch for review
Hello,
I've made some fixes in the fs layer of new devfs. First version
of this patch was passed via Poul and new version includes parts of his
suggestions.
Here is a brief decription of the patch:
Rename de_dir to de_parent with appropritate code changes.
Implement proper logic and locking in the devfs_lookup().
Fix behaviour for '.' and '..' directories with corresponding changes
in the devfs_readdir().
Implement devfs_read() operation for directories.
Return proper mount owner in the devfs_statfs().
Fix panic related to the incorrect handling of root vnode.
Few cosmetic changes as well.
Code is still not SMP safe.
--
Boris Popov
http://www.butya.kz/~bp/
Index: devfs.h
===
RCS file: /home/ncvs/src/sys/fs/devfs/devfs.h,v
retrieving revision 1.2
diff -u -r1.2 devfs.h
--- devfs.h 2000/08/24 15:36:47 1.2
+++ devfs.h 2000/08/26 12:28:52
@@ -48,10 +48,12 @@
#defineDE_ORPHAN 0x1
#defineDE_DOT 0x2
#defineDE_DOTDOT 0x4
- struct dirent *de_dirent;
+ int de_type;
+ char * de_name;
+ int de_namelen;
TAILQ_ENTRY(devfs_dirent) de_list;
TAILQ_HEAD(, devfs_dirent) de_dlist;
- struct devfs_dirent *de_dir;
+ struct devfs_dirent *de_parent;
int de_links;
mode_t de_mode;
uid_t de_uid;
@@ -68,7 +70,6 @@
};
struct devfs_mount {
- struct vnode*dm_root; /* Root node */
struct devfs_dirent *dm_rootdir;
struct devfs_dirent *dm_basedir;
unsigneddm_generation;
@@ -84,6 +85,7 @@
#define VFSTODEVFS(mp) ((struct devfs_mount *)((mp)->mnt_data))
+#define VNTODEVFS(vp) ((struct devfs_dirent *)(vp)->v_data)
extern vop_t **devfs_vnodeop_p;
extern vop_t **devfs_specop_p;
@@ -93,6 +95,9 @@
void devfs_purge __P((struct devfs_dirent *dd));
struct devfs_dirent * devfs_vmkdir __P((char *name, int namelen,
struct devfs_dirent *dotdot));
+int devfs_allocv(struct devfs_dirent *de, struct mount *mp, struct vnode **vpp,
+ struct proc *proc);
+
#endif /* DEVFS_INTERN */
typedef void (*devfs_clone_fn) __P((void *arg, char *name, int namelen, dev_t
*result));
Index: devfs_devs.c
===
RCS file: /home/ncvs/src/sys/fs/devfs/devfs_devs.c,v
retrieving revision 1.3
diff -u -r1.3 devfs_devs.c
--- devfs_devs.c2000/08/24 15:36:47 1.3
+++ devfs_devs.c2000/08/26 11:49:49
@@ -46,16 +46,13 @@
{
int i;
struct devfs_dirent *de;
- struct dirent d;
- d.d_namlen = namelen;
- i = sizeof (*de) + GENERIC_DIRSIZ(&d);
+ i = sizeof (*de) + namelen + 1;
MALLOC(de, struct devfs_dirent *, i, M_DEVFS, M_WAITOK);
bzero(de, i);
- de->de_dirent = (struct dirent *)(de + 1);
- de->de_dirent->d_namlen = namelen;
- de->de_dirent->d_reclen = GENERIC_DIRSIZ(&d);
- bcopy(name, de->de_dirent->d_name, namelen + 1);
+ de->de_name = (char *)(de + 1);
+ de->de_namelen = namelen;
+ bcopy(name, de->de_name, namelen);
nanotime(&de->de_ctime);
de->de_mtime = de->de_atime = de->de_ctime;
de->de_links = 1;
@@ -63,36 +60,23 @@
}
struct devfs_dirent *
-devfs_vmkdir(char *name, int namelen, struct devfs_dirent *dotdot)
+devfs_vmkdir(char *name, int namelen, struct devfs_dirent *parent)
{
- struct devfs_dirent *dd;
struct devfs_dirent *de;
- dd = devfs_newdirent(name, namelen);
+ de = devfs_newdirent(name, namelen);
- TAILQ_INIT(&dd->de_dlist);
+ TAILQ_INIT(&de->de_dlist);
- dd->de_dirent->d_type = DT_DIR;
- dd->de_mode = 0755;
- dd->de_links = 2;
- dd->de_dir = dd;
-
- de = devfs_newdirent(".", 1);
- de->de_dirent->d_type = DT_DIR;
- de->de_dir = dd;
- de->de_flags |= DE_DOT;
- TAILQ_INSERT_TAIL(&dd->de_dlist, de, de_list);
-
- de = devfs_newdirent("..", 2);
- de->de_dirent->d_type = DT_DIR;
- if (dotdot == NULL)
- de->de_dir = dd;
- else
- de->de_dir = dotdot;
- de->de_flags |= DE_DOTDOT;
- TAILQ_INSERT_TAIL(&dd->de_dlist, de, de_list);
+ de->de_type = DT_DIR;
+ de->de_mode = 0755;
+ de->de_links = 2;
- return (dd);
+ if (parent) {
+ de->de_parent = parent;
+ TAILQ_INSERT_TAIL(&parent->de_dlist, de, de_list);
+ }
+ return (de);
}
static void
@@ -125,7 +109,6 @@
FREE(dd, M_DEVFS);
}
-
int
devfs_populate(struct devfs_mount *dm)
{
@@ -145,7 +128,7 @@
continue;
}
if (dev == NULL && de != NULL) {
-
Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions..
On Sat, 26 Aug 2000, Mike Smith wrote: > This is not an "IDE RAID" controller. It's an IDE controller with some > lame "RAID" software in the BIOS. We don't support this. Hopefully this thread will save the next poor soul who tries this. Just to put the final nail in the coffin.. I went ahead and installed on an old WDMA2 drive of mine, and put /var and /usr on what hopefully was a striped RAID. Well, I pulled the second drive offline, and.. it still booted up beautifully. So the striping in bios on the HPT-370 is indeed meaningless. C'est la vie. Now the question is, what ATA-100 RAID solutions are there that are fully supported? I'd guess the Promise board, but the last time I guessed (err.. last week), I got a supported chipset with an unsupported feature :) Just so I don't go do anything stupid, anyone secretly working on drivers for this behind our backs, or is it as good as junk? BTW, these IBM 75GXP drives off of the HPT-370 are amazingly fast for IDE. It was fast enough to fool me into thinking the striping might have been working. Ahh, the delusions hope brings. / Thomas > > For the buildbox here, I decided to go ahead with Soren's ATA-100 RAID > > suggestion, and bought an Abit KT7-RAID motherboard, which has an onboard > > Highpoint HPT-370 ATA-100 RAID. I'm using two 15G IBM 75GX drives on it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make buildworld (4->5) failed
hi,
Just experienced on 4.0-RELEASE and 4.1-STABLE (two days ago) following
error when tried to build current world.
===> secure/usr.bin/scp
cc -O -pipe -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include -c
/usr/src/secure/usr.bin/scp/../../../crypto/openssh/scp.c
cc -O -pipe -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include -o scp scp.o -lcrypto
-lutil -lz -L/usr/obj/usr/src/secure/usr.bin/scp/../../lib/libssh -lssh
gzip -cn /usr/src/secure/usr.bin/scp/../../../crypto/openssh/scp.1 > scp.1.gz
===> secure/usr.bin/ssh
cc -O -pipe -DNO_IDEA -I/usr/obj/usr/src/i386/usr/include
-DXAUTH_PATH=/usr/X11R6/bin/xauth -c
/usr/src/secure/usr.bin/ssh/../../../crypto/openssh/ssh.c
/usr/src/secure/usr.bin/ssh/../../../crypto/openssh/ssh.c: In function `x11_get_proto':
/usr/src/secure/usr.bin/ssh/../../../crypto/openssh/ssh.c:685: syntax error before `/'
*** Error code 1
Following patch fixed this for me:
Index: Makefile
===
RCS file: /home/ncvs/src/secure/usr.bin/ssh/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile2000/08/23 09:39:20 1.8
+++ Makefile2000/08/26 10:17:10
@@ -37,7 +37,7 @@
.include
.if defined(X11BASE)
-CFLAGS+= -DXAUTH_PATH=${X11BASE}/bin/xauth
+CFLAGS+= -DXAUTH_PATH=\"${X11BASE}/bin/xauth\"
.endif
LDADD+=-L${.OBJDIR}/../../lib/libssh -lssh -lcrypto -lutil -lz
--
/* Alexey Zelkin && [EMAIL PROTECTED] */
/* Tavric National University && [EMAIL PROTECTED]*/
/* Sysadmin/Developer && [EMAIL PROTECTED] */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: perlcc in current - xs_init and boot_DynaLoader
> > If i do a perlcc test.pl i get the folllowing , in CURRENT ? > > Must i define something beforehand, or is it broken ? > > I'll take a look... Looks like perl brokenness. The missing boot_DynaLoader is in DynaLoader.a, but there is no way of linking it in. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DPT revision....(broken drivers in -STABLE)
"Matthew N. Dodd" wrote: > Not having a test system with PCI DPT boards somewhat limits my ability to > wring these things out. I won't refuse a rackmounted compaq with PCI and > EISA slots and a brace of DPT and Smart2 RAID cards if someone sends me > one. Who knows? I might even be able to beat a bit on the management > tools then. Hi Matthew, If you remember - we spoke a while ago about some problems the DPT's had with the CAMified driver? - I did offer you a PCI DPT to try, but you thought you'd be OK at the time... I can hopefully still sort that out for you, if your interested - mail me off list... -Karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions..
This is not an "IDE RAID" controller. It's an IDE controller with some lame "RAID" software in the BIOS. We don't support this. > (excuse complete ignorance as far as IDE RAID below) > > For the buildbox here, I decided to go ahead with Soren's ATA-100 RAID > suggestion, and bought an Abit KT7-RAID motherboard, which has an onboard > Highpoint HPT-370 ATA-100 RAID. I'm using two 15G IBM 75GX drives on it. > > So after a long day of hacking at getting Cyclone Interchange to run under > FreeBSD, I decided to go for the install today w/ > 2820-CURRENT. I set up the RAID BIOS to stripe together both of > the drives, each as a master on their own channel. The controller shows up > in the FreeBSD bootup, as well as the drives with UDMA100, but.. > > While "lsdev" from the boot floppy shows one drive, in FreeBSD & fdisk > they show up as two 15G drives (ad4s1 & ad6s1) rather then a 30G > concatanated one. > > Am I missing something here? I've never done IDE RAID, let alone on-board > RAID. Are they striped, but show up as seperate due to the lack of > emulation? > > I went ahead and installed FreeBSD as a 6G partition.. and everything > looked good (and fast!), but when I rebooted, BootEasy saw the FreeBSD > bootblock, but it compained that it couldn't find any ufs > partition. However, "lsdev" from the floppies saw a ufs and swap > partition when checked. > > Do I have to install / on a non-RAIDed drive so that the boot loader has a > chance? > > In any case, much thanks goes to Soren for adding support for the > HPT-370 (and for the ATA drivers in general). I don't owe him just a > beer, but probably a keg or two for all the IDE boxes that I've installed > FreeBSD on :) > > > thomas r. stromberg [EMAIL PROTECTED] > senior systems administratorhttp://www.afterthought.org/ > research triangle commerce, inc. 1.919.657.1317 > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
