Kernel Traffic #332 by Zack Brown
[email protected] Sun, 16 Oct 2005 23:35:34 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #332 For 17 Oct
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
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 5 Oct - 7 Oct (28 Security Module Hooks For Key Management
posts)
2. 6 Oct - 11 Oct (13 An Attempt To Clean Up The Boot Code
posts)
3. 6 Oct - 7 Oct (6 posts) New Linux Networking Wiki
4. 7 Oct - 8 Oct (23 Review Cycle Leading To 2.6.13.4
posts)
5. 9 Oct - 10 Oct (2 posts) Touchkit PS/2 Based On Existing Touchscreen
Drivers
6. 10 Oct (2 posts) Linux 2.6.13.4 Released
7. 10 Oct - 12 Oct (17 Linux 2.6.14-rc4 Released
posts)
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 | The top subjects of the week were: |
| were: | |
|-----------------------------+-----------------------------------------------|
|63 posts in 272KB by luke |234 posts in 1020KB for "what's next for the |
|kenneth casson leighton |linux kernel?" |
|45 posts in 184KB by ingo |75 posts in 355KB for "2.6.14-rc3-rt2" |
|molnar |39 posts in 173KB for "[rfc] atomic create+open|
|41 posts in 166KB by steven |" |
|rostedt |26 posts in 123KB for "latency data - |
|33 posts in 189KB by mark |2.6.14-rc3-rt13" |
|knecht |26 posts in 159KB for "[keyrings] [patch] keys:|
|33 posts in 154KB by al viro |add lsm hooks for key management" |
+-----------------------------------------------------------------------------+
These stats generated by mboxstats version 2.8
1. Security Module Hooks For Key Management
5 Oct - 7 Oct (28 posts) Archive Link: "[PATCH] Keys: Add LSM hooks for key
management"
People: David Howells, James 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 - 11 Oct (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 Lorrain, Pavel 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 - 7 Oct (6 posts) Archive Link: "[ANNOUNCE] linux-net wiki"
Topics: Networking
People: Stephen Hemminger, Greg 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 - 8 Oct (23 posts) Archive Link: "[patch 0/7] -stable review"
Topics: Hot-Plugging, Security
People: Greg KH, Stephen Hemminger, David S. Miller, Rick Lindsley, David
Howells, Stefan Richter, Linus Torvalds, Chris Wright, Dave Jones, Ben 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.
* From: Stefan Richter <[email protected]>
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 <[email protected]>
Cc: Ben Collins <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
* From: Pavel Roskin <[email protected]>
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 <[email protected]>
Signed-off-by: Pavel Roskin <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
* From: Stephen Hemminger <[email protected]>
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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
* From: Dave Jones <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
* From: "David S. Miller" <[email protected]>
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 <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
* From: Linus Torvalds <[email protected]>
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 <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
* From: David Howells <[email protected]>
Plug request_key_auth memleak. This can be triggered by unprivileged users,
so is local DoS.
Signed-off-by: Chris Wright <[email protected]>
Signed-Off-By: David Howells <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
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 - 10 Oct (2 posts) Archive Link: "touchkit PS/2 touchscreen driver"
Topics: Touchscreen, USB
People: Stefan Lucke, Andrey 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 (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/ (http://www.kernel.org/git/)
7. Linux 2.6.14-rc4 Released
10 Oct - 12 Oct (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.