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

Kernel Traffic #332 For 17 Oct 2005

By Zack Brown

In general, if you act like I've got all the attention span of a slightly retarded golden retriever, you'll be pretty close to the mark.

--Linus Torvalds

Table Of Contents

Mailing List Stats For This Week

We looked at 1437 posts in 9MB. See the Full Statistics.

There were 536 different contributors. 201 posted more than once. The average length of each message was 118 lines.

The top posters of the week were: The top subjects of the week were:
63 posts in 272KB by luke kenneth casson leighton
45 posts in 184KB by ingo molnar
41 posts in 166KB by steven rostedt
33 posts in 189KB by mark knecht
33 posts in 154KB by al viro
234 posts in 1020KB for "what's next for the linux kernel?"
75 posts in 355KB for "2.6.14-rc3-rt2"
39 posts in 173KB for "[rfc] atomic create+open"
26 posts in 123KB for "latency data - 2.6.14-rc3-rt13"
26 posts in 159KB for "[keyrings] [patch] keys: add lsm hooks for key management"

These stats generated by mboxstats version 2.8

1. Security Module Hooks For Key Management

5 Oct 2005 - 7 Oct 2005 (28 posts) Archive Link: "[PATCH] Keys: Add LSM hooks for key management"

People: David HowellsJames Morris

David Howells said:

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.

James Morris liked the patch so much, he asked why bother making it configurable. David had no objection, and said he'd just made it configurable because other stuff was. He was willing to take that part out.

Elsewhere, James said:

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.

2. An Attempt To Clean Up The Boot Code

6 Oct 2005 - 11 Oct 2005 (13 posts) Archive Link: "[PATCH 1/3] Gujin linux.kgz boot format"

Topics: Assembly, Backward Compatibility, Disks: IDE, Executable File Format, PCI, USB, Virtual Memory

People: Etienne LorrainPavel Machek

Etienne Lorrain said:

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.

Pavel Machek did not see the win, and pointed out that "Having to maintain both C and assembly version does not seem like improvement to me." Etienne replied:

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).

Pavel saw some merit in Etienne's plan, and asked, "Will your C version work with lilo and grub?" Etienne replied:

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.

Pavel replied, "I do not see a point, then. We have bad assembly bootup code. Adding good C bootup code, that is incompatible with lilo/grub does nothing to clean the mess up." Kalin Kozhuharov agreed that this would be a hard sell, and Etienne replied:

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

The discussion ended there.

3. New Linux Networking Wiki

6 Oct 2005 - 7 Oct 2005 (6 posts) Archive Link: "[ANNOUNCE] linux-net wiki"

Topics: Networking

People: Stephen HemmingerGreg KH

Stephen Hemminger said:

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.

Greg KH suggested, "Why not just work with the existing kernelnewbies wiki: http://wiki.kernelnewbies.org instead of creating another site?" Stephen replied, "Mainly because I started it out for my own linux networking projects, then generalized it. If you look on kernelnewbies you will see that there was already an MM wiki."

4. Review Cycle Leading To 2.6.13.4

7 Oct 2005 - 8 Oct 2005 (23 posts) Archive Link: "[patch 0/7] -stable review"

Topics: Hot-Plugging, Security

People: Greg KHStephen HemmingerDavid S. MillerRick LindsleyDavid HowellsStefan RichterLinus TorvaldsChris WrightDave JonesBen Collins

Greg KH said:

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 [email protected] 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.

There was no significant discussion. Just a stray character in one of the patches, doing no harm; and an odd subject line on another.

5. Touchkit PS/2 Based On Existing Touchscreen Drivers

9 Oct 2005 - 10 Oct 2005 (2 posts) Archive Link: "touchkit PS/2 touchscreen driver"

Topics: Touchscreen, USB

People: Stefan LuckeAndrey Panin

Stefan Lucke said:

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.

Andrey Panin liked what he saw, but had a few technical suggestions. There was no discussion.

6. Linux 2.6.13.4 Released

10 Oct 2005 (2 posts) Archive Link: "Linux 2.6.13.4"

People: Greg KH

Greg KH said:

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/

7. Linux 2.6.14-rc4 Released

10 Oct 2005 - 12 Oct 2005 (17 posts) Archive Link: "Linux v2.6.14-rc4"

Topics: Kernel Release Announcement

People: Linus Torvalds

Linus Torvalds announced Linux 2.6.14-rc4, saying:

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.

 

 

 

 

 

 

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.