PowerPC paxtest results w/ gcc-4.1
I just ran paxtest on a Mac G4 Cube. Ouch. The results are shameful. Does nobody care to fix this? (well heck, the patched firefox isn't showing up via aptitude yet, and my browser just died a horrible and unexpected death involving a pop-up ad, so I guess not!) I suppose part of the problem is that paxtest requires serious hacking to work right on PowerPC. Critical fixes are: 1. unnest the dummy() function (PaX marketing bullshit) 2. change the return opcode (see code below) 3. flush the cache as needed (see code below) 4. use the Makefile-portable that Gentoo has 5. compile with -W -Wall -fno-strict-aliasing and fix warnings With all that done, gasp in horror at the truth: Linux cube 2.6.17-rc5 #1 PREEMPT Sat May 27 20:35:12 EDT 2006 ppc GNU/Linux Executable anonymous mapping : Vulnerable Executable bss : Vulnerable Executable data : Vulnerable Executable heap : Vulnerable Executable stack : Vulnerable Executable anonymous mapping (mprotect) : Vulnerable Executable bss (mprotect): Vulnerable Executable data (mprotect) : Vulnerable Executable heap (mprotect) : Vulnerable Executable stack (mprotect) : Vulnerable Executable shared library bss (mprotect) : Vulnerable Executable shared library data (mprotect): Vulnerable Writable text segments : Vulnerable Anonymous mapping randomisation test : No randomisation Heap randomisation test (ET_EXEC): No randomisation Heap randomisation test (ET_DYN) : No randomisation Main executable randomisation (ET_EXEC) : No randomisation Main executable randomisation (ET_DYN) : No randomisation Shared library randomisation test: No randomisation Stack randomisation test (SEGMEXEC) : 11 bits (guessed) Stack randomisation test (PAGEEXEC) : 11 bits (guessed) Return to function (strcpy) : paxtest: bad luck Return to function (memcpy) : Vulnerable Return to function (strcpy, RANDEXEC): paxtest: bad luck Return to function (memcpy, RANDEXEC): Vulnerable Executable shared library bss: Vulnerable Executable shared library data : Vulnerable About the only saving grace is that the attacker would have to get lucky with the cache if they need code executed. Look, it's not as if we get closed-source binaries on PowerPC anyway. Non-free isn't the Debian way either. Screw the ABI. We need a fail-safe (enabled by default) fix for this. / code added to the top of paxtest body.h // // use this code in the obvious way #if defined(__ppc__) || defined(__powerpc__) #define RET 0x4e800020 // blr or bclr 20,0 #define FLUSH(x) __asm__ __volatile__(\ dcbf 0,%0 ; sync ; icbi 0,%0 ; sync ; isync ; sync \ :\ : r (x)\ : memory \ ) #endif #if defined(__i386__) || defined(__x86_64__) #define RET 0xc3c3c3c3 // ret ret ret ret #define FLUSH(x) #endif #include string.h /// -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
wmv3 on powerpc(and all)
Hi, If you want see wmv3 file without w32codecs, now you can. http://code.google.com/soc/ffmpeg/appinfo.html?csaid=5AA777DB19E2BB24 http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-August/013521.html http://sourceforge.net/mailarchive/forum.php?thread_id=29074592forum_id=7131 I've tested mplayer svn with some wmv3 on my testing/unstable, it works fine. Best regards, Bin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: wmv3 on powerpc(and all)
On 8/12/06, Bin Zhang [EMAIL PROTECTED] wrote: Hi, If you want see wmv3 file without w32codecs, now you can. http://code.google.com/soc/ffmpeg/appinfo.html?csaid=5AA777DB19E2BB24 http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2006-August/013521.html http://sourceforge.net/mailarchive/forum.php?thread_id=29074592forum_id=7131 I've tested mplayer svn with some wmv3 on my testing/unstable, it works fine. If you use the plugin mozilla-mplayer, maybe embedded video doesn't work. (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370517 ) Best regards, Bin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PowerPC paxtest results w/ gcc-4.1
Albert Cahalan writes: I just ran paxtest on a Mac G4 Cube. Ouch. The results are shameful. What gcc version, what binutils version, what kernel version? Paul. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xorg nv options
Hi 12 people,
i can use nv on 2.6.17.3 and all the kernels earlier since a while
with xorg nv driver and kernel nv fb device (video=nv:1024x768-60). My
external vga connector works pretty fine (at least with 1280x1024, did
not try more), and i can swsusp-resume a lot of times with the stock
vanilla swsusp.
The only thing is my first resume has to be done from tty console
(ctl-alt-f1 for example), after the first swsusp-resume cycle i can
suspend from xorg as well.
If anybody is interested in my kernel config i can post it somewhere.
Another thing that i wonder is i cannot boot 2.6.18-rc{2,3} with my
configuration. Boot process hangs quite early. Does anybody know whats
the problem there? Reading the changes i hope that powerpc things
there might fix my troubles (decompressing kernel on boot, might be
where my kernel hangs even if i thought my vmlinux os not compressed).
. cat /proc/cpuinfo
processor : 0
cpu : 7447A, altivec supported
clock : 666.666000MHz (lowered with cpufreq-userspace))
revision: 0.1 (pvr 8003 0101)
bogomips: 36.76
timebase: 18432000
platform: PowerMac
machine : PowerBook6,4
motherboard : PowerBook6,4 MacRISC3 Power Macintosh
detected as : 287 (PowerBook G4 12)
pmac flags : 001a
L2 cache: 512K unified
pmac-generation : NewWorld
Joerg
On Wed, Jul 19, 2006 at 09:07:02AM -0400, Guy Yasko wrote:
On 19 Jul 2006, Guido Guenther said:
On Sun, Jul 16, 2006 at 06:03:10PM +0200, Filippo Giunchedi wrote:
On Sat, Jul 15, 2006 at 06:19:33PM -0400, Benjamin Herrenschmidt
wrote:
I can successfully use the external vga out, however the laptop
LCD is not usable meanwhile. Note that you have to boot with the
external vga adaptor plugged in.
Actually suspending to disk is enough. This (at least in my case) is a
lot faster then the complete reboot.
That makes sense. However, I can only suspend-to-disk and wake up
once. My G4 12 (it's the 2005.2 version, i.e., PB 6,8) will hang on
the second wake up call.
--
Guy Yasko[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
libdvdread on debian testing
Hi people, im having trouble watching dvds on my 12 powerpook. Watching dvds worked perfectly since two years now, updating to some version with dist-upgrade might be the problem? It seems to me like a device thing as now i cannot eject the device with pbbuttons eject does not work anymore (i always get the result device busy, even if there is nothing accessing /dev/hdc, - lsof, fuser) Here are my messages from xine-player: libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.BUP failed libdvdread: Can't open file VIDEO_TS.IFO. If i mount the dvd manually, i can find the file and it is readable! With mplayer everything works, just the video is very small even in fullscreen, gmplayer video makes my screen and notebook hang, no ctl-alt-f2 possible anymore. I have the following packages installed: ii libdvdnav-dev 0.1.9-3The DVD navigation library, development pack ii libdvdnav4 0.1.9-3The DVD navigation library ii libdvdplay0 1.0.1-7portable abstraction library for DVD menus s ii libdvdread-dev 0.9.6-1library for reading DVDs (development) ii libdvdread3 0.9.6-1library for reading DVDs Thanks and regards, Joerg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PowerPC paxtest results w/ gcc-4.1
On 8/12/06, Paul Mackerras [EMAIL PROTECTED] wrote: Albert Cahalan writes: I just ran paxtest on a Mac G4 Cube. Ouch. The results are shameful. What gcc version, what binutils version, what kernel version? My gcc claims to be: Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --enable-checking=release powerpc-linux-gnu Thread model: posix gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5) I suppose binutils can be determined by ld: GNU ld version 2.16.91 20060413 Debian GNU/Linux The kernel version was reported: Linux cube 2.6.17-rc5 #1 PREEMPT Sat May 27 20:35:12 EDT 2006 ppc GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PowerPC paxtest results w/ gcc-4.1
Albert Cahalan writes: gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5) OK, so I think that version should have the new -msecure-plt flag, which changes the ppc32 ABI so that the PLT no longer has to be writable and executable. Previously the dynamic linker would rewrite each PLT entry, the first time it is used, to jump directly to the target routine. That was the reason why the heap had to be executable. To get the full benefit of -msecure-plt, every object file in your executable has to be compiled with it, and I think every shared library the program uses has to be compiled with it too. On a system where everything has been compiled with -msecure-plt, I believe the heap and stack will automatically be made non-executable. Of course, that won't make all that much difference on your Cube, because the G4 CPU doesn't have hardware support for non-executable pages (any readable page is executable). The G5 does, as do the 4xx and Book E 32-bit CPUs, and any 64-bit CPU from POWER4 on. As for the randomization, I'm surprised we got no stack randomization, since that appears to be handled generically (randomize_stack_stop() in fs/binfmt_elf.c). What does cat /proc/sys/kernel/randomize_va_space give you? (i386 also does arch-specific randomization of some low bits of the stack pointer, which we could do too.) Shared library randomization is a glibc thing, I assume. (It is incompatible with prelink, of course.) I don't believe we can do ET_EXEC address randomization, and I don't think x86 can do it either. Paul. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PowerPC paxtest results w/ gcc-4.1
On 8/12/06, Paul Mackerras [EMAIL PROTECTED] wrote: Albert Cahalan writes: gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5) OK, so I think that version should have the new -msecure-plt flag, The flag matters not, even with the very latest binutils that Debian offers, version 2.17-2: $ md5sum default m* 5f8398f47793ae0eee635989825c8e6b default 5f8398f47793ae0eee635989825c8e6b mbss-plt 5f8398f47793ae0eee635989825c8e6b msecure-plt (the default needs to be secure of course, so that all the Debian packages get it) To get the full benefit of -msecure-plt, every object file in your executable has to be compiled with it, and I think every shared library the program uses has to be compiled with it too. On a system where everything has been compiled with -msecure-plt, I believe the heap and stack will automatically be made non-executable. VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe default is important for security. If gcc on PowerPC ever does generate code which puts trampolines on the stack, then that can be fixed by converting to legal C code or by adding the fragile marking to the defective executables. Did gcc ever generate such code on PowerPC? If not, then there is no reason to ever allow an executable stack. In any case, I see no markings: $ eu-readelf -n /lib/libc-2.3.6.so Note segment of 32 bytes at offset 0x174: Owner Data size Type GNU 16 VERSION OS: Linux, ABI: 2.4.1 $ eu-readelf -n a.out Note segment of 32 bytes at offset 0x124: Owner Data size Type GNU 16 VERSION OS: Linux, ABI: 2.4.1 Of course, that won't make all that much difference on your Cube, because the G4 CPU doesn't have hardware support for non-executable pages (any readable page is executable). No. Look in the segment registers. The granularity isn't great, but the stack can be protected at least. With a decent memory layout, as is done for using the CS segment limit on i386, all but the bottom 256 MiB should be non-execute. Counting executable pages per segment is reasonable. I believe this is what OpenBSD does. A better way would be to frequently mark the segments as non-execute. (upon every context switch, mapping change, or sleep) Then, upon taking a fault, only enable execute in the segment if the instruction pointer is in an area which is really supposed to be executable. As for the randomization, I'm surprised we got no stack randomization, since that appears to be handled generically (randomize_stack_stop() in fs/binfmt_elf.c). What does cat /proc/sys/kernel/randomize_va_space give you? (i386 also does arch-specific randomization of some low bits of the stack pointer, which we could do too.) I get a 1. Shared library randomization is a glibc thing, I assume. (It is incompatible with prelink, of course.) It seems that glibc often asks for specific addresses, which is bad. The rest of the time this is a kernel issue. I don't believe we can do ET_EXEC address randomization, and I don't think x86 can do it either. Sure, but I just tried the other type (should be default) and didn't get any improvement. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PowerPC paxtest results w/ gcc-4.1
Albert Cahalan writes: VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe default is important for security. If gcc on PowerPC ever does generate code which puts trampolines on the stack, then that can be fixed by converting to legal C code or by adding the fragile marking to the defective executables. Did gcc ever generate such code on PowerPC? If not, then there is no reason to ever allow an executable stack. I believe it did for nested procedures in C. Now that we have the VDSO and use it for signal trampolines, we probably could change the default stack protections. No. Look in the segment registers. The granularity isn't great, but the stack can be protected at least. No, ld.so tends to go just below the stack: f7fe6000-f7fff000 r-xp 08:05 17069 /lib/ld-2.3.6.so f800e000-f800f000 r--p 00018000 08:05 17069 /lib/ld-2.3.6.so f800f000-f801 rwxp 00019000 08:05 17069 /lib/ld-2.3.6.so ffe67000-ffe7c000 rw-p ffe67000 00:00 0 [stack] Paul. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PowerPC paxtest results w/ gcc-4.1
On Sun, Aug 13, 2006 at 09:54:14AM +1000, Paul Mackerras wrote: To get the full benefit of -msecure-plt, every object file in your executable has to be compiled with it Yes. In particular, glibc startup files need to be compiled with -msecure-plt. If ld links any object file that uses the old scheme requiring an executable .got into the executable, then the old layout is forced. , and I think every shared library the program uses has to be compiled with it too. No, this isn't necessary. On a system where everything has been compiled with -msecure-plt, I believe the heap and stack will automatically be made non-executable. Exec stack is a separate issue from the plt/got layout. You need a kernel that sets non-exec stack by default and respects PT_GNU_STACK program header. -- Alan Modra IBM OzLabs - Linux Technology Centre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PowerPC paxtest results w/ gcc-4.1
On 8/12/06, Paul Mackerras [EMAIL PROTECTED] wrote: Albert Cahalan writes: VM_STACK_DEFAULT_FLAGS32 is wrong. A fail-safe default is important for security. If gcc on PowerPC ever does generate code which puts trampolines on the stack, then that can be fixed by converting to legal C code or by adding the fragile marking to the defective executables. Did gcc ever generate such code on PowerPC? If not, then there is no reason to ever allow an executable stack. I believe it did for nested procedures in C. I just disassembled libgcc. You're right. Eew. I filed a bug describing two better methods for this. Now that we have the VDSO and use it for signal trampolines, we probably could change the default stack protections. Heh. I though i386 was the only one to ever do that. The obvious method is to set the return address to be a special value which will fault, like -3. No. Look in the segment registers. The granularity isn't great, but the stack can be protected at least. No, ld.so tends to go just below the stack: f7fe6000-f7fff000 r-xp 08:05 17069 /lib/ld-2.3.6.so f800e000-f800f000 r--p 00018000 08:05 17069 /lib/ld-2.3.6.so f800f000-f801 rwxp 00019000 08:05 17069 /lib/ld-2.3.6.so ffe67000-ffe7c000 rw-p ffe67000 00:00 0 [stack] That looks like a 64-bit system, which doesn't have the granularity problem anyway. 32-bit powerpc seems to be decent. The heap shares with the executable itself, and of course there is the yucky 2 GB limit. $ cat /proc/self/maps 0010-00103000 r-xp 0010 00:00 0 0fe8b000-0ffd4000 r-xp 03:0d 2081203/lib/tls/libc-2.3.6.so 0ffd4000-0ffe3000 ---p 00149000 03:0d 2081203/lib/tls/libc-2.3.6.so 0ffe3000-0ffea000 r--p 00148000 03:0d 2081203/lib/tls/libc-2.3.6.so 0ffea000-0ffee000 rwxp 0014f000 03:0d 2081203/lib/tls/libc-2.3.6.so 0ffee000-0fff rwxp 0ffee000 00:00 0 1000-10005000 r-xp 03:0d 1327891/bin/cat 10014000-10015000 rwxp 4000 03:0d 1327891/bin/cat 10015000-10036000 rwxp 10015000 00:00 0 [heap] 3000-30019000 r-xp 03:0d 2080939/lib/ld-2.3.6.so 30019000-3001b000 rw-p 30019000 00:00 0 30028000-30029000 r--p 00018000 03:0d 2080939/lib/ld-2.3.6.so 30029000-3002a000 rwxp 00019000 03:0d 2080939/lib/ld-2.3.6.so 7fa45000-7fa5a000 rw-p 7fa45000 00:00 0 [stack] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
