X won't start: xf86MapVidMem: Could not mmap framebuffer (0

[mike33]

X won't start: xf86MapVidMem: Could not mmap framebuffer (0x000a0000,0x20000) (Invalid argument)

Note: X always worked with grsecurity kernel provided that I disabled mmprotect (and other protections) on /etc/X11/X . I have done that. I am using a config based on a config that worked in the recent past.

kernel: 2.6.36.3-grsec
hardware: toshiba satellite l505d-gs6000
Processor: dual core AMD
Videocard: radeon (using the standard opensource drivers)


Things I allready tried:
echo options radeon modeset=0 > /etc/modprobe.d/radeon-kms.conf
(and updated the initramfs's, including the grsecurity one)
I tried with pnpbios turned on and off.

Error message:

(II) RADEON(0): PCI card detected
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Loading /usr/lib/xorg/modules/libint10.so
(II) Module int10: vendor="X.Org Foundation"
compiled for 1.7.7, module version = 1.0.0
ABI class: X.Org Video Driver, version 6.0
(II) RADEON(0): initializing int10

Fatal server error:
xf86MapVidMem: Could not mmap framebuffer (0x000a0000,0x20000) (Invalid argument)

Also, at boot up, the first thing I get onscreen after grub inits is:
[ 0.598030] pci_root PNP0A08:00: address space collision: host bridge window [mem 0x000cc000-0x000cffff] conflicts with Video ROM [mem 0x000cc000-0x000cedff]
Loading, please wait...

Logs:
Xorg.0.log: http://pastebin.com/PdCHq2sM
dmesg: http://pastebin.com/a7qjUQTE

Please help me. I need X to work as I do 3d work.

[PaX Team]

(II) Loading sub module "int10"

hmm, why does X even need to load the int10 module?

Fatal server error:
xf86MapVidMem: Could not mmap framebuffer (0x000a0000,0x20000) (Invalid argument)

what's strace say on this mmap attempt?

Also, at boot up, the first thing I get onscreen after grub inits is:
[ 0.598030] pci_root PNP0A08:00: address space collision: host bridge window [mem 0x000cc000-0x000cffff] conflicts with Video ROM [mem 0x000cc000-0x000cedff]

does it happen with a vanilla kernel as well? my guess is that it does and you should probably talk to upstream about it.

PS: is there any reason why you don't enable PAE/NX support?

[mike33]

Heh, vanilla debian kernels don't even boot on this machine (they're too old).

I don't have PAE/NX enabled? I thought I had the stack protection things running?
BTW: this is an i386 compiled kernel running on a modern amd laptop.

Some things I need to do is have 2gb of memory addressable by an app (q3map2 map compiler).
(I wish I installed the 64bit version of debian but, I didn't , ohwell. I heard that NX bit or page based stack protection etc doesn't work in x64 mode )

I've asked the debian user forum about this bug and they couldn't help, I've asked the mailing list. How do I do the strace, and should I PM you the log of it? I use an encrypted SSD btw, will it contain my crypto key, I don't want that to get out.

[PaX Team]

Heh, vanilla debian kernels don't even boot on this machine (they're too old).

can you compile a vanilla kernel perhaps? i guess you did so for the grsec kernel at least .

I don't have PAE/NX enabled? I thought I had the stack protection things running?

your dmesg said so . you want PAE because it enables the use of the NX bit (i.e., you can use PAGEEXEC instead of SEGMEXEC then in PaX).

(I wish I installed the 64bit version of debian but, I didn't , ohwell. I heard that NX bit or page based stack protection etc doesn't work in x64 mode )

you can always compile an amd64 (64 bit) kernel, an i386 (32 bit) userland should work fine with it (if not, report it to your distro). the NX bit works fine in amd64 mode, in fact it was introduced there by AMD back in the day .

How do I do the strace, and should I PM you the log of it? I use an encrypted SSD btw, will it contain my crypto key, I don't want that to get out.

just run strace -f -ff -o xorg startx (or whatever command you use to start X) and it'll create xorg.* files that you can either upload somewhere on the web or email them to me. the volume keys are stored in the kernel, they're not part of a userland trace, no worries there .

[mike33]

Ok here is the xorg output (run as regular user, and then run as root)
http://ompldr.org/vNzIxaA/xorgstrace.zip

[mike33]

(Strace above)
I tried before to get help with this issue, but they just made fun of grsecurity and didn't help me at all with the Xorg issue
http://forums.debian.net/viewtopic.php? ... 79#p344479

I told them that vanilla debian kernel didn't boot, and that grsecurity always worked fine and I dont think it's that, and I disable with chpax prmx so X can run fine in the past.
(Note: 2.6.37 kernel doesn't boot at all, using 2.6.36.3, the .37 just reboots the machine immediatly after grub trys to execute the kernel, immedialty)

Maybe you can try temporarily deleting the special kernel you must use for security, and remove the radeon card that appears to be causing so many problems, and for security, since the data on your computer is apparently so sensitive, you should remove the hard drive as well. Then, because data in the RAM may be read by the Government Agents who routinely patrol your neighborhood with jugs of liquid nitrogen, you should remove that as well...just to be safe, you know. Now, to be REALLY REALLY sure no one can nick your data, you can use the secret NSA technique I use: Remove the cpu from the motherboard, turn it over and VERY carefully, with a small pair of wire cutters, clip off every 5th pin on the underside, then reinstall it. Now boot the computer and post the results of dmesg.....

Edit: Crap! I almost forgot the most important thing for keeping your data secure; I almost forgot the Government mind Reader Satellite for Emaciated Crackpots..(grsec) Protocol. Be absolutely sure you don your tinfoil hat before booting your now-safe computer.

2nd edit: It would appear that the time-honored method of defeating the grsec protocol with a tinfoil hat is no longer effective. The Government has learned how to use the 8th Barsoomian Ray of Repulsion to create a subatomic singularity that can penetrate tin foil. The only way to keep your data safe now is to pull the power cord out of a lamp, separate the 2 wires, bare 6" of the end of each wire, wrap the two bare ends securely around each ear, and plug it in to the outlet. This will scramble your brainwaves so they cannot tell what you are thinking.

How do I enable the NX bit and that other thing btw? Is it useful on an i386 compile on an amd64? Also I tried compiling for amd64 once, I don't think it worked right, don't remeber though. Should I enable both sem and page based stack exec protection? What does that do to programs that need to use 2gb or ram (or more )

[mike33]

The Debian people just make fun of PaX/Grsecurity the whole time:

*grabs popcorn*

*puts on tinfoil hat*

Edit: Crap! I almost forgot the most important thing for keeping your data secure; I almost forgot the Government mind Reader Satellite for Emaciated Crackpots..(grsec) Protocol. Be absolutely sure you don your tinfoil hat before booting your now-safe computer.

I know for a fact that grsecurity and PaX have prevented atleast one 0-day root attempt by a shell user on my server. Why shouldn't I use grsec?

Why are the debian people scumbags?

[mike33]

(strace logs, xorgroot is it run as root)
http://ompldr.org/vNzIxaA/xorgstrace.zip

[specs]

As far as I know Debian maintainers are not very security aware, unfortunately.

For example, have you read the "Verifying RELRO/SSP/PIE/ASLR/NX support on your distro" topic?
In the quick-test even Ubuntu scores a "Partial RELRO" while on debian the test yields "No RELRO". I have seen few hardening options in debian yet. There are also several default options I have to change with each new system I install (even with a minimal installation).

I would not bother using a debian kernel myself. I allways use the upstream vanilla-kernels from www.kernel.org since it does not costs me a lot of work extra. For most configurations those kernels work well enough, especially enhanced with a few out-of-tree patches.

Debian is not all bad though, I do like the way their package system. I have been wondering whether a debian server without compiler could be more secure than a hardened gentoo system. It would need compiling all packages by my lonesome self to add a few missing compile-time options to start with. I know I certainly would like a "hardened debian".

PS I have heard enough of those tin-hat like remarks myself already. You don't need debian-maintainers for that.

[mike33]

They banned me from the forum now, didn't help with the problem. First they derailed my first thread on the subject making fun of me, then they derailed the second topic after I closed the first topic, making fun of grsecurity.

They refuse to help, just said I should get rid of grsecurity and use a debian kernel.
Yes, I use a vanilla kernel and then apply the grsec patch, then move my previous .conf over, make menuconfig, see if there are any new pax, grsec, or crypto features, read through them, enable some, compile, compile modules, install both, make the intrid img, updategrub.

So, I hope PaXteam can figure out what's wrong. I also tried the 2.6.37 kernel thinking that this cold be some bug in the 2.6.36.3 (opensource kernel) radeon driver but the 2.6.37 kernel just restarts the machine immediatly once loaded, so can't use that, can't even see any errors it restarts so fast.

The tinfoil hat crap is bullshit because I know that grsec has saved my server machine atleast once, probably many more times.

[mike33]

(strace logs, xorgroot.bla is it run as root)
http://ompldr.org/vNzIxaA/xorgstrace.zip

Any ideas?

[spender]

Try disabling CONFIG_STRICT_DEVMEM -- I think it's enabled in your .config.

-Brad

[mike33]

You were correct, but still X does not run. I did as you said (changed that to =n, make clean, make menuconfig, checked the .config (saw that it was set to disabled as I set it), make, make modules, make modules_install, make install, then cd /boot, and remade the intrid image, then update-grub2)

What can I do to get you more info? Should I post the .config?

[spender]

Do you have CONFIG_X86_PAT enabled? Try disabling that as well (you may need to enable CONFIG_EMBEDDED to disable it).

If you want you can also add debugging to mmap_mem() in drivers/char/mem.c, making the code look like this:

Code: Select all

        if (!valid_mmap_phys_addr_range(vma->vm_pgoff, size)) {
                printk(KERN_ALERT "failed valid_mmap_phys_addr_range!\n");
                return -EINVAL;
        }

        if (!private_mapping_ok(vma))
                return -ENOSYS;

        if (!range_is_allowed(vma->vm_pgoff, size))
                return -EPERM;

        if (!phys_mem_access_prot_allowed(file, vma->vm_pgoff, size,
                                                &vma->vm_page_prot)) {
                printk(KERN_ALERT "failed phys_mem_access_prot_allowed!\n");
                return -EINVAL;
        }



-Brad

[mike33]

Ok I set those 2 config options, make menuconfiged, then checked the .config again and yes the options were still changed (PAT disabled, embed enabled) recompiled etc etc.

X still won't run.

What can I do now?