I spoke at the CentOS Dojo in Pune yesterday on new features available in CentOS release 7.0 since the 6 release. Slides are available here: What’s New in Virtualization. The event was organized by the Pune GNU/Linux Users Group (PLUG) for the CentOS project.
Several applications need random numbers for correct and secure operation. When ssh-server gets installed on a system, public and private key paris are generated. Random numbers are needed for this operation. Same with creating a GPG key pair. Initial TCP sequence numbers are randomized. Process PIDs are randomized. Without such randomization, we’d get a predictable set of TCP sequence numbers or PIDs, making it easy for attackers to break into servers or desktops.
On a system without any special hardware, Linux seeds its entropy pool from sources like keyboard and mouse input, disk IO, network IO, and any other sources whose kernel modules indicate they are capable of adding to the kernel’s entropy pool (i.e .the interrupts they receive are from sufficiently non-deterministic sources). For servers, keyboard and mouse inputs are rare (most don’t even have a keyboard / mouse connected). This makes getting true random numbers difficult: applications requesting random numbers from /dev/random have to wait for indefinite periods to get the randomness they desire (like creating ssh keys, typically during firstboot.).
Videos from the KVM Forum 2011 are being uploaded at http://www.youtube.com/playlist?list=PL7C0F52E2227156B3
If you’re trying out a kernel newer than 2.6.38-rc6 and find your LCD brightness doesn’t go up to its maximum, here’s some help: boot into an older kernel, set the brightness to maximum, then reboot into the newer kernel, and now you’ll get the max. brightness that you’re used to.
The git commit by Indan Zupancic explains why this happens:
drm/i915: Do not handle backlight combination mode specially
The current code does not follow Intel documentation: It misses some things and does other, undocumented things. This causes wrong backlight values in certain conditions. Instead of adding tricky code handling badly documented and rare corner cases, don’t handle combination mode specially at all. This way PCI_LBPC is never touched and weird things shouldn’t happen.
If combination mode is enabled, then the only downside is that changing the brightness has a greater granularity (the LBPC value), but LBPC is at most 254 and the maximum is in the thousands, so this is no real functional loss.
A potential problem with not handling combined mode is that a brightness of max * PCI_LBPC is not bright enough. However, this is very unlikely because from the documentation LBPC seems to act as a scaling factor and doesn’t look like it’s supposed to be changed after boot. The value at boot should always result in a bright enough screen.
IMPORTANT: However, although usually the above is true, it may not be when people ran an older (2.6.37) kernel which messed up the LBPC register, and they are unlucky enough to have a BIOS that saves and restores the LBPC value. Then a good kernel may seem to not work: Max brightness isn’t bright enough. If this happens people should boot back into the old kernel, set brightness to the maximum, and then reboot. After that everything should be fine.
For more information see the below links. This fixes bugs: