Re: Can dhclient rely on /dev/random?
Policy Question: is a fast, high-quality /dev/random a gauranteed feature starting with 5.0? yes. More like Yes, effectively. It is a module, and its conceivable under the right (Wrong?) circumstances that this module is not loaded. This would not be the default case, and it breaks Much(tm) if you don't include it. The kernel-building individual would have had to have made a decision to not include the RNG, and as such is assumed to know what she is doing. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can dhclient rely on /dev/random?
On Sat, 28 Dec 2002, Tim Kientzle wrote: I've clocked /dev/random on -current at just about 10MB/s (on a 1GHz AMD Duron). That's plenty fast enough for generating session keys. ;-) Sounds like it, I didn't realize it was that fast. :) If this code is just used for generating occasional keys, 4.x's /dev/random may well suffice. As I dig deeper, though, I'm starting to suspect that this code isn't actually used by dhclient at all. That would suggest a much simpler fix... ;-) Tim Warning! Warning! Under 4.x, you probably want to use /dev/urandom. The reason for this is that /dev/random is only guaranteed to give you values when it can guarantee that you're getting good randomness. And as 4.x doesn't harvest many entropy sources by default, there's little good randomness, and you'll get nothing! /dev/urandom's bad randomness is certainly better than no randomness at all. :) Of course, if dhclient doesn't need any randomness, then I guess you don't have to worry. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can dhclient rely on /dev/random?
Tim Kientzle wrote: The obvious fix would alter dhclient to rely only on /dev/random for entropy. (It seems this code is common to bind as well.) The obvious fix, I think, is to just use the boot time as the start for the exponential backoff. The only place this might be a problem is in a big installation where a lot of machines come on at the same time. That's probably going to melt your building's wiring, anyway. 8-). Technical Question: is /dev/random sufficient for the cryptographic requirements of programs like dhclient, bind, etc? Uh, what cryptographic requirements of dhclient? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Anyone like obscure stdio problems?
I have no problem admitting that I've traced through the innards of
_fseeko a few times now and am no closer to finding out exactly where
the problem is, though I have a suspicion it has to do with when the
file pointer's buffer is allocated and initially populated. In any
case, here's a particularly weird one from the Apple Files that also
occurs on FreeBSD
The following program, also available from
http://narcissus.queasyweasel.com/fump.c, demonstrates the problem.
If you change the top #define of FIRST_SEEK to 0 instead of 1, the
program will work. If you leave it at 1, the initial (and
theoretically redundant and no-op) fseek on readMidFP will bugger up
stdio's internal state somehow.
If anyone with more stdio-fu than me would like to poke at it, I'd be
interested in hearing what you find out. If this is breaking some
undocumented rule of stdio I'd like to know that too so that I can
document it both in FreeBSD and Mac OS X. Thanks.
- Jordan
#include stdio.h
#define SIZE 40
#define NBS 5
#define FIRST_SEEK 1
int main( void ) {
FILE *writeFP ;
FILE *readMidFP ;
int err , i , n = 0 , count , SizeOfFile , nerr = 0 ;
char ch ;
writeFP = fopen( test_fseek_outfile , w ) ;
if ( writeFP == NULL ) {
fprintf( stderr , open for write failed.\n ) ;
exit( 1 ) ;
}
readMidFP = fopen( test_fseek_outfile , r ) ;
if ( readMidFP == NULL ) {
fprintf( stderr , open readMidFP for read failed.\n ) ;
exit( 1 ) ;
}
/* write SIZE a's to output file. */
SizeOfFile = SIZE ;
for ( count = 0 ; ( count = SizeOfFile ) ( n != -1 ) ; count++ ) {
n = fprintf( writeFP , a ) ;
if ( n == -1 )
break ;
}
fflush( writeFP ) ;
/* seek to middle of file. */
// THIS IS CRUCIAL TO MAKING IT FAIL
// REMOVE THIS fseek() AND THE PROGRAM SUCCEEDS
#if FIRST_SEEK
err = fseek( readMidFP , (long) (SizeOfFile / 2) , SEEK_SET ) ;
if ( err != 0 ) {
fprintf( stderr , first fseek() to middle of file on
readMidFP failed.\n ) ;
exit( 1 ) ;
}
#endif
/* seek to middle of file. */
err = fseek( writeFP , (long) (SizeOfFile / 2) , SEEK_SET ) ;
if ( err != 0 ) {
fprintf( stderr , first fseek() to middle of file on
writeFP failed.\n ) ;
exit( 1 ) ;
}
/* write NBS b's. */
for ( i = 0 ; i NBS ; i++ )
fprintf( writeFP , b ) ;
fflush( writeFP ) ;
/* seek to middle of file. should be NBS b's there. */
err = fseek( readMidFP , (long) (SizeOfFile / 2) , SEEK_SET ) ;
if ( err != 0 ) {
fprintf( stderr , second fseek() to middle of file on
readMidFP failed.\n ) ;
exit( 1 ) ;
}
for ( i = 0 ; i NBS ; i++ ) {
fscanf( readMidFP , %c , ch ) ;
if ( ch != 'b' ) {
fprintf( stderr , ** ERROR ** \'%c\' at position:
%d\n , ch , (SizeOfFile / 2)+i ) ;
nerr++ ;
}
}
if ( nerr == 0 )
fprintf( stderr , Program was succesful.\n ) ;
else
fprintf( stderr , Program failed.\n ) ;
return( 0 ) ;
}
--
Jordan K. Hubbard
Engineering Manager, BSD technology group
Apple Computer
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Anyone like obscure stdio problems?
On Sunday, December 29, 2002, Jordan Hubbard wrote: I have no problem admitting that I've traced through the innards of _fseeko a few times now and am no closer to finding out exactly where the problem is, though I have a suspicion it has to do with when the file pointer's buffer is allocated and initially populated. In any case, here's a particularly weird one from the Apple Files that also occurs on FreeBSD The following program, also available from http://narcissus.queasyweasel.com/fump.c, demonstrates the problem. If you change the top #define of FIRST_SEEK to 0 instead of 1, the program will work. If you leave it at 1, the initial (and theoretically redundant and no-op) fseek on readMidFP will bugger up stdio's internal state somehow. If anyone with more stdio-fu than me would like to poke at it, I'd be interested in hearing what you find out. If this is breaking some undocumented rule of stdio I'd like to know that too so that I can document it both in FreeBSD and Mac OS X. Thanks. As we discussed on IRC, the problem lies in line 254 of libc/stdio/fseek.c. Since in your case the buffer is not modified (no __SMOD flag, see a few lines back in fseek.c), it assumes that the buffer that it filled after the first fseek but before the write is still OK, and simply copies out from it when you read it looking for your B's. Placing a pointless fgetln() after the first fseek() will make this obvious: if (fseek(rp, (long)(i / 2), SEEK_SET) != 0) err(1, fseek on rp); (void)fgetln(rp, throwaway); fgetln() will set __SMOD for rp's buffer and so stdio is forced to discard it and refill it from the file (which contains the B's). -- Chris Costello[EMAIL PROTECTED] FreeBSD Project http://www.FreeBSD.org/ TrustedBSD Project http://www.TrustedBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Framebuffer howto?
Hiten Pandya wrote: --- Pedro F. Giffuni [EMAIL PROTECTED] wrote: Actually I suggested on private email to use GGI. GGI can work on top of VGL or Linux's framebuffer, and when KGI becomes available it will work fine. Hmm, someone said earlier on in this thread, that FreeBSD does not have a framebuffer device; if so: 1) What is the FB_INSTALL_CDEV kernel option for? 2) What is the purpose of sys/fbio.h? Clarification will be appreciated. Cheers. Well as far as I can see the text console is considered as kind of a frame buffer. Surely not what quite what you are looking for. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Framebuffer howto?
--- Hiten Pandya [EMAIL PROTECTED] ha scritto: ... Clarification will be appreciated. I understand the Linux framebuffer device was initially based on our VESA driver, but it has evolved into a specialized device for specific graphic cards. It's also a moving target, not something anyone in FreeBSD has been willing to follow. There are more important things to do in FreeBSD's graphics end; fully newbussifying the VESA driver would be nice, perhaps supporting VBE/AF (like in this dead project (http://www.talula.demon.co.uk/freebe/index.html), or of course helping the KGI porting effort* (Hi Nicholas ;) ). cheers, Pedro. * I understand a VM guru is needed there BTW __ Yahoo! Cellulari: scarica i loghi e le suonerie per le tue feste! http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can dhclient rely on /dev/random?
Terry Lambert wrote: Uh, what cryptographic requirements of dhclient? I'm not really sure. ;-) The dhclient source has a 'dst' directory with source for an HMAC/MD5 digest authentication toolkit. I haven't figured out exactly what it's used for, though. (Dynamic DNS updates for secure BIND? Some form of authenticated DHCP?) Maybe someone else around here knows. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NFS ACLS's ?
On Fri, 27 Dec 2002, joe mcguckin wrote: Are there any strange interactions between NFS and filesystems that are not UFS? E.g. UFS2? Does NFS support new features that these fs's may implement? NFS can represent many but not all of the services found in UFS1 and UFS2. Among things it doesn't support are the retrieval and manipulation of BSD file user flags, system flags, extended attributes, and access control lists (ACLs). However, NFSv3 does correctly handle enforcement with these features because clients rely on the server to evaluate protections on file system objects using an ACCESS RPC. NFS2 evaluates protections on the client (if I recall correctly) so may not behave properly. There are RPC extensions to NFSv3 to retrieve and manipulate ACLs on Solaris, IRIX, et al, but we don't currently implement those extensions. Likewise, NFSv4 supports ACL management, but we don't yet implement NFSv4. It shouldn't be too hard to dig up information on the NFSv3 ACL RPC extensions and implement them on FreeBSD 5, since the semantics of our ACLs are highly compatible with Solaris and IRIX. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[Fwd: [FAQ] The Open Source Stackable PC BIOS (fwd)]
Forwarded, per request of the author. Original email address on file. -- Terry Bruce M Simpson wrote: Terry, On Fri, Dec 13, 2002 at 08:04:12AM -0800, Terry Lambert wrote: Ronald G. Minnich wrote: On Thu, 12 Dec 2002, Terry Lambert wrote: I guess it's not OK to make BIOS calls into the BIOS? not if it's my lazy bios that doesn't support them. Actually, the interesting part would be a survey of which BIOS calls are actually used (a survey by a BIOS writer, maybe, hint hint 8-)). The real question is fail-safe on unimplemented BIOS calls, which should return a characteristic error. I have done this work. The results can be seen at: http://www.incunabulum.com/code/projects/freebsd/freebsd-bios-interaction.txt I have also rewritten boot0.s to use the BIOS COM Port Services (INT 14h): http://www.incunabulum.com/code/projects/freebsd/boot0sio.s Comments, suggestions, flames etc. to the usual address. P.S. The PTRs for this machine may be FUBAR, so if you could repost to hackers@ I should be most grateful. yours, BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NFS ACLS's ?
Robert Watson wrote: On Fri, 27 Dec 2002, joe mcguckin wrote: Are there any strange interactions between NFS and filesystems that are not UFS? E.g. UFS2? Does NFS support new features that these fs's may implement? NFS can represent many but not all of the services found in UFS1 and UFS2. Among things it doesn't support are the retrieval and manipulation of BSD file user flags, system flags, extended attributes, and access control lists (ACLs). However, NFSv3 does correctly handle enforcement with these features because clients rely on the server to evaluate protections on file system objects using an ACCESS RPC. Participation in the enforcement protocol is, unfortunately, voluntary, however. 8-(. NFS2 evaluates protections on the client (if I recall correctly) so may not behave properly. s/may not/will not/ There are RPC extensions to NFSv3 to retrieve and manipulate ACLs on Solaris, IRIX, et al, but we don't currently implement those extensions. Last I tried, they were not implemented identically on the various platforms, so I scrapped the idea as being bogus. Without a standard, code is useless. Likewise, NFSv4 supports ACL management, but we don't yet implement NFSv4. It shouldn't be too hard to dig up information on the NFSv3 ACL RPC extensions and implement them on FreeBSD 5, since the semantics of our ACLs are highly compatible with Solaris and IRIX. They aren't identical, unforntunately. You can get close by passing one at a time, but it's not really worth it to do local enforcement. I'm actually not a fan of NFSv4. The biggest NFS problems that exist are timesync and locking, and it doesn't solve either one of those very well. I suggested to the RFC authors several times at the draft stage that they include a local timestamp on all operations, which would have eliminated the timesync problem (all times could be represented in responses as deltas from the system time minus the timesync). The only real project to implement, outside of commercial vendors, appears to be a university project on Linux, which from my reckoning is not going well (I greatly admire the CS department attempting the work, so I don't know why that's the case...). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
