World broken
makeworld from -stable is broken. Needless to say this is completely and totally unacceptible. Would the people involved with the mtree and settofflags changes please get together and fix this right. cc -O -pipe -DMD5 -DSHA1 -DRMD160 -I/usr/obj/home/imp/FreeBSD/src/i386/usr/include -o mtree compare.o crc.o create.o excludes.o misc.o mtree.o spec.o verify.o -lmd misc.o: In function `flags_to_string': misc.o(.text+0x89): undefined reference to `fflagstostr' spec.o: In function `set': spec.o(.text+0x5f5): undefined reference to `strtofflags' *** Error code 1 I'm kludging mtree so that make buildworld isn't broken. Don't remove the kludge until such time as the underlying problems have been corrected. FLAME ON Can't people test the changes they make? I mean this one bit me in less than a minute for a buildworld. Less than a minute. GRUMP. I'm not amused. FLAME OFF I got here checking an UPDATING entry someone sent me saying that one needed to do a makeinstall in libc before this would succeed Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: randomdev entropy gathering is really weak
/dev/random should block if the system does not contain as much real entropy as the reader desires. Otherwise, the PRNG implementation will be the weakest link for people who have deliberately selected higher levels of protection from cryptographic attack. I don't want to rehash this thread from the beginning. Please go back, read the Yarrow paper, and recognise that Yarrow is not an entropy-counter, it is a cryptographically secure PRNG. The "count random bits and block" model does not apply. Then the current implementation cannot provide the usual semantics for /dev/random, while it can provide the semantics for /dev/urandom. As I understand it, /dev/random is supposed to provide true randomness suitable for generating keys of unlimited length, whereas /dev/urandom is supposed to provide cryptographically-strong randomness for general applications. If people want /dev/random to seed 1024-bit keys, /dev/random must be stronger than a 1024-bit key. DS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
On Sat, 22 Jul 2000, Mark Murray wrote:
So what it if I want/need 257 bits? :-)
Read them. You'll get them. If you want higher quality randomness than
Yarrow gives, read more than once. Do other stuff; play. Don't get stuck
in the "I have exhausted the randomness pool" loop; Yarrow does not play
that game.
I think you're missing the point. The only way I can get a random number
with more than n bits of entropy out of Yarrow-n is if I sample either
side of a reseed operation, which in general comes down to timing
guesswork and having to make assumptions about the PRNG implementation.
I understand that. :-)
Your are missing the point that it is not possible to get more than
the ${number-of-bits-ofrandomness} from any accumulator or PRNG. You
have to draw the line somewhere; The current implementation has it
at 256.
If you want to generate a cryptographic key of length n bits then you
really want n bits of entropy in the random source you're deriving it
from, otherwise your key is actually much weaker than advertised because
it's easier for the attacker to attack the state of the PRNG that derived
it than to attack the key itself.
Aha! That is where Yarrow wins. The paper argues it much better than
me: Section 4.1, the paragraph that begins "Yarrow takes a different
approach...".
We currently have Yarrow-256(Blowfish); wanna make it Yarrow-1024? I could
make it so.
Well, if we did that then how about generating 2048-bit keys? :-)
Where do you draw the line? I could make it Yarrow-N, only to have
someone insist on $((N+1)) in the very next breath.
With what we have, I am staking my career on the "uncrackability"
of Blowfish-256. If that holds then Yarrow is safe. (The old one
was MD5, with all its weaknesses such as birthday attacks, and
blocking added to compensate for folk raping it for internal state;
this blocking was compromised by the non-blocking /dev/urandom. The
design was too simple. The current design has multiple accumulators,
dual pools, and cryptographically overseen reseed mechanism; on top
of that, the output is encrypted in its own right, so there is added
protection against folk guessing the internal state.).
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: randomdev entropy gathering is really weak
The core of my complaint is that even though our old PRNG did crappy
entropy handling, we used to have such a method, which is now gone. I'd
like to see yarrow hang off /dev/urandom and have /dev/random tap directly
into the entropy pool (perhaps a third pool separate from Yarrow's
fast/slow) so I can generate my large keys safely.
By your own admission, the old system was bad; yet you still want
${it}? You'd like to see a programmer with less experience than
Schneier come up with a more secure algorithm than him?
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: randomdev entropy gathering is really weak
The core of my complaint is that even though our old PRNG did crappy
entropy handling, we used to have such a method, which is now gone. I'd
like to see yarrow hang off /dev/urandom and have /dev/random tap directly
into the entropy pool (perhaps a third pool separate from Yarrow's
fast/slow) so I can generate my large keys safely.
By your own admission, the old system was bad; yet you still want
${it}? You'd like to see a programmer with less experience than
Schneier come up with a more secure algorithm than him?
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: randomdev entropy gathering is really weak
Okay, using RSA keys wasn't the best example to pick, but Yarrow also seems easy to misuse in other cases: for example if you want to generate multiple 256-bit symmetric keys (or other random data) at the same time, each additional key after the first won't contain any additional entropy, so if you break the state of the PRNG at the time the first one was generated you get the others for free (until the thing reseeds). This design tradeoff is discussed in section 4.1 of the paper. Tweakable. That said, there is nothing to prevent the system admin from tweaking the Yarrow security parameters so that Yarrow will only spit out as many bits or pseudo-randomness as it gathers bits of entropy.[4] Well, I don't see a way to tune this without modifying the Yarrow design, since the entropy pool is intentionally decoupled from the output mechanism, and it seems like it would add additional (unnecessary) overhead anyway to use it in that fashion. Look at the sysctls (some improvements and documentation coming). Indications are we can probably get quite a lot of usable entropy from a standard system (on the order of many kilobytes per second - but I need to read more of the literature about processing of entropy samples) - in this case I think maintaining a third pool which is directly tapped by /dev/random, and leaving Yarrow sitting behind /dev/urandom is the way to go. I suspect you are missing the whole point of yarrow. Yarrow protects you from the compromises inherent in attackers injecting their own junk into the "third pool". 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
Netscape
Netscape 4.74 is already out but FreeBSD 4.1-RC2 contains 4.73 version yet. Will FreeBSD 4.1-RELEASE contains the last version (4.74) of Netscape Communicator and Navigator? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
On Sun, 23 Jul 2000, Mark Murray wrote:
Your are missing the point that it is not possible to get more than
the ${number-of-bits-ofrandomness} from any accumulator or PRNG. You
have to draw the line somewhere; The current implementation has it
at 256.
Uhh..a PRNG which hashes entropy samples with e.g. SHA1 and outputs the
digest once the bucket is "full" will have 1-epsilon bit of entropy per
1 bit of output. It may not be very fast depending on the rate of entropy
accumulation, but you can get as much entropy out of it as you want.
This is basically the model I am advocating for /dev/random. It's also the
alternative "basic design philosophy" described in the yarrow paper.
If you want to generate a cryptographic key of length n bits then you
really want n bits of entropy in the random source you're deriving it
from, otherwise your key is actually much weaker than advertised because
it's easier for the attacker to attack the state of the PRNG that derived
it than to attack the key itself.
Aha! That is where Yarrow wins. The paper argues it much better than
me: Section 4.1, the paragraph that begins "Yarrow takes a different
approach...".
See "important issue" number 2 on p6. Yarrow-derived numbers are only
"good for" 256 bits of strength. Modulo reseeds, Yarrow never accumulates
more than 256 bits of entropy. Therefore you are silly to use it for
applications which require more than 256 bits of randomness.
Where do you draw the line? I could make it Yarrow-N, only to have
someone insist on $((N+1)) in the very next breath.
Precisely, which is why /dev/random shouldn't use Yarrow, or any other
seeded-cipher PRNG.
With what we have, I am staking my career on the "uncrackability"
of Blowfish-256. If that holds then Yarrow is safe. (The old one
I'm not bothered about this. My point is that, by design, Yarrow is not
suitable as a replacement for /dev/random (/dev/urandom, yes).
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: randomdev entropy gathering is really weak
On Sun, 23 Jul 2000, Mark Murray wrote:
By your own admission, the old system was bad; yet you still want
${it}? You'd like to see a programmer with less experience than
Schneier come up with a more secure algorithm than him?
The old implementation was bad. The class of algorithm is not, as long as
you are conservative about your entropy estimates.
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: randomdev entropy gathering is really weak
On Sun, 23 Jul 2000, Mark Murray wrote: Okay, using RSA keys wasn't the best example to pick, but Yarrow also seems easy to misuse in other cases: for example if you want to generate multiple 256-bit symmetric keys (or other random data) at the same time, each additional key after the first won't contain any additional entropy, so if you break the state of the PRNG at the time the first one was generated you get the others for free (until the thing reseeds). This design tradeoff is discussed in section 4.1 of the paper. Tweakable. Doing a reseed operation with every output is going to be *very* computationally expensive. That said, there is nothing to prevent the system admin from tweaking the Yarrow security parameters so that Yarrow will only spit out as many bits or pseudo-randomness as it gathers bits of entropy.[4] Well, I don't see a way to tune this without modifying the Yarrow design, since the entropy pool is intentionally decoupled from the output mechanism, and it seems like it would add additional (unnecessary) overhead anyway to use it in that fashion. Look at the sysctls (some improvements and documentation coming). Please tell me which of the following sysctls will cause Yarrow to deactivate the keyed cipher feature that spits out a constant data stream independent of the state of the entropy pools: kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 100 kern.random.yarrow.slowthresh: 160 kern.random.yarrow.slowoverthresh: 2 Indications are we can probably get quite a lot of usable entropy from a standard system (on the order of many kilobytes per second - but I need to read more of the literature about processing of entropy samples) - in this case I think maintaining a third pool which is directly tapped by /dev/random, and leaving Yarrow sitting behind /dev/urandom is the way to go. I suspect you are missing the whole point of yarrow. Yarrow protects you from the compromises inherent in attackers injecting their own junk into the "third pool". Mark, I understand this stuff quite well - I'm not "missing the whole point of Yarrow" at all. Yarrow is a good system as far as it goes, but the authors themselves admit this limitation - you just can't use this tool in contexts it was not designed for. 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: Netscape
On Sun, 23 Jul 2000 [EMAIL PROTECTED] wrote: Netscape 4.74 is already out but FreeBSD 4.1-RC2 contains 4.73 version yet. Will FreeBSD 4.1-RELEASE contains the last version (4.74) of Netscape Communicator and Navigator? No. The ports tree has been frozen. 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: randomdev entropy gathering is really weak
In message [EMAIL PROTECTED], Kri s Kennaway writes: On Sat, 22 Jul 2000, Jeroen C. van Gelderen wrote: I agree that you need long RSA keys ... but the real discussion isn't really about key length but rather about the overall complexity of attacking the key: Okay, using RSA keys wasn't the best example to pick, but Yarrow also seems easy to misuse in other cases: for example if you want to generate multiple 256-bit symmetric keys (or other random data) at the same time, Kris, Obviously, if you need more randomness than a stock FreeBSD system can provide you with, you add hardware to give you more randomness. In other words, and more bluntly: Please shut up now, will you ? -- 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
Re: randomdev entropy gathering is really weak
This is basically the model I am advocating for /dev/random. It's also the
alternative "basic design philosophy" described in the yarrow paper.
Erm, read 4.1 again :-). The paragraph that begins "One approach..." is
the old approach. It is also the approach that you are advocating.
The next paragraph "Yarrow takes..." is Yarrow, and the current
implementation.
See "important issue" number 2 on p6. Yarrow-derived numbers are only
"good for" 256 bits of strength. Modulo reseeds, Yarrow never accumulates
more than 256 bits of entropy. Therefore you are silly to use it for
applications which require more than 256 bits of randomness.
Where do you draw the line? I could make it Yarrow-N, only to have
someone insist on $((N+1)) in the very next breath.
Precisely, which is why /dev/random shouldn't use Yarrow, or any other
seeded-cipher PRNG.
It should not use the old method, which is attackable for many
reasons that Schneier makes clear. (Effectively a 128 bit hash with
a reseed ("stir") every read. Can you spell "Iterative attack"? :-) ).
Where does that leave us?
How good were our old numbers? How many users have I screwed by implementing
that system?
How do we fix it? What accumulation algorithm do we use that does not
clue the reader into what the internal state is?
With what we have, I am staking my career on the "uncrackability"
of Blowfish-256. If that holds then Yarrow is safe. (The old one
I'm not bothered about this. My point is that, by design, Yarrow is not
suitable as a replacement for /dev/random (/dev/urandom, yes).
_My_ point is that the old system is broken, and that IMO Yarrow is a
good replacement. (I support my point by noting that Schneier is a far
better cryptographer than I, and he designed the algorithm that I
implemented).
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: randomdev entropy gathering is really weak
On Sun, 23 Jul 2000, Poul-Henning Kamp wrote: Obviously, if you need more randomness than a stock FreeBSD system can provide you with, you add hardware to give you more randomness. This won't help if it's fed through Yarrow. In other words, and more bluntly: Please shut up now, will you ? No. There are legitimate technical issues to be resolved here. If you don't want to participate, press 'D' and move on with your life. 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: randomdev entropy gathering is really weak
On Sun, 23 Jul 2000, Mark Murray wrote:
Erm, read 4.1 again :-). The paragraph that begins "One approach..." is
the old approach. It is also the approach that you are advocating.
The next paragraph "Yarrow takes..." is Yarrow, and the current
implementation.
"The strength of the first approach is that, if properly designed, it is
possible to get unconditional security from the PRNG."
This is a good thing :-)
It should not use the old method, which is attackable for many
reasons that Schneier makes clear. (Effectively a 128 bit hash with
a reseed ("stir") every read. Can you spell "Iterative attack"? :-) ).
Where does that leave us?
How good were our old numbers? How many users have I screwed by
implementing that system?
Please understand that this is not a personal attack - I appreciate your
work, and welcome it in FreeBSD. My concern is with what Yarrow does not
do, but which FreeBSD needs: a PRNG which is capable of generating
arbitrarily large keys.
How do we fix it? What accumulation algorithm do we use that does not
clue the reader into what the internal state is?
I suggest we ask Bruce Schneier instead of bantering back and forth about
the issue. I claim (supported by the quote above) that it's possible to
implement such a system securely and have it co-exist with Yarrow.
_My_ point is that the old system is broken, and that IMO Yarrow is a
good replacement. (I support my point by noting that Schneier is a far
better cryptographer than I, and he designed the algorithm that I
implemented).
Yarrow is a good replacement for /dev/urandom. However it doesn't provide
features which I believe are necessary, namely the ability to generate
high-entropy keys of arbitrary size, without severely impacting on PRNG
performance by constantly reseeding.
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: randomdev entropy gathering is really weak
In message [EMAIL PROTECTED], Kri s Kennaway writes: On Sun, 23 Jul 2000, Poul-Henning Kamp wrote: Obviously, if you need more randomness than a stock FreeBSD system can provide you with, you add hardware to give you more randomness. This won't help if it's fed through Yarrow. Nobody has said anything about forcing you to use Yarrow, have they ? In other words, and more bluntly: Please shut up now, will you ? No. There are legitimate technical issues to be resolved here. If you don't want to participate, press 'D' and move on with your life. I think the general concensus is that all legitimate technical issues has been resolved and that we are stuck with a small band of merry men wasting bandwidth by repeatedly rehashing the obvious: "Any source of random bits has a finite capacity and you should not exceed that capacity." I have not seen any new information in the last N emails from you. -- 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
Re: Netscape
Kris Kennaway wrote: On Sun, 23 Jul 2000 [EMAIL PROTECTED] wrote: Netscape 4.74 is already out but FreeBSD 4.1-RC2 contains 4.73 version yet. Will FreeBSD 4.1-RELEASE contains the last version (4.74) of Netscape Communicator and Navigator? No. The ports tree has been frozen. If there will be "FreeBSD 4.1-RC3+" will it contains the newer version of Netscape? Are the fixed in Netscape 4.74 bugs not critical for release? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netscape
On Sun, 23 Jul 2000 [EMAIL PROTECTED] wrote: If there will be "FreeBSD 4.1-RC3+" will it contains the newer version of Netscape? No - the ports collection for 4.1-RELEASE has been frozen. Are the fixed in Netscape 4.74 bugs not critical for release? Who knows? I don't know of any changelog for Netscape. 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: Netscape
[EMAIL PROTECTED] wrote: Kris Kennaway wrote: On Sun, 23 Jul 2000 [EMAIL PROTECTED] wrote: Netscape 4.74 is already out but FreeBSD 4.1-RC2 contains 4.73 version yet. Will FreeBSD 4.1-RELEASE contains the last version (4.74) of Netscape Communicator and Navigator? No. The ports tree has been frozen. If there will be "FreeBSD 4.1-RC3+" will it contains the newer version of Netscape? Are the fixed in Netscape 4.74 bugs not critical for release? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message One of the big things they fixed is LDAP. You can now use the ldap search facility in the address book. Lars To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netscape
Kris Kennaway wrote: On Sun, 23 Jul 2000 [EMAIL PROTECTED] wrote: If there will be "FreeBSD 4.1-RC3+" will it contains the newer version of Netscape? No - the ports collection for 4.1-RELEASE has been frozen. Are the fixed in Netscape 4.74 bugs not critical for release? Who knows? I don't know of any changelog for Netscape. Go to http://home.netscape.com/eng/mozilla/4.7/relnotes/ there is the release notes for all 4.7x versions for all platforms. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
Obviously, if you need more randomness than a stock FreeBSD system can provide you with, you add hardware to give you more randomness. This won't help if it's fed through Yarrow. *BTTT!* Wrong. A good hardware RNG when fed at a high-enough rate through Yarrow can easily produce a continuous stream of what you need. (If we take that route, the current implementation may need to be tweaked a bit to stop reseeding after a period of unuse to avoid hammering the kernel too much; this needs careful thought). Been thinking about this; the current implemnetation runs continuously (thanks to taskqueue(9)). There is no reason that it couldn't be made (somewhat) use-driven, so that it works harder at harvesting when being used heavily. This may make it slower, but it would hurt the kernel a bit less when not in use. 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: randomdev entropy gathering is really weak
On Sun, 23 Jul 2000, Poul-Henning Kamp wrote: Obviously, if you need more randomness than a stock FreeBSD system can provide you with, you add hardware to give you more randomness. This won't help if it's fed through Yarrow. *BTTT!* Wrong. A good hardware RNG when fed at a high-enough rate through Yarrow can easily produce a continuous stream of what you need. (If we take that route, the current implementation may need to be tweaked a bit to stop reseeding after a period of unuse to avoid hammering the kernel too much; this needs careful thought). 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: randomdev entropy gathering is really weak
This design tradeoff is discussed in section 4.1 of the paper. Tweakable. Doing a reseed operation with every output is going to be *very* computationally expensive. Tradeoff. What do you want? Lightning fast? Excessive security? Balance it out. Well, I don't see a way to tune this without modifying the Yarrow design, since the entropy pool is intentionally decoupled from the output mechanism, and it seems like it would add additional (unnecessary) overhead anyway to use it in that fashion. Look at the sysctls (some improvements and documentation coming). Please tell me which of the following sysctls will cause Yarrow to deactivate the keyed cipher feature that spits out a constant data stream independent of the state of the entropy pools: kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 100 kern.random.yarrow.slowthresh: 160 kern.random.yarrow.slowoverthresh: 2 None, but very paranoid reseed intervals can be set if required. (Requires more entropy-harvesting, but doable). I suspect you are missing the whole point of yarrow. Yarrow protects you from the compromises inherent in attackers injecting their own junk into the "third pool". Mark, I understand this stuff quite well - I'm not "missing the whole point of Yarrow" at all. The acknowlegment that I am looking for is that the old, simple "gather entropy, stir with hash, serve" model is inadequate IMO, and I have not seen any alternatives. Yarrow is a good system as far as it goes, but the authors themselves admit this limitation - you just can't use this tool in contexts it was not designed for. Goes for any tool; a universal truth. I'm trying to come up with a better tool that what was, and I believe that I have, and I am perhaps misunderstanding folks' motives in shouting for the blocking model. In quite a few cases, it has been a very obvious non-understanding of what Yarrow is (I apologise for lumping you in this category). I'll relent somewhat if a secure entropy distilling algorithm could be found; one which stands up to crypanalysis. Will you relent a step or two if I can get the entropy harvesting _rate_ high enough? :-) 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: randomdev entropy gathering is really weak
On Sun, 23 Jul 2000, Mark Murray wrote: This design tradeoff is discussed in section 4.1 of the paper. Tweakable. Doing a reseed operation with every output is going to be *very* computationally expensive. Tradeoff. What do you want? Lightning fast? Excessive security? Balance it out. Thinking about it further, I dont think Yarrow can even do this (introduce entropy into every output value) without bypassing the block cipher. And if you reseed with every 256 bits of output then you're vulnerable to an iterative guessing attack because the fast pool won't have much in it. So if we want to use the Yarrow "backend" we'd have to basically reduce it to the system I describe below. The acknowlegment that I am looking for is that the old, simple "gather entropy, stir with hash, serve" model is inadequate IMO, and I have not seen any alternatives. There are two other models which rate "pretty well-designed" in the Yarrow paper: the cryptlib and PGP PRNGs. I don't know what their properties are right now (the cryptlib one is described in the paper on PRNG cryptanalysis). I'll relent somewhat if a secure entropy distilling algorithm could be found; one which stands up to crypanalysis. Well, a simple scheme which doesn't seem to suffer from any of the vulnerabilities discussed in the schneier papers is to accumulate entropy in a pool, and only return output when the pool is full. i.e. the PRNG would either block or return 0 bytes of data, or a full pool's worth. Will you relent a step or two if I can get the entropy harvesting _rate_ high enough? :-) If we get the entropy pools filling fast enough that the reseed is triggering close to every 256 bits of output then it becomes much less of a concern (but it's still there, because reseeding happens asynchronously with respect to PRNG output). However I think that in practice this will be too heavy on the CPU (unless we weaken the reseed operation) and make dd if=/dev/urandom of=/dev/null a very effective local user DoS :-( 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: randomdev entropy gathering is really weak
The acknowlegment that I am looking for is that the old, simple "gather entropy, stir with hash, serve" model is inadequate IMO, and I have not seen any alternatives. There are two other models which rate "pretty well-designed" in the Yarrow paper: the cryptlib and PGP PRNGs. I don't know what their properties are right now (the cryptlib one is described in the paper on PRNG cryptanalysis). Do you have copies of the articles concerned? I'd surely appreciate a photocopy of the relevant pages if you don't mind! :-) I'll relent somewhat if a secure entropy distilling algorithm could be found; one which stands up to crypanalysis. Well, a simple scheme which doesn't seem to suffer from any of the vulnerabilities discussed in the schneier papers is to accumulate entropy in a pool, and only return output when the pool is full. i.e. the PRNG would either block or return 0 bytes of data, or a full pool's worth. Hmm. Timing attacks? Known-input attacks? Will you relent a step or two if I can get the entropy harvesting _rate_ high enough? :-) If we get the entropy pools filling fast enough that the reseed is triggering close to every 256 bits of output then it becomes much less of a concern (but it's still there, because reseeding happens asynchronously with respect to PRNG output). However I think that in practice this will be too heavy on the CPU (unless we weaken the reseed operation) and make dd if=/dev/urandom of=/dev/null a very effective local user DoS :-( The dd if=/dev/urandom of=/dev/null is _already_ a doozy of a dos. Likewise a fork-bomb, a /tmp-filler, likewise a whole bunch of things much worse. Heck, you can hurt your system with cat /dev/zero /dev/null. Asynchonous reseeding _improves_ the situation; the attacker cannot force it to any degree of accuracy, and if he has the odds stacked heavily against him that each 256-bits of output will have an associated reseed, it makes his job pretty damn difficult. 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: randomdev entropy gathering is really weak
In message [EMAIL PROTECTED], Stefan `Sec` Zehl writes: Assume I want to encrypt a message by XOR'ing with randomness. If I then exchange my keys securely, the message is uncrackable. With the current approach it has a 256bits key. This is, in my eyes, not good. Although yarrow is nice, It's suited for any kind of key generation. The first law of crypto clearly states: "Know what you're doing". There is no way around that law. We cannot load down FreeBSD with impossibly heavy computations to cater for any and all conceiveable application of random numbers. In particular I fear that the current implementation already has killed battery lifetimes on laptops :-( -- 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
4.1-RC panic when loading dnetc (distributed.net client)
I am using the 4.63 dnetc native FreeBSD version of the distributed.net client. Here is what happens: --- Local package initialization: dnetc Fatal trap 12: page fault while in kernel mode fault virtual address = 0xe0aedffc fault code = supervisor read, page not present instruction pointer = 0x8:0xc01871cf stack pointer = 0x10:0xc8a13dcc frame pointer = 0x10:0xc8a13ddc code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor flags = interrupt enabled, resume, IOPL = 0 current process = 281(dnetc) interrupt mask = none panic: page fault --- This machine is a rebuilt world (07212000) with standard kernel optimizations COPTFLAGS = -O -pipe and CFLAGS = -O -pipe -march=pentiumpro. I am having a hard time getting into my system to disable dnetc and see if I can get more details. The CD ROM I burned with a stable from about two weeks back ignores my key entry to go to a commad prompt so that I can load the kernel off of the CD and then boot into the OS (manually). Enter is all that works and it sends me to kernel config and then sysinstall. I added "boot" to /boot/loader.rc, so I don't get a command prompt option at all when I boot my machine normally. I just thought I should report this bug. Thanks, Tom Veldhouse [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make installkernel broken ? (was Re: World broken)
Original Message On 7/23/00, 7:19:03 AM, Warner Losh [EMAIL PROTECTED] wrote regarding World broken: cc -O -pipe -DMD5 -DSHA1 -DRMD160 -I/usr/obj/home/imp/FreeBSD/src/i386/usr/include -o mtree compare.o crc.o create.o excludes.o misc.o mtree.o spec.o verify.o -lmd misc.o: In function `flags_to_string': misc.o(.text+0x89): undefined reference to `fflagstostr' spec.o: In function `set': spec.o(.text+0x5f5): undefined reference to `strtofflags' *** Error code 1 I'm kludging mtree so that make buildworld isn't broken. Don't remove the kludge until such time as the underlying problems have been corrected. Dear FreeBSd'ers, The good news: I have just made buildworld (sources cvsup'ed today), and made buildkernel with no problems. The (moderately) bad news: make installkernel fails: /usr/src # make installkernel cd /usr/obj/usr/src/sys/GENERIC; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386 /usr/bin LIBRARY_PATH=/usr/obj/usr/src/i386/usr/lib:/usr/obj/usr/src/i386/usr/ lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/us r/obj/usr/src/i386/usr/games:/tmp/install.12899 MACHINE=i386 KERNEL=GENERIC make KERNEL=GENERIC install make: not found *** Error code 127 Stop in /usr/src. *** Error code 1 Stop in /usr/src. It is a few weeks since I last made a -CURRENT world, so I have been cautious enough, and I have chosen the buildkernel and installkernel targets -- as if I were updating from -STABLE. Since I am already well "flamed" (~ 35/40 °C down here), please be so kind as not to flame me :-) Best regards, Salvo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make installkernel broken ? (was Re: World broken)
Salvo Bartolotta wrote: Dear FreeBSd'ers, The good news: I have just made buildworld (sources cvsup'ed today), and made buildkernel with no problems. The (moderately) bad news: make installkernel fails: Already fixed. Please re-cvsup. Note that the kernel will be called 'kernel' (again)! If you used the installkernel before and have modified your /boot/loader.conf, make sure it's booting /kernel again. HTH, -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
David Schwartz wrote: /dev/random should block if the system does not contain as much real entropy as the reader desires. Otherwise, the PRNG implementation will be the weakest link for people who have deliberately selected higher levels of protection from cryptographic attack. I don't want to rehash this thread from the beginning. Please go back, read the Yarrow paper, and recognise that Yarrow is not an entropy-counter, it is a cryptographically secure PRNG. The "count random bits and block" model does not apply. Then the current implementation cannot provide the usual semantics for /dev/random, while it can provide the semantics for /dev/urandom. As I understand it, /dev/random is supposed to provide true randomness suitable for generating keys of unlimited length, whereas /dev/urandom is supposed to provide cryptographically-strong randomness for general applications. If people want /dev/random to seed 1024-bit keys, /dev/random must be stronger than a 1024-bit key. 1. The current /dev/random cannot do it, it's less secure than Yarrow for a variety of reasons. So we have a net improvement anyway. Thanks Mark. 2. Most people do not want to seed 1024-bit keys as outlined in another mail in this thread. If they *understand* the issues involved they will realize that 2^256 complexity is plenty uncrackable for all practical purposes. FreeBSD is about practical purposes IMHO. 3. Yarrow can be modified to just do this, should someone think this is neccessary. Read the paper and think of what happens when you set Pg to 1/(2^(k/3)). (Note that the paper restricts this value to 1 = Pg but that's of no importance here.) ** This is overly conservative for most applications I can think of; Even a multi-million dollar financial transactioning system will be practically secure when Pg is set to 1. 4. Nothing prevents you from adapting Yarrow so that current /dev/random semantics are preserved, making Yarrow even better. It can be done with the current design it's just not very beneficial to do it. 5. Yarrow was designed as a better replacement for most any PRNG by a couple of bright cryptographers. Can you do better than that? 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: randomdev entropy gathering is really weak
Kris Kennaway wrote: On Sun, 23 Jul 2000, Mark Murray wrote: This design tradeoff is discussed in section 4.1 of the paper. Tweakable. Doing a reseed operation with every output is going to be *very* computationally expensive. Tradeoff. What do you want? Lightning fast? Excessive security? Balance it out. Thinking about it further, I dont think Yarrow can even do this (introduce entropy into every output value) without bypassing the block cipher. Why not? And if you reseed with every 256 bits of output then you're vulnerable to an iterative guessing attack because the fast pool won't have much in it. You would block until the pool is filled with entropy. [...] There are two other models which rate "pretty well-designed" in the Yarrow paper: the cryptlib and PGP PRNGs. I don't know what their properties are right now (the cryptlib one is described in the paper on PRNG cryptanalysis). Fortunately you don't need them :-) I'll relent somewhat if a secure entropy distilling algorithm could be found; one which stands up to crypanalysis. Well, a simple scheme which doesn't seem to suffer from any of the vulnerabilities discussed in the schneier papers is to accumulate entropy in a pool, and only return output when the pool is full. i.e. the PRNG would either block or return 0 bytes of data, or a full pool's worth. And you can make Yarrow do just that. Not very practical but you can do it. You effectively set Pg to 1/(2^(k/3)). Will you relent a step or two if I can get the entropy harvesting _rate_ high enough? :-) If we get the entropy pools filling fast enough that the reseed is triggering close to every 256 bits of output then it becomes much less of a concern (but it's still there, because reseeding happens asynchronously with respect to PRNG output). Reseeds do not *have* to happen asynchronously as pointed out above. What is of importance is that you *cannot* forcibly trigger a reseed without there being enough entropy in the pools. There is nothing against having /dev/random block until the pools have accumulated enough entropy. 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: randomdev entropy gathering is really weak
5. Yarrow was designed as a better replacement for most any PRNG by a couple of bright cryptographers. Can you do better than that? Nope, I agree. Ignore my previous objections. DS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netscape
Are the fixed in Netscape 4.74 bugs not critical for release? Who knows? I don't know of any changelog for Netscape. The release notes are at http://home.netscape.com/eng/mozilla/4.7/relnotes/unix-4.74.html#whatnew . The only change that looks like it applies to us is a new feature to delete all your e-mail when exiting the program. I haven't tried it, but it seems to me that making an alias like alias netscape='/usr/local/bin/netscape rm -rf ~/nsmail/*' or putting something similar in your .logout would achieve the same thing. -- Trevor Johnson http://jpj.net/~trevor/gpgkey.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.1-RC panic when loading dnetc (distributed.net client)
On Sun, 23 Jul 2000, Daniel Baker wrote: Thomas, Just use "boot -s" to boot into single user mode so that you can disable the dnetc.sh script before you get into multiuser mode when all the rc.d scripts are executed. How long has the machine that you're using been alive for? Has it had stability problems in the past? Is it under heavy load? Are the CPU fan(s) running? Running since Friday. This machine has had FreeBSD 4.0-CURRENT in the past, as well as STABLE. It has also had Linux running on it (various distros). None of the above have given problems with dnetc in the past. The machine is not under any load. It is my development machine and the error occurs during boot. All the fans are running. It is a Compaq Presario 5868 (AMD Athlon 600 with the AMD751/VIA686a chipsets). 128MB RAM SDRAM 100. Windows 2000 also runs on this machine and exhibits no problems - other than the expected :) The machine had been running fine since Friday (I upgraded world to 4.1 RC-x). I share dnetc buffer files on a FAT32 partition so that my Windows2000 dnetc client can use the same files (I don't know if this could make a difference). I have another machine running dnetc and it seems to work fine (4.1-RC 1 from ~ 7-17). I was not able to get into FreeBSD to find out if anything else was amis. The CD I burned from a snapshot would not allow me to get to a prompt to boot into single user mode. Something is wrong with that days image. The image is from around July 7th. I had edited my /boot/loader.rc to automatically boot without the prompt - so I can not enter single user mode that way either. Perhaps I will download a more recent floppy set and see if I can get in with them. Tom Veldhouse [EMAIL PROTECTED] Daniel -- [EMAIL PROTECTED] - Chief Operations Administrator - distributed.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Now make installworld is broken
Current is a damned joke these days. With sources fetched at 10:00 PDT (17:00 GMT) today: blake# make installworld mkdir -p /tmp/install.232 for prog in [ awk cat chflags chown date echo egrep find grep install ln make makewhatis mv perl rm sed sh sysctl test true u name wc zic; do cp `which $prog` /tmp/install.232; done cd /local0/src; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/local0/src/i386/usr/libexec:/usr/obj/local0/src/i386/usr/bin LIBRARY_PATH=/usr/obj/local0/src/i386/usr/lib:/usr/obj/local0/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/local0/src/i386/usr/li bexec PERL5LIB=/usr/obj/local0/src/i386/usr/libdata/perl/5.6.0 PATH=/usr/obj/local0/src/i386/usr/sbin:/usr/obj/local0/src/i38 6/usr/bin:/usr/obj/local0/src/i386/usr/games:/tmp/install.232 make -f Makefile.inc1 reinstall -- Making hierarchy -- cd /local0/src; make -f Makefile.inc1 hierarchy cd /local0/src/etc; make distrib-dirs mtree -deU -f /local0/src/etc/mtree/BSD.root.dist -p / mtree:No such file or directory *** Error code 1 John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa ^^ Current is making me feel very intelligent. :-( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DHCP client problem?
Reversing that patch fixes it. Since the source for this is in contrib, I presume we need to send this back to ISC rather than patch it in our tree? Tatsumi Hosokawa wrote: At Fri, 21 Jul 2000 17:22:15 -0700 (PDT), Nick Sayer [EMAIL PROTECTED] wrote: Something changed very recently in the dhcp client stuff that seems to have broke my -current machine's ability to be a dhcp client. The symptom is that I see ifconfig: netmask 255.255.255.224: bad value come out of the script invocation, and the ip address does not get set. My -current machine (cvsupped only a few hours ago) has the same problem. If I echo out the parameters and type in THE EXACT SAME command line myself, it works just fine. I suspect some sort of bizarre quoting conspiracy. :-) Maybe here? (in http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/isc-dhcp/client/scripts/freebsd.diff?r1=1.11r2=1.12) - if [ x$old_ip_address = x ] || [ x$old_ip_address != x$new_ip_address ] || \ - [ x$reason = xBOUND ] || [ x$reason = xREBOOT ]; then -ifconfig $interface inet $new_ip_address $new_netmask_arg \ - $new_broadcast_arg $medium + if [ "x$old_ip_address" = "x" ] || [ "x$old_ip_address" != "x$new_ip_address" ] || \ + [ "x$reason" = "xBOUND" ] || [ "x$reason" = "xREBOOT" ]; then +ifconfig "$interface" inet "$new_ip_address" "$new_netmask_arg" \ + "$new_broadcast_arg" "$medium" --- Tatsumi Hosokawa [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: trafshow doesn't work?
Fallout from the malloc.conf changes. tcpdump has the same bug. Could this break dhclient as well? 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[2]: Journaling Filesystem ?
The big win with a journaling FS is when you have to reboot the system. With Softupdates, you still have to fsck. On a large FS (say half a terabyte) that can take hours. With a JFS, you simply play the log forward and continue. -joe -- Joe McGuckin ViaNet Communications 994 San Antonio Road Palo Alto, CA 94303 Phone: 650-969-2203 Cell: 650-207-0372 Fax: 650-969-2124 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Now make installworld is broken
In article [EMAIL PROTECTED],
John Polstra [EMAIL PROTECTED] wrote:
Current is a damned joke these days. With sources fetched at 10:00
PDT (17:00 GMT) today:
blake# make installworld
mkdir -p /tmp/install.232
for prog in [ awk cat chflags chown date echo egrep find grep install ln make
makewhatis mv perl rm sed sh sysctl test true u
name wc zic; do cp `which $prog` /tmp/install.232; done
cd /local0/src; MAKEOBJDIRPREFIX=/usr/obj
COMPILER_PATH=/usr/obj/local0/src/i386/usr/libexec:/usr/obj/local0/src/i386/usr/bin
LIBRARY_PATH=/usr/obj/local0/src/i386/usr/lib:/usr/obj/local0/src/i386/usr/lib
OBJFORMAT_PATH=/usr/obj/local0/src/i386/usr/li
bexec PERL5LIB=/usr/obj/local0/src/i386/usr/libdata/perl/5.6.0
PATH=/usr/obj/local0/src/i386/usr/sbin:/usr/obj/local0/src/i38
6/usr/bin:/usr/obj/local0/src/i386/usr/games:/tmp/install.232 make -f Makefile.inc1
reinstall
--
Making hierarchy
--
cd /local0/src; make -f Makefile.inc1 hierarchy
cd /local0/src/etc; make distrib-dirs
mtree -deU -f /local0/src/etc/mtree/BSD.root.dist -p /
mtree:No such file or directory
*** Error code 1
I believe the problem is as follows. In revision 1.155
of src/Makefile.inc1, mtree was moved from cross-tools to
bootstrap-tools. Then in revision 1.161 it was removed from
bootstrap-tools but was not put it back into cross-tools. The
appended patch will probably fix it, but I'm not going to commit it
until it has been tested with a FULL make world AS I WISH A FEW OTHER
COMMITTERS WOULD LEARN TO DO. If any committer gets it tested before
I do, please feel free to commit it.
John
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.162
diff -u -r1.162 Makefile.inc1
--- Makefile.inc1 2000/07/23 17:38:32 1.162
+++ Makefile.inc1 2000/07/23 21:15:16
@@ -579,7 +579,8 @@
cross-tools:
.for _tool in ${_aout_tools} ${_btxld} ${_elf2exe} usr.bin/genassym \
-usr.bin/gensetdefs gnu/usr.bin/binutils usr.bin/objformat gnu/usr.bin/cc
+usr.bin/gensetdefs gnu/usr.bin/binutils usr.bin/objformat gnu/usr.bin/cc \
+usr.sbin/mtree
cd ${.CURDIR}/${_tool}; \
${MAKE} obj; \
${MAKE} depend; \
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Now make installworld is broken
John Polstra wrote: -- Making hierarchy -- cd /local0/src; make -f Makefile.inc1 hierarchy cd /local0/src/etc; make distrib-dirs mtree -deU -f /local0/src/etc/mtree/BSD.root.dist -p / mtree:No such file or directory *** Error code 1 My bad. I removed mtree from the bootstrap-tools after reverting the use of the -L switch. I forgot to re-add mtree to the list of saved binaries during installworld. It's fixed now (famous last words)... -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Re[2]: Journaling Filesystem ?
On Sun, 23 Jul 2000, Joe McGuckin wrote: The big win with a journaling FS is when you have to reboot the system. With Softupdates, you still have to fsck. On a large FS (say half a terabyte) that can take hours. No you don't. Your filesystem will be in a consistent state except for blocks which are marked used but are not, so you can fsck in the background at the expense of not having all of your free space available at startup. Having said that, I don't know that this procedure has been well tested in practise, so you're advised to use caution when testing it :-) 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
Driver for Adaptec/Dell/HP PCI:SCSI RAID adapters available
--- Blind-Carbon-Copy X-Mailer: exmh version 2.1.1 10/15/1999 To: [EMAIL PROTECTED] Subject: Driver for Adaptec/Dell/HP PCI:SCSI RAID adapters available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Jul 2000 15:53:40 -0700 From: Mike Smith [EMAIL PROTECTED] The first BETA version of the 'aac' driver for the Adaptec AAC-364 'Jalapeno' and AAC-3642 'Jalapeno II' RAID adapters is available from http://people.freebsd.org/~msmith/RAID/index.html#adaptec These adapters are OEMed by Dell as the PERC 2/QC and by HP as the HP NetRAID-4m. The driver has been tested on FreeBSD 5.0-CURRENT, but is known to build and should function just fine on 4.0-STABLE as well. Testers are encouraged to contact me for assistance, or to report on progress. Thanks go to BSDi for funding the development of this driver, and Adaptec for supplying me with a profusion of sample adapters and the source for their Linux driver to work from. Particular thanks to Justin Gibbs for finding the right person at Adaptec to make all this happen. - -- ... 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] --- End of Blind-Carbon-Copy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netscape
On Sun, 23 Jul 2000, Trevor Johnson wrote: Are the fixed in Netscape 4.74 bugs not critical for release? Who knows? I don't know of any changelog for Netscape. The release notes are at http://home.netscape.com/eng/mozilla/4.7/relnotes/unix-4.74.html#whatnew . The only change that looks like it applies to us is a new feature to delete all your e-mail when exiting the program. I haven't tried it, but it seems to me that making an alias like alias netscape='/usr/local/bin/netscape rm -rf ~/nsmail/*' or putting something similar in your .logout would achieve the same thing. If you are talking about Expunging, I believe to netscape that means it actually goes through and deletes the emails that you have deleted... (uhh..) When I used to use netscape for my email, netscape wouldn't release hard disk space when you delete emails until you empty trash *and* run expunge. Why deleting from trash doesn't do it, I don't know, but netscape got to be too buggy for me to use for an email client about a year ago. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel compile failure without -O option
On 2000-Jul-19 19:31:12 -0700, John Polstra [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
Hellmuth Michaelis [EMAIL PROTECTED] wrote:
In the process of tracing down the problem of the kernel panic when booting
a kernel with pcvt enabled, i tried to compile a kernel without the -O
option to gcc and got this compile failure (sources from 18.7.2000 9:00 MET):
cc -c -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include
-D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2
-fomit-frame-pointer ../../i386/i386/atomic.c
In file included from ../../i386/i386/atomic.c:47:
machine/atomic.h: In function `atomic_set_char':
machine/atomic.h:106: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_clear_char':
machine/atomic.h:107: inconsistent operand constraints in an `asm'
[...]
I have seen that same problem recently in a slightly different
context. After staring at the code for a very long time, I could
only conclude that the problem was a bug in gcc.
Last year I did some testing of atomic.h with a variety of gcc
versions (and, following a prod from bde, at a variety of optimisation
levels). At the time, I had great difficulty finding a set of
constraints that would work with both gcc 2.7.2 and egcs, with and
without optimisation.
Attached is a patch to /sys/i386/include/atomic.h,v 1.11 that I
believe solves the problem. This is an adaption of what I did last
year, to include some of Bruce's comments. At this stage, I've only
checked it against gcc version 2.95.2 19991024 (release) - at it
appears in 4.0 and the latest -current, with -O0, -O1 and -O2. An
earlier version[1] worked with 2.7.2, 2.8.1 and ecgs 1.?. I hope to
be able to check it on gcc 2.7.2 and maybe gcc 2.8.1 tonight.
Note that in theory, gcc 2.7.2 needs a second read-only argument with
a "0" constraint. In practice, this doesn't seem to be necessary
since the write-only argument is volatile memory and therefore the
compiler can't optimize out any preceeding read. This shouldn't be
required for later compiler versions since the first argument is
explicitly read-write.
[1] This was sent to Bruce early last October. The changes since
then are:
- Correct `char' case to specify "q" constraint
- Cast result of not (~) to ensure correct operand type.
- Specify `w' in `short' case to correctly print the 16-bit register.
Peter
--- /3.0/cvs/src/sys/i386/include/atomic.h Thu May 11 01:27:24 2000
+++ atomic.hMon Jul 24 08:02:16 2000
@@ -62,7 +62,7 @@
* This allows kernel modules to be portable between UP and SMP systems.
*/
#if defined(KLD_MODULE)
-#define ATOMIC_ASM(NAME, TYPE, OP, V) \
+#define ATOMIC_ASM(NAME, TYPE, OP, V, CLASS) \
extern void atomic_##NAME##_##TYPE(volatile u_##TYPE *p, u_##TYPE v);
#else /* !KLD_MODULE */
@@ -75,77 +75,61 @@
/*
* The assembly is volatilized to demark potential before-and-after side
* effects if an interrupt or SMP collision were to occur.
+ *
+ * GCC 2.8 and later (including EGCS) support read/write operands
+ * using '+' as a constraint modifier.
+ *
+ * Earlier versions of gcc don't allow the '+' and recommend the use
+ * of separate, matching read-only and write-only operands.
+ * Unfortunately, this doesn't appear to work in all cases. On
+ * the assumption that the memory operand is always volatile, it
+ * seems safe to tell gcc that it is write-only. The `volatile'
+ * attribute on the memory operand prohibits any optimization
+ * away of the reference.
+ *
+ * The constraint class for the read operand is passed as a parameter
+ * to the macro because it needs to be different in the char case.
+ * (In theory, it should also be different in the short case, but
+ * gcc doesn't have any constraint classes to specify 16-bit registers).
+ *
+ * Note that gcc doesn't support string glueing for the constraint
+ * expressions, so the common "m" or "i" bits cannot be pulled out.
*/
-#if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ 9)
-/* egcs 1.1.2+ version */
-#define ATOMIC_ASM(NAME, TYPE, OP, V) \
+#if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ = 8)
+#define ATOMIC_ASM(NAME, TYPE, OP, V, CLASS) \
static __inline void \
atomic_##NAME##_##TYPE(volatile u_##TYPE *p, u_##TYPE v)\
{ \
- __asm __volatile(MPLOCKED OP\
-: "=m" (*p)\
-: "0" (*p), "ir" (V));\
+ __asm __volatile(MPLOCKED OP : "+m" (*p) : CLASS (V) : "cc"); \
}
-
-#else
-/* gcc = 2.8 version */
-#define ATOMIC_ASM(NAME, TYPE, OP, V) \
+#else /* gcc 2.8 version */
+#define ATOMIC_ASM(NAME, TYPE,
ahc lockups in -current
It seems that the last changes to the ahc drivers (committed on the 18th) are causing my system to lock up. I'd check the aic7890 specific changes first, but that's just me. The problem is that when I start doing I/O to two drives, the system hangs. The SCSI controller and both drives(*) turn on their "I'm busy" LED, so I assume the scsi bus is hung. They OS is still there, but trying to do anything that touches the drives causes the process to lock up. I get no core dump and no messages to the console indicating any problems. With this version, I *do* get the following message at boot time that I didn't get before: (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. The system configuration is: Supermicro motherboard with two PII/Xeons and a aic7890 on it. The aic has BIOS version 2.01 on it. Attached to that are: su-2.04# camcontrol devlist SEAGATE ST39236LW 0004 at scbus0 target 0 lun 0 (pass0,da0) SEAGATE ST39173W 5958at scbus0 target 1 lun 0 (pass1,da1) iomega jaz 1GB J.86 at scbus0 target 3 lun 0 (pass2,da2) PIONEER CD-ROM DR-124X 1.06 at scbus0 target 4 lun 0 (pass3,cd0) YAMAHA CRW4260 1.0q at scbus0 target 5 lun 0 (pass4,cd1) ARTEC AM12S 1.06 at scbus0 target 6 lun 0 (pass5) Target 0 is the system disk: /, /var, /usr, swap and some scratch space. Target 1 is data: /home, more scratch space (/usr/obj lives there) and more swap. The SCSI bus is: AM12S(6) -- AIC(7) -- da(1) -- da(0) -- jazz(3) -- cd(4) -- cd(5) -- term plug I'm a bit leary of the external scanner, so I unplugged it, made sure the AIC had termination set properly, and rebooted single user. Mounted /usr read-only, mounted the scratch space on da1, and did a cp -r of /usr to the scratch space. The system locked up in the same state as described above. Trying the same test - except I left the scanner plugged in - with a kernel built with the old version of the ahc driver worked fine. In fact, building the world with /usr/src and /usr/obj on different disks has been working fine for a while now. I'm hoping to get some guidance from someone who's familiar with the code before I start digging into it. If more information would be useful (dmesg output? config file? other?), let me know. If there's somne specific testing to do - including, if needed, borrowing a 2940 and moving the drives to that to try things on - let me know. Thanx, mike *) When rebooting after the first such crash, the system locked up during fsck with the jazz drive lit as active as well. Yes, the jazz filesystem is mounted at boot. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ahc lockups in -current
It seems that the last changes to the ahc drivers (committed on the 18th) are causing my system to lock up. I'd check the aic7890 specific I just upgraded my system to the latest -current today, from a long hiatus... last time I did a world was July 3rd. I can no longer boot the system. I was beginning to sort through the boot floppies, to figure out when the changes were made that sunk me. Thanks for saving me the trouble. :) I'm booting off the onboard AIC7895 on a Tyan Thunder/100. I get the same error you do initially, followed by many, many SCSI bus resets, errors about lost devices, SCBs aborted, and the like. After a period, the system panics... not about being unable to mount the root fs like I expected, but about 'page fault in kernel mode' or something similar. (da0:ahc0:0:0:0): SCB 0x9 - timed out in Command phase, SEQADDR == 0xa0 (da0:ahc0:0:0:0): BDR message in message buffer (da0:ahc0:0:0:0): SCB 0x9 - timed out in Command phase, SEQADDR == 0x9f (da0:ahc0:0:0:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 4 SCBs aborted etc... Finally it ends with 'Fatal trap 12: page fault while in kernel mode' fault virtual address = 0x3c fault code = supervisor write, page not present The machine locks up hard at that, needing a power cycle. The SCSI activity light blazes. Sorry I can't cut'n'paste the errors to be more useful, I don't have a serial console. I'm copying them by hand as best I can (I'd appreciate being told a better method... :) ) -- Brandon Hume- hume - BOFH.Halifax.NS.Ca, http://WWW.BOFH.Halifax.NS.Ca/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Re[2]: Journaling Filesystem ?
On Sun, Jul 23, 2000 at 03:28:07PM -0700, Kris Kennaway wrote: On Sun, 23 Jul 2000, Joe McGuckin wrote: The big win with a journaling FS is when you have to reboot the system. With Softupdates, you still have to fsck. On a large FS (say half a terabyte) that can take hours. No you don't. Your filesystem will be in a consistent state except for blocks which are marked used but are not, so you can fsck in the background at the expense of not having all of your free space available at startup. Having said that, I don't know that this procedure has been well tested in practise, so you're advised to use caution when testing it :-) I didn't even know that background fsck was supported at all. I remember hearing Kirk talk about it as a future feature at FreeBSD CON last year, but I havn't heard anything about it since. How do you use it? Thanks, -brian p.s. Forgive me if this is well documented in -CURRENT. At the moment, the latest version of FreeBSD that I have available to me is 4.1-RC (cvsup from July 21) and I can't find any mention of it. -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Re[2]: Journaling Filesystem ?
On Sun, 23 Jul 2000, Brian O'Shea wrote: I didn't even know that background fsck was supported at all. I remember hearing Kirk talk about it as a future feature at FreeBSD CON last year, but I havn't heard anything about it since. How do you use it? I've never tried it myself - maybe I am confused and it's just something "which should be easy now". Brian Feldman said he thinks it requires use of FFS snapshots (recently committed). I'll stop making unsubstantiated claims :-) 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: ahc lockups in -current
At 06:07 PM 7/23/2000 -0500, Mike Meyer wrote: It seems that the last changes to the ahc drivers (committed on the 18th) are causing my system to lock up. I'd check the aic7890 specific changes first, but that's just me. The problem is that when I start doing I/O to two drives, the system hangs. The SCSI controller and both drives(*) turn on their "I'm busy" LED, so I assume the scsi bus is hung. They OS is still there, but trying to do anything that touches the drives causes the process to lock up. I get no core dump and no messages to the console indicating any problems. With this version, I *do* get the following message at boot time that I didn't get before: (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. The system configuration is: I get the same hang when doing a dump to an Exabyte 8505 connected to on board aic7880 My disks are hooked up to an internal DPT Raid controller and no problem there. Any time I try to access the tape drive it panics. Sorry I don't have the panic message as I'm running this machine headless at the moment. Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
On Sun, 23 Jul 2000, Mark Murray wrote: There are two other models which rate "pretty well-designed" in the Yarrow paper: the cryptlib and PGP PRNGs. I don't know what their properties are right now (the cryptlib one is described in the paper on PRNG cryptanalysis). Do you have copies of the articles concerned? I'd surely appreciate a photocopy of the relevant pages if you don't mind! :-) The paper I was referring to was: http://www.counterpane.com/pseudorandom_number.html Cryptlib is described here: http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ Well, a simple scheme which doesn't seem to suffer from any of the vulnerabilities discussed in the schneier papers is to accumulate entropy in a pool, and only return output when the pool is full. i.e. the PRNG would either block or return 0 bytes of data, or a full pool's worth. Hmm. Timing attacks? Known-input attacks? Inasmuch as the hash function has no timing attacks (data-dependent code paths, etc) I don't see a weakness there. Chosen input attacks can be mitigated by using a hash function which provides strong mixing (e.g. SHA1), so there is no correlation between partially-known input and output. Yarrow of course takes it a step further by using a very heavy mixing function to regenerate the key, although it seems to me from the design rationale that this is to remove correlations between the Yarrow key before and after reseeding, which doesn't affect an unkeyed PRNG which doesnt maintain state. Will you relent a step or two if I can get the entropy harvesting _rate_ high enough? :-) If we get the entropy pools filling fast enough that the reseed is triggering close to every 256 bits of output then it becomes much less of a concern (but it's still there, because reseeding happens asynchronously with respect to PRNG output). However I think that in practice this will be too heavy on the CPU (unless we weaken the reseed operation) and make dd if=/dev/urandom of=/dev/null a very effective local user DoS :-( The dd if=/dev/urandom of=/dev/null is _already_ a doozy of a dos. Likewise a fork-bomb, a /tmp-filler, likewise a whole bunch of things much worse. Heck, you can hurt your system with cat /dev/zero /dev/null. Well, all of the others can be mitigated by resource limits. It's something which needs to be revisited. Asynchonous reseeding _improves_ the situation; the attacker cannot force it to any degree of accuracy, and if he has the odds stacked heavily against him that each 256-bits of output will have an associated reseed, it makes his job pretty damn difficult. What I meant with that point is that the user may get, say an extra few hundred bits out of it with no new entropy before the scheduled reseed task kicks in. 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: randomdev entropy gathering is really weak
On Sun, 23 Jul 2000, Jeroen C. van Gelderen wrote: Well, a simple scheme which doesn't seem to suffer from any of the vulnerabilities discussed in the schneier papers is to accumulate entropy in a pool, and only return output when the pool is full. i.e. the PRNG would either block or return 0 bytes of data, or a full pool's worth. And you can make Yarrow do just that. Not very practical but you can do it. You effectively set Pg to 1/(2^(k/3)). Oh, I missed this - thanks. It does introduce an extra overhead, namely applying a generator gate with every output (since n k and Pg 1) and then the full reseed with every k bits of output. ITYM Pg = k 2^(-k/3) though - you want a maximum k bits of output, not 1. I'm not sure if the current implementation will let you do this (since Pg 1 here). Reseeds do not *have* to happen asynchronously as pointed out above. Yeah, but they do in the current implementation (AFAICT). 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[2]: Journaling Filesystem ?
On Sun, 23 Jul 2000 13:43:41 -0700 (PDT), Joe McGuckin [EMAIL PROTECTED] said: With Softupdates, you still have to fsck. On a large FS (say half a terabyte) that can take hours. No you don't. Please read the paper. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Re[2]: Journaling Filesystem ?
On Sun, 23 Jul 2000 17:31:24 -0700, "Brian O'Shea" [EMAIL PROTECTED] said: I didn't even know that background fsck was supported at all. I remember hearing Kirk talk about it as a future feature at FreeBSD CON last year, but I havn't heard anything about it since. How do you use it? It is not quite there yet. It requires the snapshot code, which just recently made its way into the tree, and some new system calls to inform the filesystem that block X is actually free. However, this doesn't change the fact that fsck is not required in order to ensure correct operation after a crash. Depending on your access patterns, the block and inode leakage may be small enough to not matter. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DHCP client problem?
On Sun, 23 Jul 2000 13:26:02 -0700, Nick Sayer [EMAIL PROTECTED] said: Nick Reversing that patch fixes it. Since the source for this is in contrib, Nick I presume we Nick need to send this back to ISC rather than patch it in our tree? Nick Tatsumi Hosokawa wrote: (snip) - if [ x$old_ip_address = x ] || [ x$old_ip_address != x$new_ip_address ] || \ - [ x$reason = xBOUND ] || [ x$reason = xREBOOT ]; then -ifconfig $interface inet $new_ip_address $new_netmask_arg \ - $new_broadcast_arg $medium + if [ "x$old_ip_address" = "x" ] || [ "x$old_ip_address" != "x$new_ip_address" ] || \ + [ "x$reason" = "xBOUND" ] || [ "x$reason" = "xREBOOT" ]; then +ifconfig "$interface" inet "$new_ip_address" "$new_netmask_arg" \ + "$new_broadcast_arg" "$medium" Did you see this log? On Thu, 20 Jul 2000 02:53:11 -0700 (PDT), "David E. O'Brien" [EMAIL PROTECTED] said: David obrien 2000/07/20 02:53:11 PDT David Modified files: David contrib/isc-dhcp/client/scripts freebsd David Log: David safe shell quoting David Obtained from: OpenBSD (rev 1.6) And I have already suggested the following fix. On Sun, 23 Jul 2000 18:53:55 +0900, Seigo Tanimura [EMAIL PROTECTED] said: Seigo 1. Seigo This breaks ifconfig(8) in dhclient-script(8) because our ifconfig(8) Seigo does not support both a parameter name and its argument to be in a Seigo single argument. Seigo What we need to do against dhclient-script(8) to prevent executing Seigo arbitrary commands include: Seigo - quoting the arguments from dhclient(8), and Seigo - intializing the internal variables. Seigo It should be a good idea to quote each argument from dhclient(8), Seigo followed by substituting the argument to an internal variable in a way Seigo like this: Seigo new_netmask_arg="netmask \"$new_subnet_mask\"" Seigo Then we do not have to quote all of the variables in dhclient-script(8). Seigo 2. Seigo An argument of "" is passed to ifconfig(8) if the value of $medium is Seigo empty, making ifconfig(8) confused. This is because certain ethernet Seigo card drivers including ed(4) do not support configuring media Seigo types. Fortunately, the fix proposed in 1 allows us once again to Seigo remove quotations around the arguments of ifconfig(8). I wonder if ifconfig(8) of OpenBSD supports providing both the name of a parameter and its value in a single argument, and an ampty argument... (eg ifconfig ed1 inet xxx.xxx.xxx.xxx "netmask yyy.yyy.yyy.yyy" "") -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
