Ok, I think that I've found the problem. The XFree86 binary does its own
object loading and on sparc it is failing to set the PROT_EXEC bit when
mapping executable code. This is falling over a change in the kernel
which checks the executable bit and gives a Segmentation Fault.
Full rationale, explanation and proposed patch below.
Richard
I was looking through the changes between 2.4.27 and 2.4.28 and there is
a patch that adds a check that executed code is actually mapped as
executable (one bit of it is)
diff -urN linux-2.4.27/arch/sparc64/mm/fault.c
linux-2.4.28/arch/sparc64/mm/fault.c
--- linux-2.4.27/arch/sparc64/mm/fault.c2004-08-07
16:26:04.0 -0700
+++ linux-2.4.28/arch/sparc64/mm/fault.c2004-11-17
03:54:21.156379721 -0800
@@ -404,6 +404,16 @@
*/
good_area:
si_code = SEGV_ACCERR;
+
+ /* If we took a ITLB miss on a non-executable page, catch
+* that here.
+*/
+ if ((fault_code & FAULT_CODE_ITLB) && !(vma->vm_flags &
VM_EXEC)) {
+ BUG_ON(address != regs->tpc);
+ BUG_ON(regs->tstate & TSTATE_PRIV);
+ goto bad_area;
+ }
+
if (fault_code & FAULT_CODE_WRITE) {
if (!(vma->vm_flags & VM_WRITE))
goto bad_area;
Now given that this reports a SIGSEGV if you hit this issue (see
SEGV_ACCERR at the top of the patch) I figured that this would be
something that could be triggered.
Now looking at the broken strace from 2.4.28 we see two mmaps during the
loading of module pcidata. These correspond to the text(code) and data
sections of the binary.
mmap(NULL, 163840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x70272000
lseek(5, 229836, SEEK_SET) = 229836
read(5, "\0pci_vendor_003d\0pci_vendor_0e11"..., 157024) = 157024
brk(0) = 0x274000
brk(0x296000) = 0x296000
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7029a000
lseek(5, 380, SEEK_SET) = 380
read(5, "\201\303\340\10\220\20 \1\201\303\340\10\1\0\0\0\235\343"...,
1612) = 1612
Note that neither has PROT_EXEC set in the mmap. The second one is the
text section that really needs it.
Now looking at the XFree86 code in
xc/programs/Xserver/hw/xfree86/loader/elfloader.c
This gets memory for the data in one of two ways (chosen at compile
time):
xf86loadermalloc - actually a call to the glibc2 malloc
or
mmap.
The mmap specifies PROT_EXEC but I've disassembled the XFree86 binary
and it seems to use the xf86loadermalloc option.
77514: 90 00 40 08 add %g1, %o0, %o0
77518: 40 05 69 49 call 0x1d1a3c
7751c: d0 24 60 48 st %o0, [ %l1 + 0x48 ]
77520: 84 10 00 08 mov %o0, %g2
77524: 80 a2 20 00 cmp %o0, 0
77528: 02 80 00 77 be 0x77704
Apologies to those who don't read SPARC assembler!
The call at 77518 is a call to malloc (from the symbol table)
001d1a3c DF *UND* 0234 GLIBC_2.0 malloc
I'm guessing that malloc doesn't set PROT_EXEC (people generally don't
want it and it would create a security risk).
Now in the elfloader.c file there is a bit of conditional code for ia64
and OpenBSD that does an mprotect to add PROT_EXEC to the code.
So it looks quite clear to me that we need to do the same for sparc.
i.e. apply the following patch (untested I'm afraid)
--- xc/programs/Xserver/hw/xfree86/loader/elfloader.c.orig
2004-12-02 16:56:31.0 +
+++ xc/programs/Xserver/hw/xfree86/loader/elfloader.c 2004-12-02
16:57:42.0 +
@@ -893,7 +893,7 @@
ErrorF( "ELFCreateGOT() Unable to reallocate memory\n"
);
return FALSE;
}
-# if defined(linux) && defined(__ia64__) || defined(__OpenBSD__)
+# if defined(linux) && (defined(__ia64__) || defined(__sparc__)) ||
defined(__OpenBSD__)
{
unsigned long page_size = getpagesize();
unsigned long round;
Anyone fancy compiling a new xserver binary?
On Thu, 2004-12-02 at 06:23, Jurzitza, Dieter wrote:
> Dear listmembers,
> I can confirm for my U60 that the XFree86-debug server comes up on 2.4.28. So
> I seem to be consistent with what Admar said and what Ron has been saying.
> What makes me wonder, though, is why does the binary loader work with 2.4.27
> and does not work with 2.4.28.
> And, moreover, if it is a loader issue it seems more plausible to me that I
> can observe additional side effects on 2.4.28 not being related to X11 (like
> very long reaction times on ping / ssh requests, not settling a network
> connection for quite a while)
> A propably dumb question:
> is that binary loader a simple file? would it be possible to get that loader
> from another version (like Debian Woody), or is it buried deep down in the
> kernel?
> Thank you for your inputs,
> take care
>
>
>
> Dieter Jurzitza
--
[EMAIL PROTECTED]
