Re: head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__

On 2017-Jul-1, at 8:40 PM, Konstantin Belousov wrote: > On Sat, Jul 01, 2017 at 07:42:11PM -0700, Mark Millard wrote: >> powerpc64 is having programs crash with an attempt >> to store addresses over code instead of into >> __cleanup_info__ when fgets is used. ntpd is an >> example. As is sshd

Re: head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__

On Sat, Jul 01, 2017 at 07:42:11PM -0700, Mark Millard wrote: > powerpc64 is having programs crash with an attempt > to store addresses over code instead of into > __cleanup_info__ when fgets is used. ntpd is an > example. As is sshd (although I've looked at > its details less). Yes, I think you

Re: head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__

[I've now got a route to get information from the old PowerMac so-called "Quad Core" despite sshd being broken. So I add gdb output material as evidence to go with the more source code level analysis from before.] On 2017-Jul-1, at 7:42 PM, Mark Millard wrote: > [Note: this is from a amd64 ->

head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__

[Note: this is from a amd64 -> powerpc64 cross-build based on system clang 4 instead of gcc 4.2.1. I'm building a gcc 4.2.1 based system currently so that I can test a more standard configuration. But I'm one of the ones that experiments with finding things to report for clang targeting powerpc64

Possible to set security.bsd.stack_guard_page to a negative value

Even though it'd be a stupid thing to do, the security.bsd.stack_guard_page sysctl node can be set to a negative integer value. This will cause all applications to crash with SIGABRT. -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key

Re: Reproducible panic with MAP_GUARD and security.bsd.stack_guard_page > 1

On Sat, Jul 01, 2017 at 01:28:47PM -0400, Shawn Webb wrote: > When running my Stack Clash PoC on a vanilla FreeBSD 12-CURRENT/amd64 VM > and security.bsd.stack_guard_page is > 1: > > https://goo.gl/photos/vZQY4B9jKJRLrNwP7 > > The PoC doesn't need to be run as root on vanilla FreeBSD with a

Re: running binary in chroot using qemu-arm-static fails to mmap after r320318

On Sat, Jul 1, 2017 at 2:46 PM, Guy Yur wrote: > Hi, > > I tried to run armv6 /bin/sh in a chroot on an > amd64 host using qemu-arm-static. > It failed on invalid argument to mmap. > > # cp /usr/local/bin/qemu-arm-static /chroots/armv6/root/ > # chroot /chroots/armv6

running binary in chroot using qemu-arm-static fails to mmap after r320318

Hi, I tried to run armv6 /bin/sh in a chroot on an amd64 host using qemu-arm-static. It failed on invalid argument to mmap. # cp /usr/local/bin/qemu-arm-static /chroots/armv6/root/ # chroot /chroots/armv6 /root/qemu-arm-static /bin/sh /lib/libedit.so.7: mmap of entire address space failed:

Reproducible panic with MAP_GUARD and security.bsd.stack_guard_page > 1

When running my Stack Clash PoC on a vanilla FreeBSD 12-CURRENT/amd64 VM and security.bsd.stack_guard_page is > 1: https://goo.gl/photos/vZQY4B9jKJRLrNwP7 The PoC doesn't need to be run as root on vanilla FreeBSD with a default configuration. Thanks, -- Shawn Webb Cofounder and Security

Re: Current amd64 new error or warning from today's current with ruby r320323

On Tue, Jun 27, 2017 at 1:56 PM, Trond Endrestøl < trond.endres...@fagskolen.gjovik.no> wrote: > On Tue, 27 Jun 2017 20:28+0200, Trond Endrestøl wrote: > > > On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote: > > > > > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > >

Re: r320528? "undefined reference to `_bus_dma*" linking kernel

Hi David, On Sat, Jul 1, 2017 at 4:26 AM, David Wolfskill wrote: > > > --- kernel.full --- > /usr/src/sys/dev/advansys/adwcam.c:302: undefined reference to > `_bus_dmamap_sync' > /usr/src/sys/dev/advansys/adwcam.c:316: undefined reference to > `_bus_dmamap_unload' >

Re: r320528? "undefined reference to `_bus_dma*" linking kernel

On Sat, Jul 01, 2017 at 08:59:58AM -0700, Jason Harmening wrote: > ... > These are all functions that were removed entirely or inlined for x86 in > r320528. > Looks like you have stale object files hanging around, seems like make > clean should fix it. OK; I'll pass that along to bdrewery@, as

Re: HEAD/i386 r320212: three reproducible panics [see also bugzilla 220404 about a type of problem introduced in head -r329722 ]

On Friday 30 June 2017 22:45:39 Mark Millard wrote: > [Just for the 3rd backtrace example. . .] > > Oleg V. Nauman oleg at theweb.org.ua wrote on > Fri Jun 23 16:58:07 UTC 2017 : > > .. . . > > > __curthread () at ./machine/pcpu.h:225 > > 225 __asm("movl %%fs:%1,%0" : "=r" (td) > > (kgdb)

r320528? "undefined reference to `_bus_dma*" linking kernel

This is for a transition from r320495 --> r32053ng: FreeBSD g1-227.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #396 r320495M/320496:1200036: Fri Jun 30 05:20:04 PDT 2017 r...@g1-227.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 ... >>> World build completed on Sat Jul 1

Re: HEAD/i386 r320212: three reproducible panics [see also bugzilla 220404 about a type of problem introduced in head -r329722 ]

[Just for the 3rd backtrace example. . .] Oleg V. Nauman oleg at theweb.org.ua wrote on Fri Jun 23 16:58:07 UTC 2017 : . . . > __curthread () at ./machine/pcpu.h:225 > 225 __asm("movl %%fs:%1,%0" : "=r" (td) > (kgdb) #0 __curthread () at ./machine/pcpu.h:225 > #1 doadump