|Og dreams of kernels||Greg KH||2 years 34 weeks ago|
|Re: Old IPSEC bug||Theo de Raadt||2 years 18 weeks ago|
|Re: Allegations regarding OpenBSD IPSEC||Rod Whitworth||2 years 18 weeks ago|
|Re: Allegations regarding OpenBSD IPSEC||Jason L. Wright||2 years 18 weeks ago|
|Re: Allegations regarding OpenBSD IPSEC||Bob Beck||2 years 18 weeks ago|
|Allegations regarding OpenBSD IPSEC||Theo de Raadt||2 years 18 weeks ago|
A linux server is capable of functioning as an assortment of different network devices. For example, it can act as a router, a switch, or even a network bridge. In the latter case, two or more ethernet networks are linked, or bridged together logically and transparently to make one larger network. Learn more about bridges in this faq.
Torrey Hoffman recently posted information on a patch he's written to the ethernet bridge driver to allow encryption in an ethernet bridge. His driver patch is intended as a tool for further development, currently applied against the 2.4.17-pre7 kernel. The example usage he describes is running multiple MPEG streams across the bridge, encrypting each with a different key to prevent the video from being copied when transferred across the network. Find more information on the project's home page. The patched ethernet bridge driver uses the AES (aka Rijndael) encryption algorithm. For Torrey's announcement email, read on.
Earlier this month Keith Owens announced v2.0 of kbuild 2.5, offering among other improvments a 30% speed increase over kbuild 2.4. (kbuild 2.4 is the currently used build system in the 2.4 and 2.5 kernel trees.) Several days ago, v2.1 of kbuild 2.5 was released, moving towards kernel inclusion.
When asked what he was waiting for, Keith replied, "For me to be satisfied that the code is stable, the rewrite with go faster stripes is less than four weeks old." [Earlier Story]
v2.1 offers a few minor bug fixes. Keith comments, "You know the code is getting stable when most of the changes are documentation and white space from Lindent :)" Later he mentions another improvement the new system has over its predecessor, "With kbuild 2.5 you do not need to 'make clean' before building, unlike the existing build system, kbuild 2.5 gets it right."
A recent thread on the FreeBSD hackers mailing list began when Jordan Hubbard reported odd behavior with ssh in the 4.5-STABLE tree. The change in behavior was due to a change in the default setting in the interests of security. During the dicussion another change to default behavior was brought up where X11 now has TCP forwarding disabled, prefering instead that the users tunnel X connections through ssh.
Much of the resulting protest was at how this changes FreeBSD's default behavior, creating confusion. Joerg Micheel said, "The system has to work right away, when installed out of the box. Period. No when's and if's. And don't tell me that X11 is an add-on and luxury. We are living in the 21st century."
The attempt is to make the default installation more secure. Terry Lambert points out, "I really don't think there's any way to fully protect a security-unconscious user, as if they had spent the time to learn what was necessary, and chosen the right settings for their site. Nothing can replace a system administrator who knows which end is up."
Finally, as the conversation considered whether such changes were security by obscurity, Robert Watson offered, ""Security by obscurity" refers to a behavioral phenomena in system design and delivery, not to a technical design principle. For example, it refers to using a secret algorithm, but does not refer to using a secret key with a published algorithm. So disabling services in a default configuration reduces risk by reducing exposure, but it's not security by obscurity. "
Robert Love recently submitted a group of O(1) scheduler patches for Alan Cox's 2.4-ac branch. The eight patch set brings the ultra-scalable scheduler up to date in the 2.4 stable tree, back porting the many fixes and improvements that were up to now only found in the 2.5 development tree. Robert highlights the addition of the migration thread as the most important change. Though the currently submitted patches are only for 2.4.19-pre7-ac2, Robert noted that he'd be making patches available for 2.4.18 and 2.4.19-pre7 shortly.
A buffer overlow has been discovered in OpenSSH by which in a worse case scenario remote users can gain privileged access to a server. Fortunately the bug is not present in a default install, and therefore it likely does not affect the vast majority of users. According to the OpenSSH security advisory: "All Versions of OpenSSH compiled with AFS/Kerberos support and ticket/token passing enabled contain a buffer overflow. Ticket/Token passing is disabled by default and available only in protocol version 1."
If you have compiled in AFS/Kerberos support and have ticket/token passing enabled:
Updated: Updated advisory follows.
Erich Focht submitted a patch to the lkml, fixing a bug in migration threads (in the 2.5.8 development kernel) that lead to a deadlock, or frozen system. In the process of fixing the bug, he also worked to cleanup the initialization of the migration threads.
In an earlier email to the lkml, Ingo Molnar explained migration threads:
"The concept is the following: there arenew per-CPU system threads (so-called migration threads) that handle a per-runqueue 'migration queue'. set_cpus_allowed() registers tasks in the target CPU's migration queue, kicks the migrating thread and wakes up the migration thread. The migrating thread unschedules on its source CPU, at which point the migration thread picks the task up and puts it into the local runqueue."
The GNU/Hurd home page says, "The Hurd is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux)". Over time, however, this may change.
In a recent thread, Farid Hajji offered an update no the Hurd/L4 port. The goal here is to replace the aging Mach microkernel with the newer L4 microkernel. The effort is still in the early stages, Farid describing it so far as a "skeleton project". Current efforts use the Hazelnut implementation (v2), though the plan is to use Pistachio (v4) when it's ready, adding 64bit support.
More details can be found in Farid's email. Read on...
James Simmons announced innocently enough on the lkml, "Just to let you know I created a bitkeeper repository for the framebuffer layer." M. R. Brown replied a couple hours later, "Please tell us that primary framebuffer/input/console development will continue in the CVS drop-in tree on SourceForge? "
Richard Gooch pointed out that the serial driver was broken in 2.4.19-pre7. Alan Cox explains, "Yes. Someone put the HCDP below not above the basic x86 ports. Tweak include/asm-i386/serial.h and that should be well."
So if you're going to use 2.4.19-pre7 and need your serial port, then you need to apply this patch.
Mike Fedyk asked on the lkml why the -aa VM update hasn't gone into 2.5 yet. Andrew Morton, who recently split the large -aa update into smaller pieces for 2.4 inclusion explained that now was the wrong time for such an effort. Andrew's current focus in 2.5 is the buffer layer, and because of the intamacy between this layer and the VM, adding the -aa patches "would represent some wasted effort."
Also mentioned was the possibilty that 2.5 will use Rik van Riel's rmap VM, and hence tuning the existing VM would again be "wasted effort". In summary, Andrew offered, "So. My vote would be that unless the VM is actually impeding developers who are working on other parts of the kernel (it is not) then just leave it as-is for the while.".
It was also pointed out that the -aa patches are currently being merged into the 2.4 stable kernel.
Guy Bormann posted a question to the help-hurd mailing list after bowsing Wolfgang Jahrling's Hurd Hacking Guide. The guide looks to be quite useful, saying about itself:
"This document is an introduction to GNU Hurd and Mach programming. The purpose of this guide is to help interested people start hacking the Hurd or extending it (by writing translators). It gives lots of references to the Hurd- or GNU Mach source files. It is recommended that you read through some of these sources. Indeed the Hurd sources are very well written and commented and you can learn a lot by reading them."
Guy's question relates to how various Mach libraries allocate memory, and when it's the progammer's responsibility to free such allocated memory. Marcus Brinkmann offers a detailed reply.
John Looney recently posted to the lkml, asking about the possibilty of one computer serving multiple users. That is to say, multiple keyboards, mice, monitors, etc, hooked up to a single server. The advantages of such a setup in a lab type environment are obvious.
The following discussion ranges through several technical issues with such a configuration, including a kernel limitation of one virtual terminal active at a time, and the typical lack of quality in long video cables. However, none of the issues raised are unbeatable. James Simmons, for example, has been working on cleaning up the virtual terminal code, with many related fixes already merged into Dave Jones' tree.
Another hack exists. Miguel Freitas has a page titled, Multiple local XFree users under Linux on which he details using multiple instances of XFree86 and a dual-head video card to support two keboards/mice/monitors.