Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #295 For 3 Feb 2005

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 2891 posts in 16785K.

There were 589 different contributors. 321 posted more than once. 216 posted last week too.

The top posters of the week were:

1. Linux 2.6.10-mm1 Released

3 Jan 2005 - 15 Jan 2005 (126 posts) Archive Link: "2.6.10-mm1"

Topics: Kernel Release Announcement, PCI, POSIX, Sound: ALSA, Sound: OSS, Version Control

People: Andrew MortonTakashi IwaiAlan CoxLee RevellLinus Torvalds

Andrew Morton announced Linux 2.6.10-mm1, saying:

Mark H. Johnson reported some problems with audio. He posted a bug report, and Takashi Iwai replied, "The default blocking behavior of OSS devices was changed recently. When the device is in use, open returns -EBUSY immediately in the latest version while it was blocked until released in the former version." Andrew Morton's eyes bugged out, and he replied, "whoa. That's a significant change in user-visible behaviour. Why was this done?" Lee Revell gave a pointer to an email from Linus Torvalds. Mark was disconcerted by the whole business as well, and also asked for an explanation. Alan Cox explained:

OSS itself changed behaviour over time (2.2 to 2.4) ALSA has merely caught up with the newer OSS behaviour and the new behaviour is correct.

If you want to find out if the interface is busy open it. If you want to do it portably open it with O_NDELAY.

Lee added, "And if you want to find out who is using it then try fuser /dev/dsp, fuser /dev/snd/*, or lsof."

In a nearby sub-thread, Alan also added, "It now emulates the later OSS PCI and other devices not 2.2 OSS. As such its the right thing to have done for emulation of OSS IMHO. It also works with more apps several of which hang on opening /dev/dsp0 expecting OSS -EBUSY responses."

Takashi said historically:

It was discussed on alsa-devel in November. Unfortunately, I can't find ML archive any longer...

The blocking behavior of OSS is a feature which is nowehre defined. Some OSS drivers open in the blocking mode and some don't. So, apps shouldn't depend on this feature.

We had implemented OSS emulation in the blocking manner since we intepreted the POSIX definition in that way. But Linus pointed out that it's a misreading.

BTW, you can enable the blocking mode again via module/boot option. See OSS-Emulation.txt.

Lee followed up with:

if you want the excruciating details, here are some pointers. It's a long thread, and unfortunately the threading is a little broken.

Here's a link to the technical part:

And here's the rant that started it:

2. Linux 2.6.10-mm2 Released

6 Jan 2005 - 13 Jan 2005 (80 posts) Archive Link: "2.6.10-mm2"

Topics: Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced Linux 2.6.10-mm2, with "Various minorish updates and fixes" , and there was the usual set of bug-hunts.

3. Tracking Process Memory Usage In /proc

6 Jan 2005 - 19 Jan 2005 (16 posts) Archive Link: "[PATCH] A new entry for /proc"

Topics: FS: procfs, Real-Time

People: Mauricio LinAndrew MortonRoger LuethiHugh DickinsEdjard Souza Mota

Mauricio Lin said, "Here is a new entry developed for /proc that prints for each process memory area (VMA) the size of rss. The maps from original kernel is able to present the virtual size for each vma, but not the physical size (rss). This entry can provide an additional information for tools that analyze the memory consumption. You can know the physical memory size of each library used by a process and also the executable file." Andrew Morton replied, "This is potentially quite useful. I'd be interested in what others think of the idea and implementation." Roger Luethi offered a negative critique:

With split interfaces (machine-/human-readable) as proposed a few months ago, we wouldn't need to clutter /proc with such cruft. We could simply add the obvious field to /proc/maps and add another field to nproc.

Using procfs for both humans and software means over time it will get worse for _both_ sides, and switching to a saner solution won't get cheaper, either. I still believe we should bite that bullet now.

Hugh Dickins was also skeptical:

Well, it goes back to just what wli freed 2.6 from, and what we scorned clameter for: a costly examination of every pte-slot of every vma of the process. That doesn't matter _too_ much so long as there's no standard tool liable to do it every second or so, nor doing it to every single process, and it doesn't need spinlock or preemption disabled too long.

But personally I'd be happier for it to remain an out-of-tree patch, just to discourage people from writing and running such tools, and to discourage them from adding other such costly analyses.

Potentially quite useful, perhaps. But I don't have a use for it myself, and if I do have, I'll be content to search out (or recreate) the patch. Let's hear from those who actually have a use for it now - the more useful it is, of course, the stronger the argument for inclusion.

Edjard Souza Mota was more in favor, saying, "I belive we've just found a potentially important use of it. We tested the old version of this patch for applications running on the Sarge Debian Distro for ARM platform (can be found We tested only on OMAP 1510 and 5912. The advantage we found is that these little numbers can be used to help control the memory consumption for embedded devices like the one we tested. A fine grain memory control can help us envisage how memory is consumed with such systems that usually lack swap space. If they ever have (allocating space from flash memory) the tiny control give us a better picuture where we should work on optimising memory consumption."

4. linux-libc-headers Version Released

8 Jan 2005 - 13 Jan 2005 (13 posts) Archive Link: "[ANNOUNCE] linux-libc-headers"

People: Mariusz MazurRandy Dunlap

Mariusz Mazur announced linux-libc-headers version, saying:

Available at


Two weeks after 2.6.10, but you can blame Linus for releasing 2.6.10 just before Christmas.

Like I've said two months ago - my scripts for testing new versions now do separate asm-i386-ansi and asm-i386-noansi checks, so any ansi degradation in linux or asm-i386 (like the one from 2.6.9) won't go unnoticed.

One more thing - llh is now officially one year old (first commits are from December 2003). That's a long time for any hack to live. Especially a hack this big and one that even has a couple of vendor specific variants. A couple of discussions took place concerning this matter (in the last one Linus even said, that he'll be accepting patches) and still I see no movement. I'd really like to see glibc guys figuring out a way not to duplicate definitions and structures from linux and starting to submit patches. That'd be a really good (and much needed - glibc's and linux' headers conflict in lots of ugly ways) first step.

Randy Dunlap encouraged Mariusz not to give up, saying he'd help in spite of not being a glibc person.

5. Listing All Registered Kprobes

10 Jan 2005 - 20 Jan 2005 (13 posts) Archive Link: "[PATCH] Kprobes /proc entry"

People: Luca FalavignaGreg KHNathan LynchPrasanna S. PanchamukhiPrasanna S. Panchamuk

Luca Falavigna said, "This simple patch adds a new file in /proc, listing every kprobe which is currently registered in the kernel. This patch is checked against kernel 2.6.10" . Greg KH replied, "No, please do not add extra /proc files to the kernel. This belongs in /sys, as it has _nothing_ to do with processes." Nathan Lynch said, "Wouldn't this sort of thing be a good candidate for debugfs? If you're messing with kprobes, then aren't you by definition doing kernel debugging? :)" Greg replied, "That's an even better idea, I like it." Luca said he'd get right to work on this, and Prasanna S. Panchamukhi said, "kernel probes can also be listed using SysRq key. Below is the small patch that provides this feature." Meanwhile, Luca finished porting his own patch to DebugFS, and offered it up for review. With the basic structure settled, Greg focused more on the technical details of the patch, and they went back-and-forth on it for a few posts.

6. Reporting Linux Security Problems

10 Jan 2005 - 20 Jan 2005 (18 posts) Archive Link: "Proper procedure for reporting possible security vulnerabilities?"

Topics: MAINTAINERS File, Version Control, Virtual Memory

People: Steve BergmanAlan CoxFlorian WeimerChris WrightLinus TorvaldsGreg KHMarcelo Tosatti

Steve Bergman asked:

There seems to be some confusion in certain quarters as to the proper procedure for reporting possible kernel security issues. REPORTING-BUGS says send bug reports to the maintainer of that area of the kernel. However, what about areas for which a maintainer is not listed? (e.g. VM) It seems that some take that to mean send it directly to Linus and if you don't hear something back quickly, release an exploit to the wild.

So what is the preferred procedure and is it documented somewhere? Should it be made more prominent?

Alan Cox replied:

Good question. The preferred procedure depends on your viewpoint on disclosure

[email protected] is a cross vendor security list and a good place for stuff. It will deal with both public and date embargoed security information. [email protected][your-vendor] should work for most responsible vendors and may be more appropriate if it involves a vendor kernel that may have bugs not in the base tree.

For stuff in -bk kernel snapshots and the like that isn't in the production kernels then I'd start by mailing Linus/(Andrew for -mm) or the list.

Florian Weimer remarked, "Some people claim that vendor-sec is not trustworthy anymore because it leaks information, based on the recent forged e-matters advisory. Personally, I think the intent of the forgers was to discredit vendor-sec. There's no hard no evidence that there is a systematic leak (apart from the occasional blunders)."

In the course of discussion, Chris Wright created [email protected], and posted a patch listing it in the MAINTAINERS file as the proper place to submit security bug reports. Alan and others supported this.

In a different thread with Subject: thoughts on kernel security issues, Chris said:

This same discussion is taking place in a few forums. Are you opposed to creating a security contact point for the kernel for people to contact with potential security issues? This is standard operating procedure for many projects and complies with RFPolicy.

Right now most things come in via 1) lkml, 2) maintainers, 3) vendor-sec. It would be nice to have a more centralized place for all of this information to help track it, make sure things don't fall through the cracks, and make sure of timely fix and disclosure.

In addition, I think it's worth considering keeping the current stable kernel version moving forward (point releases ala 2.6.x.y) for critical (mostly security) bugs. If nothing else, I can provide a subset of -ac patches that are only that.

I volunteer to help with _all_ of the above.

Linus Torvalds replied, "I wouldn't mind, and it sounds like a good thing to have. The _only_ requirement that I have is that there be no stupid embargo on the list. Any list with a time limit (vendor-sec) I will not have anything to do with. If that means that you can get only the list by invitation-only, that's fine." A couple of posts later, he clarified:

I'd very happy with a "private" list in the sense that people wouldn't feel pressured to fix it that day, and I think it makes sense to have some policy where we don't necessarily make them public immediately in order to give people the time to discuss them.

But it should be very clear that no entity (neither the reporter nor any particular vendor/developer) can require silence, or ask for anything more than "let's find the right solution". A purely _technical_ delay, in other words, with no politics or other issues involved.

Otherwise it just becomes politics: you end up having security firms that want a certain date because they want a PR blitz, and you end up having vendors who want a certain date because they have release issues.

Does that mean that vendor-sec would end up being used for some things, where people _want_ the politics and jockeying for position? Probably. But having a purely technical alternative would be wonderful.

Greg KH said privately to Linus, "So you would be for a closed list, but there would be no incentive at all for anyone on the list to keep the contents of what was posted to the list closed at any time? That goes against the above stated goal of complying with RFPolicy." Linus quoted him on linux-kernel, replying:

There's already vendor-sec. I assume they follow RFPolicy already. If it's just another vendor-sec, why would you put up a new list for it?

In other words, if you allow embargoes and vendor politics, what would the new list buy that isn't already in vendor-sec.

When I saw how vendor-sec worked, I decided I will never be on an embargo list. Ever. That's not to say that such a list can't work - I just personally refuse to have anything to do with one. Whether that matters or not is obviously an open question.

Marcelo Tosatti countered:

Of course it matters Linus - vendors need time to prepare their updates. You can't ignore that, and you can't "have nothing to do with it".

You seem to dislike the way embargos have been done on vendorsec, fine. They can be done on a different way, but you have to understand that you and Andrew need to follow and agree with the embargo.

How you feel about having short fixed time embargo's (lets say, 3 or 4 days) ?

The only reason for this is to have "time for the vendors to catch up", which can be defined by the kernel security office. Nothing more - no vendor politics involved.

It is a simple matter of synchronization.

Linus replied:

Please realize that I don't have any problem with a short-term embargo per se, what I have problems with is the _politics_ that it causes. For example, I do _not_ want this to become a

"vendor-sec got the information five weeks ago, and decided to embargo until day X, and then because they knew of the 4-day policy of the kernel security list, they released it to the kernel security list on day X-4"

See? That is playing politics with a security list. That's the part I don't want to have anything to do with. If somebody did that to me, I'd feel pissed off like hell, and I'd say "screw them".

But in the absense of politics, I'd _happily_ have a self-imposed embargo that is limited to some reasonable timeframe (and "reasonable" is definitely counted in days, not weeks. And absolutely _not_ in months, like apparently sometimes happens on vendor-sec).

So if the embargo time starts ticking from _first_ report, I'd personally be perfectly happy with a policy of, say "5 working days" (aka one week), or until it was made public somewhere else.

IOW, if it was released on vendor-sec first, vendor-sec could _not_ then try to time the technical list (unless they do so in a very timely manner indeed).

I'm not saying that we'd _have_ to go public after five days. I'm saying that after that, there would be nothing holding it back (but maybe the technical discussion on how to _fix_ it is still on-going, and that might make people just not announce it until they're ready).

Elsewhere, Linus clarified:

Btw, the only thing I care about is the embargo on the _fix_.

If a bug reporter is a security house, and wants to put a longer embargo on announcing the bug itself, or on some other aspect of the issue (ie known exploits etc), and wants to make sure that they get the credit and they get to be the first ones to announce the problem, that's fine by me.

The only thing I really care about is that we can serve the people who depend on us by giving them source code that is as bug-free and secure as we can make it. If that means that we should make the changelogs be a bit less verbose because we don't want to steal the thunder from the people who found the problem, that's fine.

One of the problems with the embargo thing has been exactly the fact that people couldn't even find bugs (or just uglinesses) in the fixes, because they were kept under wraps until the "proper date".

Elsewhere he also said, "I'm a big believer in _total_ openness. Accept the fact that bugs will happen. Be open about them, and fix them as soon as possible. None of this cloak-and-dagger stuff." Elsewhere, he also added:

Quite frankly, nobody should ever depend on the kernel having zero holes. We do our best, but if you want real security, you should have other shields in place. exec-shield is one. So is using a compiler that puts guard values on the stack frame (immunix, I think). But so is saying "you can't just compile or download your own binaries, nyaah, nyaah, nyaah".

As I've already made clear, I don't believe one whit in the "secrecy" approach to security. I believe that "security through obscurity" can actually be one valid level of security (after all, in the extreme case, that's all a password ever really is).

So I believe that in the case of hiding vulnerabilities, any "security gain" from the obscurity is more than made up for by all the security you lose though delaying action and not giving people information about the problem.

I realize people disagree with me, which is also why I don't in any way take vendor-sec as a personal affront or anything like that: I just think it's a mistake, and am very happy to be vocal about it, but hey, the fundamental strength of open source is exactly the fact that people don't have to agree about everything.

Elsewhere, Linus also said:

it's very clear that some exploits have definitely been written by looking at the source code with automated tools or by instrumenting things, and that the exploits would likely have never been found without source code. That's fine. We just have higher requirements in the open source community.

And I do think that the same is true for being open about security advisories: I think that to offset an open security list, we'd have to then have more "best practices" than a vendor-sec-type closed security list might need. I think it would be worth it.

This was quite a long thread, with a lot of folks on the other side of the fence, including Alan and other big-time kernel hackers. It looks like [email protected] will exist though, and be a primary location for discussing Linux kernel security issues.

7. Linux 2.6.11-rc1 Released

11 Jan 2005 - 20 Jan 2005 (42 posts) Archive Link: "Linux 2.6.11-rc1"

Topics: Disks: IDE, Disks: SCSI, Kernel Release Announcement, Power Management: ACPI, Sound: ALSA, USB, Virtual Memory

People: Linus TorvaldsSergey S. KostyliovNick PigginAndi Kleen

Linus Torvalds announced Linux 2.6.11-rc1, saying:

Ok, the big merges after 2.6.10 are hopefully over, and 2.6.11-rc1 is out there.

Lots of small cleanups, although that inevitable qlogic firmware update makes pretty much _everything_ look small in comparison.

SCSI, USB, IDE, x86-64, FRV, PPC64, ARM, input layer, ALSA, network drivers, pcmcia, knfsd, ACPI, sparse cleanups... You name it. Lots of (mostly) small updates all over the landscape.

What gets hidden in the noise of all the updates is things like the conversion to 4-level page tables by Andi Kleen and Nick Piggin. That makes us able to use the full virtual memory space on 64-bit architectures. The patches may not be very large, and in fact it was interesting to see just how smoothly it seems to integrate.

Sergey S. Kostyliov reported, "2.6.10-rc1 hangs at boot stage for my dual opteron machine" , and Linus replied, "Oops, yes. There's some recent NUMA breakage - either disable CONFIG_NUMA, or apply the patches that Andi Kleen just posted on the mailing list (the second option much preferred, just to verify that yes, that does fix it)." Sergey confirmed that Andi's patch fixed his problem.

8. Linux 2.4.29-rc2 Released

12 Jan 2005 - 15 Jan 2005 (16 posts) Archive Link: "Linux 2.4.29-rc2"

Topics: SMP

People: Marcelo Tosatti

Marcelo Tosatti announced Linux 2.4.29-rc2, saying:

Here goes the second release candidate of v2.4.29.

It contains mainly security fixes, including backports from 2.6-ac Coverity fixes, rework of the do_brk() fixes as suggested by Linus, and a fix for the pagefault SMP race disclosed today:


9. RAID For Tape Drives (RAIT)

13 Jan 2005 (4 posts) Archive Link: "RAIT device driver feasibility"

Topics: Disk Arrays: RAID

People: Ludovic DrolezAlan Cox

Ludovic Drolez said, "I'd like to know if it's easy to write a RAID like device for tapes (RAIT)... For block devices, hooks are present in the kernel code, but for char devices, is there a way to implement a write function for example, which will write in parallel to N /dev/stX tape devices? RAIT already exists in Amanda, in user space, but I'd like to see a generic kernel RAIT driver which could be used by any backup program." Alan Cox replied, "Why kernel space - why not a user space shared library you can add to other tape apps?" But the discussion petered out.

10. More Discussion Of Security Discussions

13 Jan 2005 - 18 Jan 2005 (12 posts) Archive Link: "security contact draft"

People: Chris WrightAlan CoxLinus TorvaldsMarcelo TosattiFlorian WeimerChris Wright:

Continuing the security discussion from Issue #295, Section #6  (10 Jan 2005: Reporting Linux Security Problems) , Chris Wright said:

To keep the conversation concrete, here's a pretty rough stab at documenting the policy.

Linux kernel developers take security very seriously. As such, we'd like to know when a security bug is found so that it can be fixed and disclosed as quickly as possible.

1) Contact

The Linux kernel security contact is $CONTACTADDR. This is a private list of security officers who will help verify the bug report and develop and release a fix. It is possible that the security officers will bring in extra help from area maintainers to understand and fix the security vulnerability.

It is preferred that mail sent to the security contact is encrypted with $PUBKEY.

As it is with any bug, the more information provided the easier it will be to diagnose and fix. Please review the procedure outlined in REPORTING-BUGS if you are unclear about what information is helpful. Any exploit code is very helpful and will not be released without consent from the reporter unless it's already been made public.

2) Disclosure

The goal of the kernel security contact is to work with the bug submitter to bug resolution as well as disclosure. We prefer to fully disclose the bug as soon as possible. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested or for vendor coordination. However, we expect these delays to be short, measurable in days, not weeks or months. As a basic default policy, we expect report to disclosure to be on the order of $NUMDAYS.

Alan Cox remarked, "It's not documenting the stuff Linus seems to be talking about which is a public list ? Or does Linus want both ?" Linus Torvalds replied:

I see myself as pretty extreme when it comes to my approach to security.

And I actually distrust extremes. I'm at one end of the spectrum, and vendor-sec is at the other (I'm not even counting the head-in-the-sand approach as part of the spectrum ;). Knowing that, I'd expect that most people are somewhere in between.

Which to me implies that while what I personally _want_ is total openness, that's not necessarily what makes the most sense in real life.

So I want to give people choice. I want to encourage openness. But hell, if we have a closed list with a declared short embargo that is known to not play games (ie clock starts ticking from original discovery, not from somebody elses embargo), that's good too.

Let people vote with their feet. If vendor-sec ends up being where all the "important" things are discussed - so be it. We've not lost anything, and at worst a "kernel-security" list would be a way to discuss stuff that was already released by vendor-sec.

Marcelo Tosatti was glad to see Linus not insisting on total openness; and said:

On my understanding we are about to win several things.

I rather prefer having vendorsec NOT deal with these issues because it gives autonomy to the kernel team. It wont depend on "suspicious" criteria of embargo's - but instead have a clear written policy for embargo's.

And the timeframe, as Alan says, has to be acceptable for the vendors to generate their updates and run the QA process, otherwise things will continue to be discussed at vendorsec.

Other than that, by not "wrapping" the fixes with non descritive changelogs, we will have an official list of security problems. Hey, this is a serious operating system.

Wrapping up fixes means "disclosure" for the better informed people (the bad guys) who read the changesets, and means "lack of knowledge" for the less informed - users who dont run the latest kernel and only upgrade in case of public security issues (the majority of them?).

So the argument of "wrapping" up fixes for "better and safer code" is actually very bad if you think about it.

Once we have that, there will be a "official" list of known issues.

Those MANY who ask "I'm using v2.6.12 on my customized kernel and I can't upgrade to the latest v2.6.20 kernel, which security bugs exist that I need fixed?"

Will have an easy answer.

This is better for the Linux kernel developers, better for vendors and better for users.

Elsewhere, Florian Weimer approved of Chris' text, though he suggested adding something that said the security list was not a formal body and therefore could not enter into Non-Disclosure Agreements with anyone. He said, "UNIRAS and probably others require NDAs from affected software vendors before they share vulnerability information. It makes things easier if you state upfront that you won't play such games." Chris said he'd add that. Alan asked, "Is it worth adding the stipulation up front about who sets release dates and within what limit as well" ? Chris replied:

Guess it's an open question. Do you agree with these basics bits?

Hard to put real time on it.

Alan said, "Its emphasising "release date set by linux-security not reporter" rather than length - although length guidance is good." Chris posted an updated draft:


Linux kernel developers take security very seriously. As such, we'd like to know when a security bug is found so that it can be fixed and disclosed as quickly as possible. Please report security bugs to the Linux kernel security team.

1) Contact

The Linux kernel security team can be contacted by email at $CONTACTADR. This is a private list of security officers who will help verify the bug report and develop and release a fix. It is possible that the security team will bring in extra help from area maintainers to understand and fix the security vulnerability.

It is preferred that mail sent to the security team is encrypted with $PUBKEY.

As it is with any bug, the more information provided the easier it will be to diagnose and fix. Please review the procedure outlined in REPORTING-BUGS if you are unclear about what information is helpful. Any exploit code is very helpful and will not be released without consent from the reporter unless it has already been made public.

2) Disclosure

The goal of the Linux kernel security team is to work with the bug submitter to bug resolution as well as disclosure. We prefer to fully disclose the bug as soon as possible. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested or for vendor coordination. However, we expect these delays to be short, measurable in days, not weeks or months. A disclosure date is negotiated by the security team working with the bug submitter as well as vendors. However, the kernel security team holds the final say when setting a disclosure date. The timeframe for disclosure is from immediate (esp. if it's already publically known) to a few weeks. As a basic default policy, we expect report date to disclosure date to be on the order of 7 days.

3) Non-disclosure agreements

The Linux kernel security team is not a formal body and therefore unable to enter any non-disclosure agreements.

11. Semantics Of Subtree Sharing

13 Jan 2005 - 18 Jan 2005 (20 posts) Archive Link: "[RFC] shared subtrees"

Topics: FS: autofs

People: Alexander Viro

Alexander Viro posted a lengthy proposal (some typos were found after discussion; fixes are incorporated here):

NOTE: as far as I'm concerned, that's a beginning of VFS-2.7 branch. All that work will stay in a separate tree, with gradual merge back into 2.6 once the things start settling down.

OK, here comes the first draft of proposed semantics for subtree sharing. What we want is being able to propagate events between the parts of mount trees. Below is a description of what I think might be a workable semantics; it does *NOT* describe the data structures I would consider final and there are considerable areas where we still need to figure out the right behaviour.

Let's start with introducing a notion of propagation node; I consider it only as a convenient way to describe the desired behaviour - it almost certainly won't be a data structure in the final variant.

  1. each p-node corresponds to a group of 1 or more vfsmounts.
  2. there is at most 1 p-node containing a given vfsmount.
  3. each p-node owns a possibly empty set of p-nodes and vfsmounts
  4. no p-node or vfsmount can be owned by more than one p-node
  5. only vfsmounts that are not contained in any p-nodes might be owned.
  6. no p-node can own (directly or via intermediates) itself (i.e. the graph of p-node ownership is a forest).

These guys define propagation:

a) if vfsmounts A and B are contained in the same p-node, events propagate from A to B
b) if vfsmount A is contained in p-node p, vfsmount B is contained in p-node q and p owns q, events propagate from A to B
c) if vfsmount A is contained in p-node p and vfsmount B is owned by p, events propagate from A to B
d) propagation is transitive: if events propagate from A to B and from B to C, they propagate from A to C.

In other words, members of the same p-node are equivalent and events anywhere in p-node are propagated to all its slaves. Note that not any transitive relation can be represented that way; it has to satisfy the following condition:

* A->C and B->C => A->B or B->A

All propagation setups we are going to deal with will satisfy that condition.

How do we set them up?

* we can mark a subtree sharable. Every vfsmount in the subtree that is not already in some p-node gets a single-element p-node of its own.

* we can mark a subtree slave. That removes all vfsmounts in the subtree from their p-nodes and makes them owned by said p-nodes. p-nodes that became empty will disappear and everything they used to own will be repossessed by their owners (if any).

* we can mark a subtree private. Same as above, but followed by taking all vfsmounts in our subtree and making them *not* owned by anybody.

Of course, namespace operations (clone, mount, etc.) affect that structure and are affected by it (that's what it's for, after all).


That one is simple - we copy vfsmounts as usual

2. mount

We have a new vfsmount A and want to attach it to mountpoint somewhere in vfsmount B. If B does not belong to any p-node, everything is as usual; A doesn't become a member or slave of any p-node and is simply attached to B.

If B belongs to a p-node p, consider all vfsmounts B1,...,Bn that get events propagated from B and all p-nodes p1,...,pk that contain them.

In other words, mount is propagated and propagation among the new vfsmounts mirrors the propagation between mountpoints.

3. bind

bind works almost identically to mount; new vfsmount is created for every place that gets propagation from mountpoint and propagation is set up to mirror that between the mountpoints. However, there is a difference: unlike the case of mount, vfsmount we were going to attach (say it, A) has some history - it was created as a copy of some pre-existing vfsmount V. And that's where the things get interesting:

4. rbind

rbind is recursive bind, so we just do binds for everything we had in a subtree we are binding in obvious order; everything is described by previous case.

5. umount

umount everything that gets propagation from victim.

6. mount --move

prohibited if mountpoint of what we are moving is in some p-node, otherwise we move as usual to intended mountpoint and create copies for everything that gets propagation from there (as we would do for rbind).

7. pivot_root

similar to --move

How to use all that stuff?

Example 1:

mount --bind /floppy /floppy
mount --make-shared /floppy
mount --rbind / /jail
<finish setting the jail up, umount whatever doesn't belong there, etc.>
mount --make-slave /jail/floppy

and we get /floppy in chroot jail slave to /floppy outside - if somebody (u)mounts stuff on it, that will get propagated to jail.

Example 2:

same, but with the namespaces instead of chroots.

Example 3:

same subtree visible (and kept in sync) in several places - just mark it shared and rbind; it will stay in sync

Example 4:

have some daemon control the stuff in a subtree sharable with many namespaces, chroots, etc. without any magic:
mark that subtree sharable
clone with CLONE_NS
parent marks that subtree slave
child keeps working on the tree in its private namespace.

There's a lot more applications of the same idea, of course - AFS and its ilk, autofs-like stuff (with proper handling of MNT_EXPIRE and traps - see below), etc., etc.

Areas where we still have to figure things out:

12. QLA2XXX Maintainership

14 Jan 2005 (1 post) Archive Link: "[PATCH] MAINTAINERS: add entry for qla2xxx driver."

Topics: Disks: SCSI, MAINTAINERS File

People: Andrew Vasquez

Andrew Vasquez posted a patch to MAINTAINERS, listing himself as the official maintainer of the Qlogic QLA2XXX FC-SCSI driver.

13. Status Of SATA Hotplug Support

14 Jan 2005 (2 posts) Archive Link: "SATA hotplug status (sii3114)"

Topics: Hot-Plugging, Serial ATA

People: Jeff Garzik

Andy Helten asked about the status of SATA hotplug support, and Jeff Garzik replied:

There's a plan but no code yet. :)

[email protected] is where this stuff gets discussed (though there's nothing on there recently about hotplug).

14. Linux 2.4.29-rc3 Released

15 Jan 2005 (2 posts) Archive Link: "Linux 2.4.29-rc3"

People: Marcelo Tosatti

Marcelo Tosatti announced Linux 2.4.29-rc3, saying:

Here goes the third release candidate.

This one comes out to release a bunch of pending networking fixes from David Miller: netfilter, sctp, ipvs, etc.

Also changes the tty ldisc locking patches to not export a couple of API functions as GPL, because that breaks compatibility with older modutils.

This will become final if no problems appear.

Please help with testing!

15. Some Discussion Of Patents

17 Jan 2005 - 18 Jan 2005 (6 posts) Archive Link: "IBM Patents"

Topics: Patents

People: Richard B. JohnsonJames BruceChris Lingard

Richard B. Johnson said:

IBM has announced that it will provide free access to about 500 of its existing software patents to users and groups working on open source software.

Many of these patents relate to interoperability, communications, file-export protocols, and dynamic linking.

Bernd Petrovitsch thought this was only a marketing ploy, and pointed out that IBM had only promised not to bring lawsuits against open source projects in those 500 cases. James Bruce remarked, "I believe that IBM is simply responding to the recent study that "Linux violates more than 283 patents". Regardless of the truth to that study, this is IBM's way of stating that the 60 that they hold will not be used against Linux or other open source projects." Chris Lingard said, "The study said that it may violate patents; but that those patents may not be enforceable due to prior art. Only a court of law; and only in the USA could your statment be tested."

16. Status Of iswraid In 2.4

18 Jan 2005 (10 posts) Archive Link: "iswraid and 2.4.x?"

Topics: Disk Arrays: RAID

People: Jeff GarzikMartins KrikisMarcelo Tosatti

Martins Krikis wanted to get his iswraid patches accepted into the 2.4 tree, and asked if they might appear in 2.4.30. Marcelo Tosatti was initially dubious about the prospect. He wanted to avoid anything that was not absolutely critical for 2.4. Jeff Garzik spoke up however, saying he supported iswraid in the 2.4 tree; and Marcelo asked Jeff to look the patch over to make sure it would be OK. Jeff replied, "Check your inbox from months ago ;-) AFAICS his current version addresses all the comments from Alan and myself, from when it hit lkml 6 months(?) ago... I'll give it another quick lookover though, sure." Martins replied, "As long as 2.4.30 is planned at all, I have no more worries for the moment. But if so, then please don't waste your time looking over the current version. In about a week there should really be another one out. It will add RAID10, and get rid of the "claim disks for RAID" mis-feature. I'll let everybody know, of course."

17. New Collision Regression Test Suite

18 Jan 2005 - 19 Jan 2005 (4 posts) Archive Link: "[ANNOUNCEMENT] Collision regression test suite released"

Topics: BSD

People: Lorenzo Hernández García-HierroChris Wright

Lorenzo Hernández García-Hierro said:

Past days I wrote about a regression test suite which i used to explain why a grsecurity-like security improvement could be good for mainline inclusion, and also, that at least the 50% of the faults it shows on Vanilla sources could be solved without major blocking issues (aka big deals, whatever else).

I've released the code, so, everybody could mess it up and send me patches with fixes, enhancements, extra features or better source comments ;)

The source code is available at

An example results log dumped by it when running on a default Vanilla kernel (no security patches, etc) can be found at:

In the forthcoming days i will try to add more tests to it, mainly related with capabilities and such, for SELinux and LSM testing. Also, maybe an ExecShield specific test (see [1] and [2]) and possibly a few other tests related with BSD Jails.

I would like to have feedback about it, but it's main goal is to show that there are still some security "faults" that affect users of Vanilla sources that can be solved without a lot of pain and could represent a start for those who want better security worked on many time before me and have been ignored or just left working alone and independently.

The suite has some tests related with "toolchain" hardening, but most stuff is kernel-related.

Chris Wright asked, "Do you categorize the faults in any way?" and Lorenzo replied, "There are separators to make sections of similar tests, but still not a nifty "per-type" sections organization. I would like to improve it and use percents and such instead of simple "Vulnerable" and "Not vulnerable" results, so, you can have a global idea of the current security status. Patches are welcome, as I don't have a lot of time now (school "normal" rhythm started this week)."

18. Linux 2.4.29-rc4 Released

19 Jan 2005 (1 post) Archive Link: "Linux 2.4.29-rc4"

Topics: USB

People: Marcelo Tosatti

Marcelo Tosatti announced Linus 2.4.29-rc4, saying:

Here goes the fourth release candidate.

It reverts the root mount retry patch for USB/special devices, this is going to get fixed cleanly on v2.6.

And updates the i386 defconfig.

v2.4.29 announcement should follow shortly

19. Linux 2.4.29 Released

19 Jan 2005 (2 posts) Archive Link: "linux-2.4.29 released"

People: Marcelo Tosatti

Marcelo Tosatti announced Linux 2.4.29, as 2.4.29-rc4 with no changes.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.