Kernel Traffic #265 by Zack Brown
[email protected] Wed, 30 Jun 2004 13:05:50 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #265 For 30 Jun
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 30 May - 3 Jun (33 Some Explanation Of Disk Geometry Handling In
posts) 2.4 And 2.6
2. 1 Jun - 6 Jun (69 Linux 2.6.7-rc2-mm1 Released; Linux 2.7 May
posts) Require GCC Version Greater Than 2.x
3. 1 Jun - 4 Jun (2 Status Of SysFS Maintainership
posts)
4. 2 Jun - 8 Jun (66 'NX' Security Features Coming To 2.6
posts)
5. 2 Jun - 4 Jun (4 exec-shield Patch Updated For 2.6.7-rc2-bk2
posts)
6. 2 Jun - 6 Jun (9 Linux 2.4.27-pre5 Released
posts)
7. 3 Jun (1 Linux Test Project Updated
post)
8. 4 Jun (2 Some Developer Disconnect Over ia64
posts) Maintainership
9. 4 Jun - 5 Jun (6 SMBIOS Driver Removed From 2.6 Kernel; Some
posts) Developers Want It Back In
10. 4 Jun - 6 Jun (6 Improving Mousedev Button-Handling
posts)
11. 5 Jun (1 uClinux Cross-Compiler Toolchain Updated
post)
12. 6 Jun - 9 Jun (5 Supporting SCO Binaries Under Linux
posts)
13. 7 Jun - 8 Jun (10 Linux 2.6.7-rc3 Released
posts)
14. 7 Jun - 8 Jun (3 udev 026 Released
posts)
15. 8 Jun (1 bridge-utils Version 1.0.4 Released
post)
16. 9 Jun (1 linux-libc-headers Version 2.6.6.0 Released
post)
17. 9 Jun (2 Linus Moving To Portland, Oregon
posts)
Mailing List Stats For This Week
We looked at 2035 posts in 10603K.
There were 497 different contributors. 245 posted more than once. 248 posted
last week too.
The top posters of the week were:
* 70 posts in 469K by Vojtech Pavlik
* 64 posts in 320K by Andrew Morton
* 63 posts in 361K by Paul Jackson
* 52 posts in 244K by William Lee Irwin III
* 45 posts in 160K by Greg KH
* Full Stats
1. Some Explanation Of Disk Geometry Handling In 2.4 And 2.6
30 May - 3 Jun (33 posts) Archive Link: "2.6.x partition breakage and dual
booting"
Topics: Disk Arrays: RAID, Disks: IDE, Disks: SCSI, FS: FAT, Ioctls
People: Jeff Garzik, Andries Brouwer
Jeff Garzik said:
So it seems that the 2.6.x geometry code breaks dual booting, since Windows
wants "sane" CHS values. See the thread on slashdot, or http://
www.redhat.com/archives/fedora-devel-list/2004-May/msg00908.html
Although Fedora Core is current taking grief for this, it's really a 2.6.x
kernel problem AFAICT.
Has anybody taken the time to hunt down the csets that cause this massive
partition table breakage? If so, it will save me some time tracking this
down.
Andries Brouwer said that the slashdot thread related only to a user-space
problem, and that the fdisk program maintained by Andries worked perfectly. He
said, "I can tell you in great detail all about disk geometry, and the 2.4
situation and the 2.6 situation." Jeff asked for this great detail, and Andries
replied:
I already wrote several many-page texts on this stuff. See, e.g., http://
www.win.tue.nl/~aeb/linux/Large-Disk.html
Attempt at a brief summary:
1. Hardware:
In the ancient past a disk (MFM or RLL) had a geometry describing how
many sectors per track, how many tracks (cylinders), and how many heads
the thing had.
With the advent of IDE it no longer was true that a disk has a
well-determined geometry: the ATA command INITIALIZE DRIVE PARAMETERS
will tell the disk what geometry it is supposed to have today.
An IDE disk can be accessed in CHS and in LBA mode, and the geometry
specified, or read via the ATA IDENTIFY command, defines the meaning of
a CHS command. With LBA access no geometry plays a role.
SCSI disks never had this geometry nonsense.
Linux uses LBA and does not need to concern itself with geometry.
2. DOS / Windows:
The DOS disk interface used CHS. If the disk uses LBA the driver has to
convert CHS to LBA and hence needs a geometry (at least H, S).
Because DOS (BIOS INT 13) had 10 bits for C, and 6- bits for S, while
ATA uses 4 bits for H, this scheme could address only somewhat less
than 2^20 sectors. The 528 MB limit.
All kinds of translation schemes were invented to give the BIOS
interface a geometry different from that used at the ATA interface. The
user chooses a translation scheme in the BIOS setup. The geometry is
now unrelated to the disk, but is known to the BIOS.
Various BIOS calls exist that report on various versions of the
geometry.
3. Partition tables:
A DOS-type partition table (see, e.g., http://www.win.tue.nl/~aeb/
partitions/partition_tables.html) gives the location of a partition in
two ways. One is the way used by Linux (the starting sector and length,
both given in 32 bits). The other, used by DOS, given CHS for the first
and for the last sector (both in 24 bits).
Even when nobody cares about geometry any longer, is it still necessary
to fill these CHS fields.
If the filesystem living in the partition is a FAT filesystem, then the
boot sector of the FAT filesystem again gives information on the size
of the partition.
4. Linux:
There is an ioctl HDIO_GETGEO that returns the geometry of a disk and
the starting sector (offset) of a partition. There is an ioctl
BLKGETSIZE that returns the size (in 512-byte sectors) of a block
device in 32 bits. There is an ioctl BLKGETSIZE64 that returns the size
(in bytes) of a block device in 64 bits.
Clearly, BLKGETSIZE is obsolescent - it should be replaced by
BLKGETSIZE64 everywhere. 2^41 B is 2 TB, and some RAIDs are larger.
The HDIO_GETGEO ioctl gives heads, sectors and cylinders - fields of 1,
1, 2 bytes. On the one hand that is reasonable - no interface exists
that can use more than 16 bits for the number of cylinders. On the
other hand there is still some broken software that computes the size
of a disk as C*H*S, and obtains C, H, S by HDIO_GETGEO. Of course this
is broken, and introducing a new ioctl is no good - such software must
be fixed to use BLKGETSIZE64.
5. Geometry use under Linux:
Roughly speaking geometry was needed under Linux for two purposes: LILO
(and similar bootloaders) and *fdisk. Of course, also programs that
tried to emulate aspects of DOS/Windows are interested in a geometry.
The LILO aspect has disappeared - with options like linear, or lba32,
lilo uses linear sector numbers at install time, and converts them to
CHS, when needed, at boot time.
The fdisk aspect has also disappeared - after this geometry business
had become infinitely complicated, nobody any longer tried to
understand geometry, but just inferred from the partition table what
geometry was used by the program that last wrote it.
How did the kernel find a geometry? Mainly in three ways: (i) from boot
parameters, (ii) by looking at the partition table, (iii) by asking the
BIOS at boot time, before switching to protected mode.
Information (i) - explicit specification - and (ii) - partition table -
is also available to user space, no kernel needed. Remains the question
whether (iii) is a good idea.
It didnt always work, but often it worked. (And only on i386 of
course.) Examples of failure: The code we had only asked the BIOS for
info on the first two disks. An often-posed question was: I have two
identical disks, how come they get different geometries? Also, the code
we had failed when the system had SCSI disks. Also, the code we had
assumed that the first two BIOS disks were hda and hdb. But there is no
reason why that would be the case. For example, many people kept their
large disks out of the BIOS since it would crash upon seeing big disks.
So, this (iii) was a bit messy stuff with many problems, but OK for
most people.
6. The present
Linux no longer makes any attempt to invent a geometry. If someone
needs a geometry, he is responsible himself for choosing one of the
many concepts of geometry, and determining a value. What most software
does is looking at the partition table, and that works.
Maybe parted has not yet been updated to do this, that is why I
conjectured that Fedora problems might be due to the use of parted.
Was this a loss? I don't think so, but there is at least one use of the
old situation that fails today: the installation of Windows systems
from Linux media on a completely blank disk.
2. Linux 2.6.7-rc2-mm1 Released; Linux 2.7 May Require GCC Version Greater Than
2.x
1 Jun - 6 Jun (69 posts) Archive Link: "2.6.7-rc2-mm1"
Topics: FS: NFS, Kernel Release Announcement, Networking, Profiling
People: Andrew Morton, Alexander Gran, David S. Miller, Linus Torvalds, Adrian
Bunk
Andrew Morton announced Linux 2.6.7-rc2-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7-rc2/
2.6.7-rc2-mm1/
+ NFS server udpates
+ md updates
+ big x86 dmi_scan.c cleanup
+ merged perfctr. No documentation though :(
+ cris architecture update
Alexander Gran remarked, "I can neither enter nor activate the gigabit ethernet
driver section in menuconfig." Andrew replied that he had no problem with that;
and David S. Miller said, "It seems you have to enable the 10/100 section in
order to get to the gigabit section. This is the case in the standard tree too,
nothing in -mm changed this." Alexander tried and confirmed this, saying, "Ahh,
all right. Than the bug was introduced with 2.6.7-rc2."
Elsewhere, Adrian Bunk reported seeing a lot of warnings about dereferencing
void pointers during compilation, when compiling with GCC 2.95; Linus Torvalds
replied:
Yes. Apparently gcc-2.95 doesn't like to dereference a "void *" even just
inside of a "__typeof__". Which is a bit silly, since the result is a
perfectly valid _type_. It's obviously been fixed since, so I never saw
this.
(Aside - with anon unions also not working in older gcc's, I suspect we'll
start requiring gcc-3+ in the 2.7.x timeframe. I know it's a lot slower,
but apparently at least it now is starting to generate comparable code
again).
Anyway, the easiest work-around would be to just avoid derefencing the
pointer, but then you have to add strange modifiers (both "const" and
"volatile" at the same time) to make sure that gcc won't complain about the
assignment dropping any modifiers.
So the fix I'm going to check in is to just make "__chk_user_ptr()" be
something that gcc never even sees, which allows us to simplify it for the
sparse case too.
In other words, this should work for even old versions of gcc.. Just to be
anal, you should probably test on gcc-2.95 ;)
Adrian tried Linus' fix and confirmed that it worked with GCC 2.95.
3. Status Of SysFS Maintainership
1 Jun - 4 Jun (2 posts) Archive Link: "Sysfs maintainer"
Topics: FS: sysfs, MAINTAINERS File
People: Greg KH
Christian Gmeiner was trying to contact the SysFS maintainer, but couldn't seem
to find any information on who that person might be; Greg KH replied, "I'm the
de-facto sysfs and driver core maintainer these days, I guess I should add that
to the MAINTAINERS file eventually..."
4. 'NX' Security Features Coming To 2.6
2 Jun - 8 Jun (66 posts) Archive Link: "[announce] [patch] NX (No eXecute)
support for x86, 2.6.7-rc2-bk2"
Topics: Executable File Format, Microsoft, Security, Spam, Virtual Memory
People: Ingo Molnar, Linus Torvalds, Doug McNaught, Jakub Jelinek, Brian Gerst
, Christoph Hellwig, William Lee Irwin III, Andi Kleen, Andy Lutomirski, Arjan
van de Ven, Gerhard Mack, Jun Nakajima, Rusty Russell
Ingo Molnar said on behalf of Red Hat:
we'd like to announce the availability of the following kernel patch:
http://redhat.com/~mingo/nx-patches/nx-2.6.7-rc2-bk2-AE
which makes use of the 'NX' x86 feature pioneered in AMD64 CPUs and for
which support has also been announced by Intel. (other x86 CPU vendors,
Transmeta and VIA announced support as well. Windows support for NX has
also been announced by Microsoft, for their next service pack.) The NX
feature is also being marketed as 'Enhanced Virus Protection'. This patch
makes sure Linux has full support for this hardware feature on x86 too.
What does this patch do? The pagetable format of current x86 CPUs does not
have an 'execute' bit. This means that even if an application maps a memory
area without PROT_EXEC, the CPU will still allow code to be executed in
this memory. This property is often abused by exploits when they manage to
inject hostile code into this memory, for example via a buffer overflow.
The NX feature changes this and adds a 'dont execute' bit to the PAE
pagetable format. But since the flag defaults to zero (for compatibility
reasons), all pages are executable by default and the kernel has to be
taught to make use of this bit.
If the NX feature is supported by the CPU then the patched kernel turns on
NX and it will enforce userspace executability constraints such as a
no-exec stack and no-exec mmap and data areas. This means less chance for
stack overflows and buffer-overflows to cause exploits.
furthermore, the patch also implements 'NX protection' for kernelspace
code: only the kernel code and modules are executable - so even
kernel-space overflows are harder (in some cases, impossible) to exploit.
Here is how kernel code that tries to execute off the stack is stopped:
kernel tried to access NX-protected page - exploit attempt? (uid: 500)
Unable to handle kernel paging request at virtual address f78d0f40
printing eip:
...
The patch is based on a prototype NX patch written for 2.4 by Intel -
special thanks go to Suresh Siddha and Jun Nakajima @ Intel. The existing
NX support in the 64-bit x86_64 kernels has been written by Andi Kleen and
this patch is modeled after his code.
Arjan van de Ven has also provided lots of feedback and he has integrated
the patch into the Fedora Core 2 kernel. Test rpms are available for
download at:
http://redhat.com/~arjanv/2.6/RPMS.kernel/
the kernel-2.6.6-1.411 rpms have the NX patch applied.
here's a quickstart to recompile the vanilla kernel from source with the NX
patch:
http://redhat.com/~mingo/nx-patches/QuickStart-NX.txt
There were a lot of technical suggestions and comments from folks like
Christoph Hellwig, Andi Kleen, Rusty Russell, and Gerhard Mack. Also, Linus
Torvalds asked:
Just out of interest - how many legacy apps are broken by this? I assume
it's a non-zero number, but wouldn't mind to be happily surprised.
And do we have some way of on a per-process basis say "avoid NX because
this old version of Oracle/flash/whatever-binary-thing doesn't run with
it"?
In answer to the first question, Ingo and Arjan van de Ven (also from Red Hat)
confirmed that the amount of legacy breakage was in fact zero. Ingo also
explained that just in case, any breakage from this would be less than other
breakage already introduced by Red Hat. He put it, "in the full install of FC1
and FC2 the number is zero - and Fedora has exec-shield which does a couple of
things more: it makes the heap non-executable as well [this broke X], it
randomizes the address-space layout and has a 4:4 VM [which broke the Sun
JVM]." Doug McNaught added, close by, "Lisp systems like CMUCL and SBCL (plus
commercial Lisps) had problems with FC1 due to execshield. They tend to do
things like compile code on the fly to heap memory and expect to be able to run
it." And Jakub Jelinek (also from Red Hat) replied, "They will still work, as
long as you don't recompile them with recent toolchain. When you recompile
them, they either needs to be taught to DTRT (i.e. use mmap with PROT_EXEC for
executable stuff), or can be linked with -Wl,-z,execstack to mark them as
needing executable stack. prelink package also contains execstack(8) utility
which can be used on already linked binaries/shared libraries."
To Linus' second question, about the possibility of per-process avoidance of NX
for compatibility reasons, Ingo explained:
we have three mechanisms for this in Fedora:
1. the PT_GNU_STACK flag itself - you can turn executability on/off
compile-time or even after the fact via the execstack(8) utility Jakub
wrote. This only affects the stack's executability - if an application
assumes a non-PROT_EXEC mmap() can be executed it might still break
with NX - but based on experience with Fedora Core i'd say there's
almost no such application.
this method works in 2.6 too, since it supports PT_GNU_STACK. gcc's
PT_GNU_STACK mechanism is very conservative - e.g. if an application
does an asm() then gcc assumes that it might rely on stack
executability and emits the X flag. [applications can then turn this
off in the source if stack executability is not required.] Likewise, if
gcc emits trampolines then the X flag is emitted too. (glibc knows
about PT_GNU_STACK all across - so e.g. if a nonexec stack application
dlopen()s a library that needs stack executability then glibc makes the
stack executable on the fly via PROT_GROWSDOWN/GROWSUP.)
2. via a runtime method: via the i386 personality. So an application can
trigger the 'legacy' Linux VM layout by e.g doing 'i386 java ./
test.class'.
this is a hack in Fedora - we wanted to have a finegrained runtime
mechanism just in case. But it would be nice to have this upstream too
- e.g. via a PERSONALITY_3G?
3. via a kernel boot parameter (exec-shield=0)
with the NX patch this becomes noexec=off [the same flag works on
x86_64 too]. This method is the most inflexible one, and is a
last-resort thing. (Fedora also has a runtime global switch to turn off
the VM layout changes.)
here's a list of applications that we had to fix/work around in Fedora when
the VM layout changed:
+ emacs _rebuild_. (it coredumps itself during build ... xemacs is OK.)
+ some JDKs. Since they generate code and try to be as fast as possible
they tend to rely more on VM details than normal applications.
+ X's module loader assumed that brk was executable. (fixed)
+ Wine. (it implements another OS so it's by definition very sensitive to
layout changes.)
most of the breakages were unclean x86-only code that would have broken if
ported over to 64-bit anyway.
old, legacy applications dont have the PT_GNU_STACK flag so they all work
fine.
Regarding Wine's breakage when the Virtual Memory Subsystem changed, Brian
Gerst disagreed with Ingo's explanation, and remarked, "Wine breaks because of
the part of exec-shield that relocates shared libs to low addresses, where the
(stripped) Windows binaries expect to be loaded at. NX stack doesn't affect
it." Ingo accepted this, adding, "I think Wine could get around this by
creating a dummy ELF section in the Wine binary that covers the first 1GB or
so. Wine could still use ordinary dynamic libraries - those would go above that
1GB. Then once Wine has loaded up it can munmap() that first 1GB. (this would
not work if Wine has to dlopen() new libraries after this phase - does that
happen?)" But Christoph Hellwig suggested, "Why can't wine just implement it's
own binfmt_pecoff? Sounds like the much simpler solutuion." And William Lee
Irwin III said, "I'd be in favor of this also. An executable format with wide
enough usage is worth adding kernel support for loading it."
Ingo replied also to his own long post, dealing with his item 2 above, the
runtime method of triggering the legacy Linux VM subsystem. He said:
i've attached a patch that provides a cleaner solution. It does 3 changes:
+ it adds a ADDR_SPACE_EXECUTABLE bit to the personality 'bug bits'
section. This bit if set will make the stack executable. (if in the
future we decide to make the malloc() heap non-exec [which i definitely
think we should], that property will also listen to this bit.)
+ in elf.h, it changes the x86 personality inheritance code to match that
of x86_64 - which is a much saner method. This means if a complex app
that does exec()s will all run with the personality of the parent(s).
+ in exec.c, since address-space executability is a security-relevant
item, we must clear the personality when we exec a setuid binary. I
believe this is also a (small) security robustness fix for current
64-bit architectures.
(the patch also adds a break to the elf_ex.e_phnum loop - there can only be
one STACK header in the binary and once we found it we should not iterate
through the remaining program headers (if any).)
we didnt want to add a non-standard personality flag to Fedora so we abused
PER_LINUX32 as the compatibility flag - but this only works on x86. With
the ADDR_SPACE_EXECUTABLE flag there would be a standard method to fall
back to 'legacy' executability assumptions Linux applications might make.
Andi replied to the third item in the list above, regarding clearing the
'personality' when executing a setuid binary. He said, "This means I cannot
easily force an i386 uname or 3GB address space on suid programs anymore on
x86-64. While in theory it could be a small security problem I think the
utility is much greater. It's hard to see how setting NX could cause a security
hole. The program may crash, but it is unlikely to be exploitable." Andy
Lutomirski replied:
The whole point of NX, though, is that it prevents certain classes of
exploits. If a setuid binary is vulnerable to one of these, then Ingo's
patch "fixes" it. Your approach breaks that.
I don't like Ingo's fix either, though. At least it should check CAP_PTRACE
or some such. A better fix would be for LSM to pass down a flag indicating
a change of security context. I'll throw that in to my caps/apply_creds
cleanup, in case that ever gets applied.
Andi thought it would be overkill to require an LSM module, but he agreed that
Andy had a good point, although Andi also objected, "that only applies to the
NX personality bit. For the uname emulation it is not an issue. So maybe the
dropping on exec should only zero a few selected personality bits, but not
all." This made sense to Andy; and close by, Ingo said, "ok, how about the
attached patch then? There's a PERS_DROP_ON_SUID mask that we drop upon setuid
- all the other personality bits get inherited." Andy replied, "This is wrong
on SELinux (and presumably with other LSMs). It also does unexpected things if
you fail to exec a setuid executable." He posted his own patch, and Linus
Torvalds came in with:
Let's not do this at all.
Anything that changes subtle behaviour at suid-execute time is just wrong.
Imagine an app that has been tested in normal use, and then has a subtle
bug when executed set-uid, simply because the address space layout changes.
Or something that mysteriously works when you're root, but not when you're
anything else. Ouch.
I think we should just look at the executable itself, not whether it is
suid. If the executable says it is "NX-approved", then it's NX-approved.
End of story - just try to make sure that as many executables as possible
get compiled with the newer compiler suite that enables it.
Add a tool to let people turn on/off the NX bit on an executable if it
turns out the executable can't work with it (let's say it was compiled and
tested on a CPU without NX support), and everybody should be happy. You can
have a trivial script that turns on the NX bit on all the legacy apps too,
and then if testing shows iot wasn't a good idea, you can turn it off again
on a per-executable basis.
Ingo did a bunch more work, posting patches; and Arjan also remarked, "the
prelink rpm on Fedora has such a tool" [to flip the NX bit on an executable]
"already fwiw. (it's part of prelink because the elf manipulations needed are
quite similar to the ones prelink does so infrastructure is shared)" Linus
replied:
Just for fun, can somebody that has the required hardware just test old
apps with NX turned on?
I know we used to put the signal handler trampoline on the stack, but these
days that should all be handled with the magic executable syscall page, so
_normally_ I don't think an old application should even really care.
In fact, it would be interesting to just hear somebody running an older
distribution with a new CPU and a new kernel, and see just how many
programs need to be marked non-NX in "normal running".
Arjan replied, "I know that in a FC1 full install there are less than 5
binaries that don't run with NX. (one uses nested functions in C and passes
function pointers to the inner function around which causes gcc to emit a stack
trampoline, and gcc then marks the binary as non-NX, the others have asm in
them that we didn't fix in time to be properly marked)." And Linus said:
If things are really that good, why are we even worrying about this?
It sounds like we should just have NX on by default even for executables
that don't have any NX info records, and have some way of marking the (very
few) executables that don't want it. Maybe have the NX fault print a
warning when it happens for an executable that defaulted to NX on.
I think most people have seen the security disaster that causes most of the
emails on the net to be spam. So this should be _trivial_ to explain to
people when they complain about default behaviour breaking their strange
legacy app. Especially if there's a trivial tool to add an elf section to
make it work again.
So instead of having complex things to try to turn NX on for suid, we
should aim to turn ot on as widely as possible, _even_if_ that means that
people who upgrade hardware might have to do some trivial MIS stuff.
Make a kernel bootup option to default to legacy mode if somebody literally
has trouble booting and fixing their thing due to "init" or similar being
one of the problematic cases. Together with a printk() that says which
executable triggered, it should be trivial to clean up a system.
5. exec-shield Patch Updated For 2.6.7-rc2-bk2
2 Jun - 4 Jun (4 posts) Archive Link: "[patch] exec-shield patch for
2.6.7-rc2-bk2, integrated with NX"
Topics: Big Memory Support
People: Ingo Molnar, Christoph Hellwig, Joe Korty
Ingo Molnar said:
Here's the latest exec-shield patch for 2.6.7-rc2-bk2, integrated with the
'NX' feature (see the announcement from earlier today):
http://redhat.com/~mingo/exec-shield/exec-shield-on-nx-2.6.7-rc2-bk2-A7
you first have to apply the NX patch, which can be found at:
http://redhat.com/~mingo/nx-patches/nx-2.6.7-rc2-bk2-AE
prebuild kernel RPMs for Fedora Core 2, with this latest version of
exec-shield, are available at:
http://redhat.com/~arjanv/2.6/RPMS.kernel/
(kernel-2.6.6-1.411 has this latest, NX-aware exec-shield.)
if the CPU supports NX (and the kernel has been compiled with
CONFIG_HIGHMEM64G) then exec-shield will use NX to provide page-level
finegrained control over execution. On legacy CPUs that dont support NX the
segment-limit method is used to control execution (in a coarser way). In
the NX case the segment-limit is turned off altogether.
e.g. on an Athlon64 box the boot message looks:
NX (Execute Disable) protection: active
on a CPU without NX the boot message is:
NX (Execute Disable) protection: not present!
Using x86 segment limits to approximate NX protection
note: the NX patch will also protect against kernel-space code injection.
all the other components of exec-shield are identical between NX and
non-NX: the brk area is non-executable, libraries and PIE binaries are
moved into the ascii-shield as much as possible, and all aspects of the
address space are randomized.
Christoph Hellwig thought the patch was too big and included more stuff than
some folks would want. He asked, "Any chance to split this up a bit? Having the
pure non-exec stack (and maybe heap) would be really nice while the
randomization feature are a litte bit too much security by obscurity for my
taste." Joe Korty disagreed, "It's no more security by obscurity than keeping
your key secret is security by obscurity. (One can think of the randomization
as a white-noise key)." Nevertheless, Ingo posted a new patch with the
randomization code removed. But he added, "but i still think randomization is
useful as a last-resort barrier, against worm-alike mass attacks. There's a
huge difference between a 1-packet infection and a 2-hour brute-force search
over broadband, in terms of the 'economy' of worms."
6. Linux 2.4.27-pre5 Released
2 Jun - 6 Jun (9 posts) Archive Link: "Linux 2.4.27-pre5"
People: Marcelo Tosatti
Marcelo Tosatti announced Linux 2.4.27-pre5, saying, "This time we have merges
from Jeff's -netdrivers tree, David's -net tree, including a fix for
compilation error without CONFIG_SCTP set, SPARC64 update, i810_audio fixes,
amongst others."
7. Linux Test Project Updated
3 Jun (1 post) Archive Link: "[ANNOUNCE] JUne LTP release now available"
People: Marty Ridgeway
Marty Ridgeway announced the Linux Test Project version 20040603, saying:
LTP-20040603
+ Minor corrections to the NUM_PROCS patch
+ Added the ability to pass NUM_PROCS to the -c option for runalltests.sh
+ Fix genload in runalltests.sh, it was trying to run it in all caps, but
the binary is all lower case. Should actually run genload now.
+ Patch from Alastair McKinstry to allow LTP to build on Linux/HPPA
+ Changes for parameters passed to aio-sparse for correct offsets and
restrictions on sizes.
+ Add new security tests to syscalls testsuite
+ In acl_file_test.c and acl_link_test.c syscalls regarding xattrs are
still done via syscall, although libc functions are available.
Furthermore I found out that on older distros for non-intel
architectures both attr/xattr.h and constants like __NR_getxattr are
not available, so in this case the these testcases are not built.
+ Updates for the DMPAI testsuite ppc64 support.
+ Fix failure on rwtest versions rwtest03 and rwtest04 due to mmap
running out of resources.
+ Made changes to get thread ID vs get PID for NPTL threads for unique
filenames where child/parent PIDs are the same.
+ Changes to diotest5 and diotest_routines to eliminate random/
intermitant failures on data compare.
+ Fixed memory leak in mmstress testcase.
+ Changed clone02 to use tid instead of pid to eliminate failures on NPTL
threads(same PIDs for parent/child)
+ Changed fcntl15 getpid to gettid (syscall(gettid)) to get unique thread
ID vs common PID in NPTL threads.
+ Added adp testcases.
8. Some Developer Disconnect Over ia64 Maintainership
4 Jun (2 posts) Archive Link: "[PATCH] ia64 MAINTAINERS update"
Topics: MAINTAINERS File, Version Control
People: Grant Grundler, Jesse Barnes
Jesse Barnes noticed that the ia64 web site and mailing list, as listed in the
MAINTAINERS file, no longer worked. He posted a patch to point to the
[email protected] mailing list instead, and to remove the URL
altogether. Grant Grundler replied:
The correct URL still is: http://www.ia64-linux.org/
Please update the URL.
grundler <512>host www.ia64-linux.org
www.ia64-linux.org has address 192.25.206.7
192.25.206.7 also hosted parisc-linux.org. But recently all the
parisc-linux services migrated to another box. I'm not sure when/why the
"old" box was disconnected or if it just crashed.
In any case, despite being at gcc-summit conf, willy did find time to
migrate ia64-linux.org to the same host as parisc-linux.org. IIRC, that was
yesterday. The DNS just hasn't propagated yet but ISTR willy said it would
today at some point.
The entire ia64-linux web site is available via anon CVS. See
cvs.parisc-linux.org but use "ia64-web" instead as the repository.
I've checked out a snapshot anyone can access for now on http://
iou.parisc-linux.org/ia64-web/
9. SMBIOS Driver Removed From 2.6 Kernel; Some Developers Want It Back In
4 Jun - 5 Jun (6 posts) Archive Link: "EFI-support for SMBIOS driver"
Topics: Version Control
People: David Mosberger, Michael Brown, Greg KH, Bartlomiej Zolnierkiewicz
David Mosberger said:
The patch below adds EFI support to the SMBIOS driver. Since EFI already
knows the address of the SMBIOS, this avoids having to scan for the table.
It also enables use of the driver on ia64 machines. The patch also adds
code to handle the case where the SMBIOS table resides in memory, which is
the case at least for HP's zx1-based ia64 machines. If CONFIG_EFI is off,
the resulting code should be unchanged (except for replacing a readb() loop
into a memcpy_fromio()).
One observation: I believe find_table_max_address() is missing some readb()
calls (it's dereferencing ioremap'pped addresses directly). I didn't try to
fix that since I wasn't sure why it wasn't done in the first place.
Bartlomiej Zolnierkiewicz pointed out that according to a BitKeeper patch (
http://linus.bkbits.net:8080/linux-2.5/cset@40b6702axansvQIxOVjTSIp7_DVoHA) ,
the SMBIOS driver was no longer in the tree. David replied:
Man, talk about going in circles!
If folks are serious about discouraging /dev/mem, then the SMBIOS driver
makes tons of sense.
Close by, Greg KH pointed out that the driver was removed because everything it
did could be done from userspace. David said, "I know full well that it can be
done in user-level --- via /dev/mem, which lots of people dislike. I certainly
don't feel strongly about it, but the SMBIOS driver made sense to me." At this
point, Michael Brown offered:
I was the original submitter. Somebody kindly pointed out to me (offline)
the error of my ways, and I was able to get my userspace lib to work just
fine using mmap() instead of read(). This takes care of two out of three of
the main reasons I orignally submitted this driver.
Since my library was the only user of this lib, and I no longer need it, I
asked several people if it would make sense to continue to support it or to
pull it. The consensus was not to "bloat" the kernel with extra stuff if it
can be done via /dev/mem.
If there are strong sentiments the other way, the code is still out there
if somebody else wants to take over. I looked at what it would take to add
EFI support for this, and it would be trivial. I just didn't want to become
yet another absentee-maintainer if I no longer need the code.
10. Improving Mousedev Button-Handling
4 Jun - 6 Jun (6 posts) Archive Link: "[PATCH 2.6] Mousedev - better button
handling under load"
People: Dmitry Torokhov, Vojtech Pavlik
Dmitry Torokhov said:
Currently mousedev combines all hardware motion data that arrivers since
last time userspace read data into one cooked PS/2 packet. The problem is
that under heavy or even moderate load, when userspace can't read data
quickly enough, we start loosing valuable data which manifests in:
+ ignoring buton presses as by the time userspace gets to read the data
button has already been released;
+ click starts in wrong place - by the time userspace got aroungd and
read the packet mouse moved half way across the screen.
The patch below corrects the issue - it will start accumulating new packet
every time userspace is behind and button set changes. Size of the buffer
is 16 packets, i.e. up to 8 pairs of press/release events which should be
more than enough.
The patch is against Vojtech's tree and shuld apply to -mm. I also have
cumulative mousedev patch done against 2.6.7-pre2 at:
http://www.geocities.com/dt_or/input/misc/
mousedev-2.6.7-rc2-cumulative.patch.gz
Vojtech Pavlik was happy to see this.
11. uClinux Cross-Compiler Toolchain Updated
5 Jun (1 post) Archive Link: "[ANNOUNCE] GCC 3.4 ColdFire/ARM toolchain for
uClinux (20040604)"
Topics: Backward Compatibility, FS: ROMFS
People: Bernardo Innocenti
Bernardo Innocenti said:
a new version of the uClinux cross-compiler toolchain based on GCC 3.4 is
available here:
http://www.uclinux.org/pub/uClinux/uclinux-elf-tools/gcc-3/
This release adds preliminary ARM support and includes binaries for Linux
(both glibc23 and glibc22 distros) and Cygwin.
Many other things have been changed since the last public announcement:
Changes in release 20040605:
+ Preliminary GCC 3.5 support.
+ Add some GCC 3.4 patches by Peter Barada.
+ Add support for GDB 6.1.
+ Update m68k-bdm to 1.3.0 and use GDB patches distributed with it.
+ Integrate preliminary ARM support. (Contributed by Steve Miller
<[email protected]>).
+ Fix genromfs patch for CygWin. (Reported by Jens Heilig
<[email protected]>).
Changes in release 20040425:
+ Update GCC 3.4 to the official 3.4.0 release.
+ Update m68k-bdm to 1.2.0.
Changes in release 20040323:
+ Update GCC 3.4 to the 20040317 snapshot.
+ Update binutils to 2.15.90.0.1.1, which already contains all the
required uClinux patches.
+ Backport argument pointer corruption fix to GCC 3.3.3
Changes in release 20040309:
+ Drop Insight support (DDD is better anyway) and install GDB in $PREFIX.
+ Rename "interrupt" attribute to "interrupt_handler" in 3.3.x patches to
match GCC 3.4.
Changes in release 20040112:
+ Update GCC 3.4 to 3.4-20040114.
+ Update uClibc to 0.9.26.
+ Update binutils to 2.14.90.0.8 (and drop some integrated patches).
+ Cleanup support for backwards compatibility links to m68k-elf- tools.
+ Correctly detect GCC version for interim releases.
+ Apply a couple of rogue patches to GCC 3.4.
+ Fix build with gcc-java, but don't expect it to work right now.
Changes in release 20031230:
+ Switch to m68k-uclinux for all components of the GCC 3.4 toolchain.
+ GCC's compiler driver now adds required linker flags when building
executables with -mid-shared-libary.
+ Update uClibc to 0.9.24.
+ Update m68k-bdm to 20031207 and import latest GDB patches.
+ Update GCC 3.4 to 3.4-20031222.
+ Update GCC 3.3.x to 3.3-20031222.
+ Merge-in patches by Andrea Tarani for uClibc 0.9.23 and m68k-bdm.
12. Supporting SCO Binaries Under Linux
6 Jun - 9 Jun (5 posts) Archive Link: "linux-abi dead?"
Topics: Executable File Format, IBCS, Version Control
People: Steve Bergman, Mike Jagdis, Eric Youngdale
Steve Bergman wanted to run an old SCO binary, and noticed that the
linux-abi.sf.net (http://linux-abi.sf.net) project seemed dead. He asked if
there were any other projects working on running foreign binaries under Linux.
Later he said, "It seems that there is a patch, released just today (and just
for me, I guess?) at: http://sourceforge.net/tracker/index.php?func=detail&aid=
968070&group_id=13130&atid=313130" Elsewhere, Mike Jagdis commented:
iBCS ceased when I decided that "enough" vendors were targetting Linux as a
Tier-1 platform and what was left was legacy proprietry stuff that either
worked or would be painful to fix. iBCS then became linux-abi which ported
to newer kernels and added UnixWare support. I guess there just isn't
enough SYSV stuff left to keep any momentum behind linux-abi anymore
either...
SCO stated a long time ago that they saw nothing in linux-abi to worry
them.
Which is kind of interesting because iBCS started life pretty much as a way
for Eric Youngdale to test his ELF loader code, which subsequently moved
into the main kernel.
(iBCS CVS is still available on http://sf.net/projects/ibcs even if nothing
else is. It doesn't go back quite to the start - I think my initial import
was 1993...)
13. Linux 2.6.7-rc3 Released
7 Jun - 8 Jun (10 posts) Archive Link: "Linux 2.6.7-rc3"
Topics: Kernel Release Announcement
People: Linus Torvalds
Linus Torvalds announced Linux 2.6.7-rc2, saying:
Ok, let's calm down for a while before the final 2.6.7.
-rc3 does a lot of sparse type cleanup, mainly thanks to Al Viro (but his
work ended up getting some other people involved too, since the list of
sparse warnings isn't as daunting any more). Some of that has unearthed
real bugs which Al fixed.
But there are DRM, AGP, cpufreq, sparc64, and input updates there too.
14. udev 026 Released
7 Jun - 8 Jun (3 posts) Archive Link: "[ANNOUNCE] udev 026 release"
Topics: FS: devfs, FS: sysfs, Hot-Plugging, Version Control
People: Greg KH
Greg KH announced:
I've released the 026 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-026.tar.gz (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-026.tar.gz)
(yes, there was a 025 release, I just forgot to announce it, full changelog
is below)
udev allows users to have a dynamic /dev and provides the ability to have
persistent device names. It uses sysfs and /sbin/hotplug and runs entirely
in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run.
Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ (http://www.kernel.org/
pub/linux/utils/kernel/hotplug/udev-FAQ)
For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs
Major changes since 024:
+ lots of minor bugfixes
+ added udev_volume_id from Kay Sievers which is an excellent way to read
block volume ids to create udev rules.
+ deleted the dbus and selinux programs as they were not the way to
integrate udev with those packages. DBUS integration with udev is now
handled by the HAL project using the /etc/dev.d/ notifiers.
+ update documentation. Thanks to Daniel Drake for this.
Thanks to everyone who has send me patches for this release, a full list of
everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
15. bridge-utils Version 1.0.4 Released
8 Jun (1 post) Archive Link: "[ANNOUNCE] bridge-utils-1.0.4"
Topics: FS: sysfs
People: Stephen Hemminger
Stephen Hemminger said:
Released a new version of bridge utilities that supports both new 2.6.7
interface and older 2.6/2.4 releases. The only changes since 1.0 were
internal to fix compatibility issues.
The tarball can be downloaded from:
http://prdownloads.sourceforge.net/bridge
Getting full functionality requires a build system with:
+ libsysfs from the sysfsutils package
http://linux-diag.sourceforge.net/Sysfsutils.html
+ kernel (and headers) from 2.6.7-rc1 or later
Note: libsysfs has not been fully integrated by the main linux vendors. So
producing a full functional package is not possible with the default spec
file.
The utilities will build (and run) on earlier systems it will just default
to the old interface and which doesn't have 32/64 bit compatibility.
16. linux-libc-headers Version 2.6.6.0 Released
9 Jun (1 post) Archive Link: "[ANNOUNCE] linux-libc-headers 2.6.6.0"
People: Mariusz Mazur
Mariusz Mazur announce linux-libc-headers Version 2.6.6.0, saying:
Available at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
Changes:
+ updated to 2.6.6 kernel
+ readded allmost all of the sound/* headers; some of those contain
driver specific definitions that might be used in userland apps to
control various hardware features
+ added scsi headers - more on that below
+ fixed macros in byteorder/swab.h - now hdparm on big endian machines
really builds
+ other fixes (eg. frottle should build)
+ I've made linux/audit.h parse out of the box; if I understand correctly
this is supposed to be a "kernel talks to userland" thing
First of all sorry for the long delay - this version should be here three
weeks ago, but I've been kind of busy. This shouldn't happen anymore and
new version should be released no more than a week after the kernel. (yes,
I know 2.6.7 will probably be here in a week or so :)
As for the addition of sanitized scsi headers - I've had some requests for
it. Up until now I've encountered only one app that wanted something more
than glibc had to offer and am not entirely sure if using these headers
instead of glibc's won't break more things than it fixes. Test it if you
like and do send a bugreport if you find that it breaks something.
17. Linus Moving To Portland, Oregon
9 Jun (2 posts) Archive Link: "Linus is moving to Portland, OR"
People: Samantha Bee, Andrew Walrond
Samantha Bee said, "It's not mentioned anywhere in google news yet, but this
morning's Willamette Week claims that Linus has bought a house in Portland and
enrolled his kids in school here. http://www.wweek.com/story.php?story=5172"
Andrew Walrond quipped, "At least it's not Redmond ;)"
We Hope You Enjoy Kernel Traffic
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.