The attached patch adds LSM hooks for key management facilities. The notable changes are:

1. The key struct now supports a security pointer for the use of security modules. This will permit key labelling and restrictions on which programs may access a key.
2. Security modules get a chance to abort the allocation of a key.
3. Two new keyctl functions have been added to associate security data with a key and to retrieve it. They talk directly to the security modules and have no other function.
4. The key permission checking can now be overridden by or enhanced by the security modules. It has also been moved out of the key-ui.h header file into permission.c file since it's quite large and it's used a lot.
5. Security modules may review the data with which a key will be instantiated or updated.

Note that there isn't an LSM hook specifically for each keyctl() operation, but rather the permissions hook allows control of individual operations based on the permission request bits.

Key management access control through LSM is enabled by CONFIG_SECURITY_KEYS.

I think this looks ok from an SELinux point of view if keys are treated as opaque objects, i.e. like files.

We could do something like create a new object class (kernkey or something) and implement SELinux permissions for the class such as read, write, search, link, setattr and getattr. Your KEY_VIEW perm could be translated to SELinux getattr.

More thought needs to go into whether we need to implement an SELinux create permission (and add hooks into the code), for control over whether a process can create an anonymous keyring.

I'm not sure if we need user-level labeling of keys via the set & get security ops, although LSPP may require some form of get_security. If we don't need to manually set security attributes but still view them, they could be displayed via /proc/keys rather than implementing a separate multiplexed syscall.

It seems that there are no LSM checks for the following:

keyctl_chown_key()
keyctl_setperm_key()
keyctl_set_reqkey_keyring()

keyctl_join_session_keyring() [only if we add a 'create' perm]

All users of key_permission() need to propagate the error code from the LSM back to the user.

This is following that set of patch: http://marc.theaimsgroup.com/?l=linux-kernel&m=112557274910448&w=4 to get a simpler structure of the vmlinux boot file, named like: /boot/linux-2.6.14.kgz

This linux-*.kgz format is the "native" format of the Gujin bootloader which can be found here: http://gujin.org

The main change of this set of patch is the rewrite of nearly all the ia16/ia32 assembler of Linux into a C file named "realmode.c", and its include "realmode.h". The mapping of the 4 Kbytes memory page exchanged in between real mode and protected mode is exactly the same, but is described in a C structure - a lot cleaner.

Another big change is that the GZIP compressed file produced during Linux compilation now contains a comment describing some important information: which processor this kernel has been compiled for (so no invalid instruction crash when running a Athlon compiled kernel on a Pentium - but a nice error message from the bootloader), which video mode the kernel support (VGA text or VESA, and which VESA)...

If you apply this set of patch, you still can use the old method to boot a kernel with LILO, Loadlin, Grub or SYSLINUX, and this patch will not modify any assembler instruction executed on this boot path when you use "make bzImage" or the like.

To produce the new format you just have to apply at least the first two patch and type "make /boot/linux-gujin.kgz ROOT=auto", or apply the 3rd patch to get root autodetection (based on the partition/directory of the linux*.kgz file loaded) and type "make /boot/linux-gujin.kgz". (also see "make help")

This set has few changes: applies on all distributions (end-of-line at end-of-file problem on Fedora3), updated to apply on 2.6.13-rc3 - or 2.6.13.rc2-mm2 with few offsets, compiles also without warnings on GCC-2.95.3 and GCC-4.0.*, links without problem (no more memcpy()/memset() called).

It perfectly works for me, and even after reading those tens of times I no more find anything to change or improve.

Can someone propose a way forward, either in the direction of linux-2.6.14/15 or in the -mm tree, and/or propose improvement or point me to my bug(s) ?

Attached first patch just add two standalone executable, one to manage GZIP comments, the other to display a text line of the parameters used to compile the kernel.

The problem is that you call the assembly version "maintained". When I started hacking that part, in 1998, I tried to rewrite it cleanly and fix obvious bugs - but assembler is not the right tool for this job and touching those assembler files would break some configuration - even if some other configuration would work better.

I am not alone to not want to touch those assembler files: If you have a look at Linux/arch/x86_64/boot/video.S you will see that on an X86_64 architecture, people are doing I/O port and PCI peek/poke all over the place to detect video cards which have only been available on ISA bus, two bus generation ago! I seriously doubt you can even imagine an AMD 64 bits with an ISA trident 8900 video card inside, even for fun: you cannot plug it in.

The problem of assembler is that when it has been put in, you cannot remove anything because at the time you want to remove old stuff, you no more understand the implications. You can not, like in C, stop calling a function and hope everything will be right. With my code, when you will want to get rid of the APM stuff, you just remove the function call vmlinuz_APM() and recompile.

I am, with this set of patch, proposing a new way to boot. This way enable you to boot unlimited size kernel ("make allyesconfig" produces a bootable linux.kgz kernel) and the BIOS information collection is done in C while in real mode. This real mode function can be a lot bigger than it is currently, so that you can temporarily call some printf() equivalent while collecting data - instead of trying to get a clue of what has happen *after* the crash.

There is no extended time spent in protected mode (unlike Grub) before collecting BIOS information, so that the BIOS environment has not been broken (for instance older BIOS APM power saving system would be active at startup on some PC, setting timer interrupt to slowly reduce power consumption in real mode. Grub switching to protected mode stop serving those interrupts, and may not work on this PC, or the BIOS information may be invalid).

Tricky question. In short no, it cannot.

It is in fact theoretically possible to boot the same way for LILO, Grub and SYSLINUX to still work, and then call this linux_set_params() function but involves a lot of assembler programming and linker setup. I have done this exact work once with Gujin, but then I was in full control of the bootloader, in a setup which was already in C, has the stack setup, where I can free the first 4 Kbytes of data (located at address 0) for use by this kernel function. It was far to be simple.

One of the problem I can see is that you currently have two link being done by the linker, one in real mode and one in protected mode. You cannot have cross references in between those two links, and for instance with Gujin, you are filling the content of the LnxParam pointer, which is transparently copied at its right position before jumping to the Linux kernel code. You will need a seriously more complex linker file to forbid cross references, and duplicate Gujin treatment about memory setup (in this case that may involve HIMEM/EMM primitive calling if starting under DOS).

Note that if this kernel function returns an error, Gujin will display an error message and you can select another kernel to boot, but you cannot return to LILO or Grub with an error...

Modifying the bootloader may be possible, but lately I had another look at LILO source and I do not want to touch it. If you run Grub, you loose the "BIOS information gathering before switching to protected mode" advantage, BIOS environment may still be broken. SYSLINUX is probably at lot more accessible, and Gujin still do not support network booting (It can be added, but my TODO list is long), but you will want to call a function which is curently at the end of a still compressed image.

Sorry I cannot be compatible with them, please note that Gujin is also GPL.

It is even worse than that, I not only said to change the bootloader but also to remove one of the two links produced during a standard "make bzImage", the one which handle the real mode ia32 code, in Linux/arch/i386/boot/*.

Sometimes, to simplify, you need to remove things. As I said, a Linux kernel "linux.kgz" is just a compressed binary image of an ELF file - it no more deals with real mode, its first instruction is in protected mode (no virtual memory, just flat one, and interrupts disabled). It still contains the processor it is compiled for in the GZIP comment part, in text mode.

That has advantages like that you use a clean real mode environment to get all the BIOS information you want, the first kernel assembler instruction can be located anywhere in memory (even at an address currently used by BIOS/DOS because the relocation is very late), and there is no more any limit to the kernel size.

So, at the bootloader time, you can start a FreeDOS environment with DOS USB drivers and load your kernel at any address you want, or decide that you do not want to touch the BIOS environment and boot from a simulated floppy on a ATAPI IDE CDROM. If your kernel no more boots (got a HD with SMART failure lately), you can get an error while loading the kernel and just can boot a CDROM with a IDE disk RMA generator. When network support will be included in Gujin, because the processor is still in real mode, it will be able to use the network BIOS with its IRQ in a transparent way.

Note that there is no more any development for LILO or the real mode part of the kernel, probably people no more want to deal with assembler software. I can't blame them, I stopped too to use assembler in Gujin. I can't talk to the development teams of LILO or the real mode part of the kernel...

Anyway, it is technically not possible to rely on the old real mode interface because things are not done at the right time, complete backward compatibility is kept because you just describe what you want at the "make" time, by typing "make bzImage" or "make /boot/linux-2.13.kgz".

I can't force anybody to switch to Gujin; I am just proposing a way to start Linux which is a lot simpler, involves a lot less assembler code so is a lot easier to maintain, which is working right now, which is quite easy to debug (with the DBG*.exe files). You can boot your PC with your USB FLASH disk, your CD/DVD-ROM or a simple disk / partition / floppy right now, there isn't any configuration file because everything is autodetected - at least anything which cannot be selected by the graphic/mouse interface. http://gujin.org

There is now a wiki for Linux networking related activities and documentation.

http://linux-net.osdl.org

This is an experiment to see if it would be more useful to have an online and editable documentation source rather than bits and pieces.

Also, it should interact well with Wikipedia, since we can link to have the generic descriptions of things like protocols (TCP, bridging, bonding, VLAN's,...) and the Linux implementation.

I filled in my stuff, and Acme and Ian have been adding DCCP and the TODO list.

This is the start of the stable review cycle for the 2.6.13.4 release. There are 7 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email stable@kernel.org to add your name to the list. If you want to be off the reviewer list, also email us.

Responses should be made by Sunday, October 9, 24:00:00 UTC. Anything received after that time, might be too late.

• From: Stefan Richter <stefanr@s5r6.in-berlin.de>

  Fixes for reference counting problems, deadlocks, and delays when SBP-2 devices are unplugged or unbound from sbp2, or when unloading of sbp2/ ohci1394/ pcilynx is attempted.

  Most often reported symptoms were hotplugs remaining undetected once a FireWire disk was unplugged since the knodemgrd kernel thread went to uninterruptible sleep, and "modprobe -r sbp2" being unable to complete because still being in use.

  Patch is equivalent to commit abd559b1052e28d8b9c28aabde241f18fa89090b in 2.6.14-rc3 plus a fix which is necessary together with 2.6.13's scsi core API (linux1394.org commit r1308 by Ben Collins).

  Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
  Cc: Ben Collins <bcollins@debian.org>
  Signed-off-by: Chris Wright <chrisw@osdl.org>
  Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

• From: Pavel Roskin <proski@gnu.org>

  The orinoco driver can send uninitialized data exposing random pieces of the system memory. This happens because data is not padded with zeroes when its length needs to be increased.

  Reported by Meder Kydyraliev <meder@o0o.nu>

  Signed-off-by: Pavel Roskin <proski@gnu.org>
  Signed-off-by: Chris Wright <chrisw@osdl.org>
  Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

• From: Stephen Hemminger <shemminger@osdl.org>

  Please consider this change for 2.6.13-stable Since BIC is the default congestion control algorithm, this fix is quite important.

  Missing parenthesis in causes BIC to be slow in increasing congestion window.

  Spotted by Injong Rhee.

  Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
  Signed-off-by: David S. Miller <davem@davemloft.net>
  Signed-off-by: Chris Wright <chrisw@osdl.org>
  Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

• From: Dave Jones <davej@redhat.com>

  Please consider for next 2.6.13, it is a minor security issue allowing users to turn on drm debugging when they shouldn't...

  This fell through the cracks. Until Josh pointed me at http://bugs.gentoo.org/show_bug.cgi?id=107893

  Signed-off-by: Chris Wright <chrisw@osdl.org>
  Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

• From: "David S. Miller" <davem@davemloft.net>

  We need to use stricter memory barriers around the block load and store instructions we use to save and restore the FPU register file.

  Signed-off-by: David S. Miller <davem@davemloft.net>
  Signed-off-by: Chris Wright <chrisw@osdl.org>
  Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

• From: Linus Torvalds <torvalds@osdl.org>

  Avoid 'names_cache' memory leak with CONFIG_AUDITSYSCALL

  The nameidata "last.name" is always allocated with "__getname()", and should always be free'd with "__putname()".

  Using "putname()" without the underscores will leak memory, because the allocation will have been hidden from the AUDITSYSCALL code.

  Arguably the real bug is that the AUDITSYSCALL code is really broken, but in the meantime this fixes the problem people see.

  Reported by Robert Derr, patch by Rick Lindsley.

  Acked-by: Al Viro <viro@ftp.linux.org.uk>
  Signed-off-by: Linus Torvalds <torvalds@osdl.org>
  Signed-off-by: Chris Wright <chrisw@osdl.org>
  Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

• From: David Howells <dhowells@redhat.com>

  Plug request_key_auth memleak. This can be triggered by unprivileged users, so is local DoS.

  Signed-off-by: Chris Wright <chrisw@osdl.org>
  Signed-Off-By: David Howells <dhowells@redhat.com>
  Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

based on the touchkit USB and livebook PS/2 touchscreen driver, I made a driver for the touchkit PS/2 version. The work is based upon kernel 2.6.13.2 .

The egalax touchsreen controller (PS/2 or USB version) is used in this 7" device: http://www.cartft.com/catalog/il/449

Currently I'm using the PS/2 version in a DirectFB enviroment.
http://www.directfb.org/
http://mail.directfb.org/pipermail/directfb-dev/2005-September/000705.html
http://mail.directfb.org/pipermail/directfb-dev/2005-September/000706.html

Could you please have a look at it and tell my your comments on what would be additional required to get it included into kernel tree.

We (the -stable team) are announcing the release of the 2.6.13.3 kernel.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between 2.6.13.3 and 2.6.13.4, as it is small enough to do so.

The updated 2.6.13.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.13.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/

Here's the final -rc before a 2.6.14 release.

In the diffstat, most of the changes are one-liners, with the main exceptions being some sparc64 work (fix user-space corruption due to FP save/restore) and the new Megaraid SAS driver. There's some networking fixes, and a couple of driver updates (scsi: aacraid, net: cassini, and watchdog: pcwd_pci).

Along with a x86-64 suspend/resume page table corruption and some new defconfig files for ARM, that rounds out the bigger chunks.