user-mode port 0.56-2.4.18-15
I'm breaking with my usual practice of tying full UML releases to major kernel releases. The intervals between successive 2.4.x kernels are getting too long for my taste.
So, here's a second 2.4.18 UML. As usual, there are a ton of bug fixes in this release. Some of the more important ones are:
The console flow control bug is now fixed. Flow control works properly both with and without Sapan Bhatia's tty output SIGIO fix.
Fixed a crash caused by using a tty_struct after it had been freed when there was no getty on the main console.
Daniel Phillips' pgtable fixes are in.
Fixed a crash caused by installing cmucl.
On older processors which don't implement the cmov instructions, UML likely would hang on starting init. Strictly speaking, this is not a UML bug. The bug was booting a filesystem that executes cmov. However, UML now detects cmov support in the host processor and panics with a useful message when it sees init get a SIGILL on a cmov. The real fix is to get a filesystem that's built for earlier processors than P6.
Added SA_SAMPLE_RANDOM to the irq registration flags of some drivers. This makes apps which read /dev/random work a lot better. Randomness in UML is more problematic than on the host, but I chose a set of drivers whose interrupts shouldn't be too predictable.
The signal mask is now initialized so that odd environments can't screw UML up by passing in bogus masks.
The consoles and serial lines now support SIGWINCH.
The ubd driver's COW bitmaps are now properly byte-swapped.
UML is now robust in the face of tmpfs running out of space.
HZ is now 52.
The project's home page is http://user-mode-linux.sourceforge.net
Downloads are available at
http://user-mode-linux.sourceforge.net/dl-sf.html
Jeff
Quoted 4 lines · Jeff Dike
Added
SA_SAMPLE_RANDOMto the irq registration flags of some drivers. This makes apps which read/dev/randomwork a lot better. Randomness in UML is more problematic than on the host, but I chose a set of drivers whose interrupts shouldn't be too predictable.
If these drivers truly are sufficient candidates for feeding /dev/random, perhaps you could pull these bits and submit them to Linus and Marcelo?
I for one think this is a good idea.
Robert Love
Quoted 3 lines · [email protected] said:
If these drivers truly are sufficient candidates for feeding
/dev/random, perhaps you could pull these bits and submit them to Linus and Marcelo?
They're UML drivers, so they're not useful anywhere except in UML.
Jeff
Hi!
Quoted 4 lines
Added
SA_SAMPLE_RANDOMto the irq registration flags of some drivers. This makes apps which read/dev/randomwork a lot better. Randomness in UML is more problematic than on the host, but I chose a set of drivers whose interrupts shouldn't be too predictable.
Why don't you just feed your /dev/random from hosts /dev/random?
Quoted 1 line
HZ is now 52.
Wow.. Why such strange value?
Pavel
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Quoted 1 line · [email protected] said:
Why don't you just feed your
/dev/randomfrom hosts/dev/random?
That would open up DOS attacks on the host. A nasty person inside a UML could drain the host's /dev/random and hang anything on the host that needs random numbers.
Quoted 1 line
Wow.. Why such strange value?
HZ > 50 is needed to make ps and friends shut up. HZ % 4 == 0 is needed to make some QOS thing compile.
Jeff
Hi!
Quoted 5 lines
Quoted 1 line
Why don't you just feed your
/dev/randomfrom hosts/dev/random?That would open up DOS attacks on the host. A nasty person inside a UML could drain the host's
/dev/randomand hang anything on the host that needs random numbers.
Okay, make it /dev/urandom ;-).
Pavel
Signature · 2 lines
Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic.
Quoted 1 line · [email protected] said:
Okay, make it
/dev/urandom;-).
Doesn't /dev/urandom have exactly the same DOS properties as /dev/random? I.e. it reads real random numbers until the entropy pool is empty, then starts returning pseudo-random numbers? If so, things on the host will still hang when they then try to read /dev/random.
Also, UML processes deserve crytographically secure numbers just as much as host proceses do. When something opens /dev/random, /dev/random is exactly what it should get.
Jeff
Quoted 4 lines · Jeff Dike
Doesn't
/dev/urandomhave exactly the same DOS properties as/dev/random? I.e. it reads real random numbers until the entropy pool is empty, then starts returning pseudo-random numbers? If so, things on the host will still hang when they then try to read/dev/random.
You are correct. Reading from /dev/urandom consumes just as much entropy as reading from /dev/random. It just doesn't block when the entropy pool is random.
Hmm, maybe this should be fixed by refilling the urandom entropy pool much less often...
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
Quoted 6 lines · Jeff Dike
Quoted 1 line · [email protected] said:
Why don't you just feed your
/dev/randomfrom hosts/dev/random?That would open up DOS attacks on the host. A nasty person inside a UML could drain the host's
/dev/randomand hang anything on the host that needs random numbers.
Why not feed your /dev/random from the host's /dev/urandom?