I am not sure if this is related. But when I code assembly to pass
a double precision floating point value (%xmm0) to printf, my program will
crash
without a stack frame. I am fine for passing strings and integers.
Here's the simple code:
.section .data
str:
.string "%f\n"
test:
.float 2.5
.section .text
.extern printf
.global main
main:
push %rbp # set-up stack frame
movq %rsp, %rbp # will fault without this
movl $str, %edi
movl $test, %eax
cvtss2sd (%rax), %xmm0
movq $1, %rax
call printf
movq $1, %rax
xorq %rdi, %rdi
syscall
If I remove the stack frame, this code will fault every time. Now, according
to the amd64 ABI, I shouldn't need a stack frame. Now, gcc compiles with stack
frames, but this does appear to be a memory bug. I'm just not sure where to go
next to research this further.
Here's my dmesg:
OpenBSD 3.8-beta (GENERIC) #210: Sat Aug 13 20:20:15 MDT 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1073278976 (1048124K)
avail mem = 909148160 (887840K)
using 22937 buffers containing 107536384 bytes (105016K) of memory
mainbus0 (root)
cpu0 at mainbus0: (uniprocessor)
cpu0: AMD Athlon(tm) 64 Processor 3000+, 1808.55 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
pci0 at mainbus0 bus 0: configuration mode 1
"Nvidia nForce4 DDR" rev 0xa3 at pci0 dev 0 function 0 not configured
"Nvidia nForce4 ISA" rev 0xa3 at pci0 dev 1 function 0 not configured
"Nvidia nForce4 SMBus" rev 0xa2 at pci0 dev 1 function 1 not configured
ohci0 at pci0 dev 2 function 0 "Nvidia nForce4 USB" rev 0xa2: irq 10, version
1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: Nvidia OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 10 ports with 10 removable, self powered
ehci0 at pci0 dev 2 function 1 "Nvidia nForce4 USB" rev 0xa3: irq 11
usb1 at ehci0: USB revision 2.0
uhub1 at usb1
uhub1: Nvidia EHCI root hub, rev 2.00/1.00, addr 1
uhub1: 10 ports with 10 removable, self powered
auich0 at pci0 dev 4 function 0 "Nvidia nForce4 AC97" rev 0xa2: irq 11, nForce4
AC97
ac97: codec id 0x414c4760 (Avance Logic ALC655)
audio0 at auich0
pciide0 at pci0 dev 6 function 0 "Nvidia nForce4 IDE" rev 0xa2: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: <HL-DT-ST, DVDRAM GSA-4163B, A103> SCSI0 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
pciide1 at pci0 dev 7 function 0 "Nvidia nForce4 SATA 1" rev 0xa3: DMA
(unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide1: using irq 10 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: <WDC WD360GD-00FLA2>
wd0: 16-sector PIO, LBA48, 35304MB, 72303840 sectors
pciide1: channel 1 ignored (not responding; disabled or no drives?)
pciide2 at pci0 dev 8 function 0 "Nvidia nForce4 SATA 2" rev 0xa3: DMA
(unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide2: using irq 11 for native-PCI interrupt
pciide2: channel 0 ignored (not responding; disabled or no drives?)
pciide2: channel 1 ignored (not responding; disabled or no drives?)
ppb0 at pci0 dev 9 function 0 "Nvidia nForce4 PCI-PCI" rev 0xa2
pci1 at ppb0 bus 1
vga1 at pci1 dev 5 function 0 "ATI Rage XL" rev 0x27
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
"VIA VT6306 FireWire" rev 0x80 at pci1 dev 6 function 0 not configured
"Nvidia CK804 LAN" rev 0xa3 at pci0 dev 10 function 0 not configured
ppb1 at pci0 dev 11 function 0 "Nvidia nForce4 PCIE" rev 0xa3
pci2 at ppb1 bus 2
ppb2 at pci0 dev 12 function 0 "Nvidia nForce4 PCIE" rev 0xa3
pci3 at ppb2 bus 3
ppb3 at pci0 dev 13 function 0 "Nvidia nForce4 PCIE" rev 0xa3
pci4 at ppb3 bus 4
bge0 at pci4 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1 (0x4101):
irq 5 address 00:e0:81:56:8f:66
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb4 at pci0 dev 14 function 0 "Nvidia nForce4 PCIE" rev 0xa3
pci5 at ppb4 bus 5
pchb0 at pci0 dev 24 function 0 "AMD AMD64 HyperTransport" rev 0x00
pchb1 at pci0 dev 24 function 1 "AMD AMD64 Address Map" rev 0x00
pchb2 at pci0 dev 24 function 2 "AMD AMD64 DRAM Cfg" rev 0x00
pchb3 at pci0 dev 24 function 3 "AMD AMD64 Misc Cfg" rev 0x00
isa0 at mainbus0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pmsi0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pmsi0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
dkcsum: wd0 matches BIOS drive 0x80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
auich0: measured ac97 link rate at 48010 Hz, will use 48000 Hz
> like to ask the community to do lots of testing over the next week if
> they can.
>
> This release will bring a lot of new ideas from us. One of them in
> particular is somewhat risky. I think it is time to talk about that
> one, and let people know what is ahead on our road.
>
> Traditionally, Unix malloc(3) has always just "extended the brk",
> which means extending the traditional Unix process data segment to
> allocate more memory. malloc(3) would simply extend the data segment,
> and then calve off little pieces to requesting callers as needed. It
> also remembered which pieces were which, so that free(3) could do it's
> job.
>
> The way this was always done in Unix has had a number of consequences,
> some of which we wanted to get rid of. In particular, malloc & free
> have not been able to provide strong protection against overflows or
> other corruption.
>
> Our malloc implementation is a lot more resistant (than Linux) to
> "heap overflows in the malloc arena", but we wanted to improve things
> even more.
>
> Starting a few months ago, the following changes were made:
>
> - We made the mmap(2) system call return random memory addresses. As well
> the kernel ensures that two objects are not mapped next to each other;
> in effect, this creates unallocated memory which we call a "guard page".
>
> - We have changed malloc(3) to use mmap(2) instead of extending the data
> segment via brk()
>
> - We also changed free(3) to return memory to the kernel, un-allocating
> them out of the process.
>
> - As before, objects smaller than a page are allocated within shared
> pages that malloc(3) maintains. But their allocation is now somewhat
> randomized as well.
>
> - A number of other similar changes which are too dangerous for normal
> software or cause too much of a slowdown are available as malloc options
> as described in the manual page. These are very powerful for debugging
> buggy applications.
>
> Other results:
>
> - When you free an object that is >= 1 page in size, it is actually
> returned to the system. Attempting to read or write to it after
> you free is no longer acceptable. That memory is unmapped. You get
> a SIGSEGV.
>
> - For a decade and a bit, we have been fixing software for buffer overflows.
> Now we are finding a lot of software that reads before the start of the
> buffer, or reads too far off the end of the buffer. You get a SIGSEGV.
>
> To some of you, this will sound like what the Electric Fence toolkit
> used to be for. But these features are enabled by default. Electric
> Fence was also very slow. It took nearly 3 years to write these
> OpenBSD changes since performance was a serious consideration. (Early
> versions caused a nearly 50% slowdown).
>
> Our changes have tremendous benefits, but until some bugs in external
> packages are found and fixed, there are some risks as well. Some
> software making incorrect assumptions will be running into these new
> security technologies.
>
> I discussed this in talks I have given before: I said that we were
> afraid to go ahead with guard pages, because a lot of software is just
> written to such low standards. Applications over-read memory all the
> time, go 1 byte too far, read 1 byte too early, access memory after free,
> etc etc etc.
>
> Oh well -- we've decided that we will try to ship with this protection
> mechanism in any case, and try to solve the problems as we run into
> them.
>
> Two examples:
>
> Over the last two months, some OpenBSD users noticed that the X server
> was crashing occasionally. Two bugs have been diagnosed and fixed by
> us. One was a use-after-free bug in the X shared library linker. The
> other was a buffer-over-read bug deep down in the very lowest level
> fb* pixmap compositing routines. The latter bug in particular was
> very difficult to diagnose and fix, and is about 10 years old. We
> have found other bugs like this in other external software, and even a
> few in the base OpenBSD tree (though those were found a while back,
> even as we started experimenting with the new malloc code).
>
> I would bet money that the X fb* bug has crashed Linux (and other) X
> servers before. It is just that it was very rare, and noone ever
> chased it. The new malloc we have just makes code get lucky less
> often, which lets us get to the source of a bug easier. As a
> programmer, I appreciate anything which makes bugs easier to
> reproduce.
>
> We expect that our malloc will find more bugs in software, and this
> might hurt our user community in the short term. We know that what
> this new malloc is doing is perfectly legal, but that realistically
> some open source software is of such low quality that it is just not
> ready for these things to happen.
>
> We ask our users to help us uncover and fix more of these bugs in
> applications. Some will even be exploitable. Instead of saying that
> OpenBSD is busted in this regard, please realize that the software
> which is crashing is showing how shoddily it was written. Then help
> us fix it. For everyone.. not just OpenBSD users.
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
