Kernel Traffic #101 For 8 Jan 2001 By Zack Brown linux-kernel FAQ (http://www.tux.org/lkml/) | subscribe to linux-kernel (http:/ /www.tux.org/lkml/#s3-1) | linux-kernel Archives (http://www.uwsg.indiana.edu/ hypermail/linux/kernel/index.html) | kernelnotes.org (http:// www.kernelnotes.org/) | LxR Kernel Source Browser (http://lxr.linux.no/) | All Kernels (http://www.memalpha.cx/Linux/Kernel/) | Kernel Ports (http:// perso.wanadoo.es/xose/linux/linux_ports.html) | Kernel Docs (http:// jungla.dit.upm.es/~jmseyas/linux/kernel/hackers-docs.html) | Gary's Encyclopedia: Linux Kernel (http://members.aa.net/~swear/pedia/kernel.html) | # kernelnewbies (http://kernelnewbies.org/) Table Of Contents * Standard Format * Text Format * XML Source * German Translation * Spanish Translation * Introduction * Mailing List Stats For This Week * Threads Covered 1. 21 Dec 2000 - 26 Dec 2000 (14 Recommended GCC Compiler Version posts) 2. 21 Dec 2000 - 26 Dec 2000 (12 The NSA's Security-Enhanced Linux posts) 3. 25 Dec 2000 - 26 Dec 2000 (4 Some BIOSes Favoring Microsoft posts) 4. 28 Dec 2000 - 29 Dec 2000 (3 Repetive Strain Injuries posts) 5. 29 Dec 2000 (3 PowerPC Tree Out Of Date posts) 6. 30 Dec 2000 (3 Some Crossed Wires With Patch posts) Submission 7. 30 Dec 2000 (4 Status Of PowerPC Port In The posts) Official Tree 8. 30 Dec 2000 - 31 Dec 2000 (2 POSIX Message Queues posts) Introduction Sorry, nothing in this issue about the release of 2.4; in fact, this issue of KT covers the heart of the Christian holiday season, so there was not as much discussion on the list as usual. Tune in next week for discussions about the new stable series. Mailing List Stats For This Week We looked at 546 posts in 2549K. There were 230 different contributors. 105 posted more than once. 0 posted last week too. The top posters of the week were: * 25 posts in 113K by Andrea Arcangeli * 24 posts in 89K by Alan Cox * 14 posts in 103K by Andrew Morton * 13 posts in 62K by Marcelo Tosatti * 12 posts in 43K by Jens Axboe * Full Stats 1. Recommended GCC Compiler Version 21 Dec 2000 - 26 Dec 2000 (14 posts) Archive Link: "recommended gcc compiler version" Topics: Version Control People: Barry K. Nathan, Linus Torvalds, Alan Cox Robert B. Easter asked which were the recommended compiler versions for 2.2.18 and the 2.4-test series. For 2.2.18, Barry K. Nathan recommended, "gcc 2.7.2.3 is safest, but egcs 1.1.2 should be safe even for mission-critical stuff. gcc 2.95.2 seems to work for many people, but isn't necessarily safe." For 2.4 he recommended, "egcs 1.1.2 is the safe choice, but gcc 2.95.2 seems to work. gcc 2.7.2.3 miscompiles 2.4 more often than not, so 2.4 has a preprocessor check that stops any attempts to compile it with 2.7.2.3." He added that the Documentation/Changes file would answer the compiler question for each particular release. Elsewhere, Linus Torvalds said at one point: Note that despite my public comments about it beign a bad idea to ship extremely untested compilers in a major release, I actually think that it would be wonderful to have people who are ready to face the consequences to try the new 2.96. It's not been all that widely tested, but if you kno a bit about what you're doing (or want to learn), gcc-2.96 _does_ potentially create better code, and if nobody is willing to test it, any potential bugs (be they in the kernel sources and triggered by a smarter compiler, or in the compiler itself) won't be found. So please do try it out, but please mention the fact if you end up having to report a bug (it won't make your bug-report be ignored, don't ever worry about something like that. But i would be good to have an older compiler handy to correlate the bug with the compiler for sure). In fact, I'd love to hear about experiences even with the CVS snapshots. I just don't like them showing up in distributions ;) In reply, Matthew Vanecek reported that the latest gcc 2.96 updates from Red Hat had been working fine for his kernel compiles. Elsewhere, Alan Cox also listed the recommended compilers for Robert, adding, "Red Hat's 2.96 seems to generate valid kernels but don't expect sympathy if you report a bug in one built that way." And Linus went on, in response: Now, now, I'd love to se reports of expecially the new updated compiler. I've not actually seen a single report of problems for the kernel even with the old 2.96, it's just that I've seen too many user-space problems that I would be hesitant to use it for the kernel. Despite my dislike of releasing snaopshot compilers, I'd _much_ rather see Red Hat just dropping their "kgcc" thing, and in order to do that people do ned to test with the new compiler. I just want people to mention the fact, so that I can correlate any bug-reports with a compiler version. Just in case. It can be important (and not just because of compiler bugs, but due to real kernel bugs that just were hidden by pure luck with other compilers). And it helps a LOT if you have another compiler available to compare with. 2. The NSA's Security-Enhanced Linux 21 Dec 2000 - 26 Dec 2000 (12 posts) Archive Link: "The NSA's Security-Enhanced Linux (fwd)" Topics: Access Control Lists, Microkernels: Mach People: Casey Schaufler, Sandy Harris, Alan Cox, James Lewis Nance, Michael H. Warfield, Kurt Garloff, Stephen Smalley, Amon Ott, Alex Buell, Mike A. Harris Mike A. Harris gave a link to the NSA's Security Enhanced Linux Project Page ( http://www.nsa.gov/selinux/background.html) and asked if anyone had looked into it. Alex Buell recommended paranoia, saying it would be prudent to look for back-doors before including any of the NSA's code. But elsewhere, Casey Schaufler said, "Persons looking for backdoors, tricks, traps, snares, or ice are going to be disappointed. It's just code like everone else produces. Much of the work was done by employees of the NSA. They should be applauded for the effort they put in just to be allowed to make this available." Sandy Harris replied, "These folks are good at what they do and the code is GPL. It is worth starting to consider whether this code, or code from one of the other security-enhancement projects, should be included in the standard kernel for 2.6 or 3.0." Alan Cox replied, "I think this is a good point. Its actually a nice testimonial for free software that its finally got the NSA contributing code in a way that everyone benefits from and which may help cut down computer crime beyond government. (and which of course actually is part of the NSA's real job)" And James Lewis Nance credited, "I often wonder how many people know that a whole bunch of the Linux networking code is Copyrighted by the NSA. I'm always waiting to hear someone come up with a conspiracy theory about it on slashdot, but I have never heard anyone mention it." Elsewhere, Alan remarked, "Im sure all sorts of people will be finding bugs in it because they are looking for secret NSA backdoors so why discourage them 8)." Michael H. Warfield replied, "Now that's a real damn good point that I hadn't thought of. With everyone so paranoid about what backdoors they may have left (like they would be that crazy to put them in and put it out in plain view for everyone) that the code should end up getting a real good review for bugs as well. :-) Such a deal. :-)" Elsewhere on a more technical note, Kurt Garloff said: I wonder how their approach compares to the RSBAC stuff, though. The RSBAC (by Amon Ott) has all the infrastructure available to have policy based access control; whenever an access decision has to be taken, a call via some interface is made to a module, which then takes the decision ... Just like PAM in userspace. http://www.rsbac.org/ I think it's a good approach and I think, it has gone much further than the NSA stuff. I'd prefer to have RSBAC merged in 2.5. Stephen Smalley replied: The Security-Enhanced Linux has a well-defined architecture (named Flask) for flexible mandatory access controls that has been experimentally validated through several prototype systems (DTMach, DTOS, and Flask). The architecture provides clean separation of policy from enforcement, well-defined policy decision interfaces, flexibility in labeling and access decisions, support for policy changes, and fine-grained controls over the kernel abstractions. Detailed studies have been performed of the ability of the architecture to support a wide variety of security policies and are available on the DTOS and Flask web pages accessible via the Background page (http://www.nsa.gov/selinux/ background.html). A published paper about the Flask architecture is also available on the Background page. The architecture and its implementation in Linux are described in detail in the documentation (http://www.nsa.gov/selinux/ docs.html). RSBAC appears to have similar goals to the Security-Enhanced Linux. Like the Security-Enhanced Linux, it separates policy from enforcement and supports a variety of security policies. RSBAC uses a different architecture (the Generalized Framework for Access Control or GFAC) than the Security-Enhanced Linux, although the Flask paper notes that at the highest level of abstraction, the the Flask architecture is consistent with the GFAC. However, the GFAC does not seem to fully address the issue of policy changes and revocation, as discussed in the Flask paper. RSBAC also differs in the specifics of its policy interfaces and its controls, but a careful evaluation of the significance of these differences has not been performed. This was also covered recently in Debian Traffic Issue #16, Section #6 ( 22 Dec 2000: NSA's Secure Linux Distribution) . 3. Some BIOSes Favoring Microsoft 25 Dec 2000 - 26 Dec 2000 (4 posts) Archive Link: "BIOS problem, pro Microsoft, anti other OS" Topics: Microsoft, Modems, PCI People: Marvin Stodolsky, David Riley Marvin Stodolsky reported: some PC BIOS chips are now coming with a default Microsoft setting, which makes them hostile to some functionalities of other OS. If particular under Linux, a PCI Winmodem did NOT function with the Win98 BIOS setting, but did fine with BIOS choice "Other OS". Possible, other PCI devices under Linux OS might be simmilarly afflicated. This indicates a need for Linux install software to be equipped with a utility to probe the BIOS and report back "Linux hostile" BIOS settings. Today most Newbies are getting new PC boxes equipped with WinModems. Hostile BIOS settings will block their capability to get on-line. David Riley replied, "I don't think this can necessarily be classified as "Linux hostile", but really more as "Linux ignorant". In most decent BIOS setups, the "Windows" option in your setup would read as "PnP OS". The writers of your bios just assumed that Windows is the only OS that works properly with PNP (though up until recently that wasn't far from the truth). In any case, using a somewhat newer kernel (like 2.4.0-test12, I think) should solve problems by properly handling PnP stuff." 4. Repetive Strain Injuries 28 Dec 2000 - 29 Dec 2000 (3 posts) Archive Link: "[PATCH] 8139too fix" People: Andre Hedrick, Mike Galbraith, Jeff Garzik, Rik van Riel Rik van Riel sent a patch to Jeff Garzik, and Andre Hedrick replied, "Jeff Garzik, is offline for the next three weeks...... He claims that his wrists hurt from the keyboard ;-)..." Mike Galbraith replied: And if his wrists hurt, he's definitely doing the right thing by laying off. I _know_: 8 months in a neck brace due to cervical spine damage (don't hunch forward while reading cool/clever code). 1.5 years physical therapy for that damage (permanent, _do not_ hunch forward while reading cool/clever code). 7 months paralysis of left arm (don't put weight on your elbow on hard surface while reading cool/clever code) 5 months paralysis of lower left leg (don't cross your legs while leaning on left elbow while...). The nerve damage can be helped a bit with massive doses of vitamine B if you're lucky, but they don't fully recover in my experience. Bones don't recover at all.. ever. Remember the thousand times your mom said sit up straight?.. I sure do ;-) End Of Discussion. 5. PowerPC Tree Out Of Date 29 Dec 2000 (3 posts) Archive Link: "PowerPC branch out of date" People: Tom Gall, Tom Rini, Alan Cox, Rik van Riel, Linus Torvalds Tom Gall reported: I'm one of the folks that works on the PowerPC portion of the kernel. I've noticed for some time that what's available at kernel.org and what's being worked on by those of us who maintain our little portion of the PowerPC tree is more and more out of sync. How it's got there etc etc etc at this stage isn't important. First how to fix it and how to make sure it doesn't happen again does concern me. Currently the diff between test13-preX and the master fsmlabs.com ppc tree is about 450k. Is the right thing to start with that patch get that into the test13-preX series? I would REALLY appreciate it if this could be made to happen. I've got a whole boatload of RS/6000 (aka pSeries) hardware that will be starting to work once this patch is in. It's truely a shame to have to explain to people that kernel.org *SHOULD* be the place to get a good kernel but given that things are out of sync to have to point them somewhere else. Rik van Riel suggested submitting patches to Linus Torvalds or Alan Cox, but Tom replied, "test13-pre5-acXX is up-to-date with everything that's important anyways. Weather that makes it into Linus' tree is the important and unknown bit." 6. Some Crossed Wires With Patch Submission 30 Dec 2000 (3 posts) Archive Link: "test13-pre6 compile error..network.o" People: Alan Cox, Frank Davis, Andrew Morton Frank Davis got some undefined references in network.o, while trying to compile 2.4.0test13-pre6; Andrew Morton posted a patch to fix it, and Alan Cox explained, "My fault. I fed Linus a few things too many trying to get the networking stuff tidied up. Stuff leaked in from the networking core fixes that arent yet in Linus tree." 7. Status Of PowerPC Port In The Official Tree 30 Dec 2000 (4 posts) Archive Link: "Linux 2.4test-ac merge status" Topics: Kernel Release Announcement People: Alan Cox, Tom Rini Alan Cox announced 2.4.0test13pre7-ac1 and explained, "This is to help give folks an idea of what -ac stuff has been pushed to Linus, is still in need of work, has been dumped in the bitbucket of bad ideas etc." Tom Rini asked if the PowerPC port had been dumped in the bitbucket, and Alan replied, "It might be the ppc port is 2.4.0ac1 and 2.4.2 Linus or something. I don't think that is likely to be a big problem. I need to get on top of 2.2.19pre4 and the rest of the Linus resync then I'm going to dump chunks of stuff out of -ac and try and get a nice clean -ac tree. If folks want to sync non x86 ports with that initially go ahead." Tom replied, "Oh well. I guess our problem is we can never get Linus to notice the smaller chunks and he always seems to hate big patches." 8. POSIX Message Queues 30 Dec 2000 - 31 Dec 2000 (2 posts) Archive Link: "Posix MessageQ's" Topics: POSIX People: Rajesh Balan, Gabi Davar Rajesh Balan asked, "Does linux support Posix Message Q's. Iam reffering richard stevens V2 for IPC.. The book said to include , which i was not able to find. Iam using Linux 2.2." Gabi Davar replied, "POSIX Message Queues are not implemented yet in glibc v2.2 (POSIX semaphores are partially implemented). Once glibc will support them, you could test for their existence via sysctl() and the relevant defines. As far as I know, Linux implements only SysV MQs. Solaris and True64 implement them though." Sharon And Joy Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.