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
On Mon, 2002-04-08 at 16:56, Jeff Dike wrote:
> 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.
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
Hi!
> 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.
Why don't you just feed your /dev/random from hosts /dev/random?
> HZ is now 52.
Wow.. Why such strange value?
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
[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
[email protected] said:
> Why don't you just feed your /dev/random from 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.
> 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!
> > Why don't you just feed your /dev/random from 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.
Okay, make it /dev/urandom ;-).
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
[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
On Apr 09, 2002 20:44 -0500, Jeff Dike wrote:
> 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.
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/
Jeff Dike wrote:
>[email protected] said:
>> Why don't you just feed your /dev/random from 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.
Why not feed your /dev/random from the host's /dev/urandom?