date:20140514

m_get_tag returns same tag address when called multiple times

2014-05-14 Thread Sreenivasa Honnur

Hi,
In FreeBSd-11 Current i am seeing that m_tag_get() returns same tag address for 
two subsequent calls, and m_tag_find() results in panic with below stack trace. 
Anything wrong here?

Fatal trap 9: general protection fault while in kernel mode
cpuid = 4; apic id = 04
instruction pointer = 0x20:0x80959ff0
stack pointer   = 0x28:0xfe01acfa09a0
frame pointer   = 0x28:0xfe01acfa09d0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (irq277: t5nex0:0,5)
[ thread pid 12 tid 100128 ]
Stopped at  m_tag_locate+0x40:  cmpl%ebx,0xc(%rcx)

Here is the calling sequence;

1. get_mbuf_mtag: m:0xf8005b3e4c00 mtag:0xf8002c47d180

2. get_mbuf_mtag: m:0xf8005b3e5000 mtag:0xf8002c47d180

3. find_mbuf_mtag(0xf8005b3e4c00) results in above trace.

Note that the same code works fine in FBSD-9.1.

struct my_mbuf_cb * get_mbuf_mtag(struct mbuf *m)
{
struct m_tag*mtag;

mtag = m_tag_get(PACKET_TAG_PF, sizeof(struct my_mbuf_cb), M_NOWAIT);
if (mtag == NULL) {
os_log_info(Error allocating mtag\n,);
return (NULL);
}
bzero(mtag + 1, sizeof(struct my_mbuf_cb));
m_tag_prepend(m, mtag);
 
return ((struct my_mbuf_cb *)(mtag + 1));
}

static struct my_mbuf_cb * find_mbuf_mtag(struct mbuf *m)
{
struct m_tag*mtag;

if ((mtag = m_tag_find(m, PACKET_TAG_PF, NULL)) == NULL)
return (NULL);

return ((struct my_mbuf_cb *)(mtag + 1));
}

Thanks
Sreenivas
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

NTOS: ... message in /var/log/messages PANIC

2014-05-14 Thread Matthias Apitz


Hello,

I have encountered on a system:

$ uname -a
FreeBSD La-Habana 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r250588M: Sat Jun 22 
14:15:48 CEST 2013 
guru@La-Habana:/usr/obj/usr/home/guru/head/src/sys/GENERIC  i386

twice a PANIC, last line in /var/log/messages was always:

May  9 13:55:26 La-Habana kernel: NTOS: timer 0xc5ea5430 fired even though it 
was canceled
May 14 09:43:08 La-Habana kernel: NTOS: timer 0xc5f05430 fired even though it 
was canceled

What does this line mean?
Thanks

matthias
-- 
Matthias Apitz   |  /\   ASCII Ribbon Campaign:
E-mail: g...@unixarea.de |  \ /   - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ |   X- No proprietary attachments
phone: +49-170-4527211   |  / \   - Respect for open standards
 | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-14 Thread Shawn Webb

Hey All,

[NOTE: crossposting between freebsd-current@, freebsd-security@, and
freebsd-stable@. Please forgive me if crossposting is frowned upon.]

Address Space Layout Randomization, or ASLR for short, is an exploit
mitigation technology. It helps secure applications against low-level
exploits. A popular secure implementation is known as PaX ASLR, which is
a third-party patch for Linux. Our implementation is based off of PaX's.

Oliver Pinter, Danilo Egea, and I have been working hard to bring more
features and robust stability to our ASLR patches. We've done extensive
testing on amd64. We'd like to get as many people testing these patches.
Given the nature of them, we'd also like as many eyeballs reviewing the
code as well.

I have a Raspberry Pi and have noticed a few bugs. On ARM (at least, on
the RPI), when a parent forks a child, and the child gracefully exits,
the parent segfaults with the pc register pointing to 0xc000. That
address is always the same, no matter the application. If anyone knows
the ARM architecture well, and how FreeBSD ties into it, I'd like a
little guidance.

I also have a sparc64 box, but I'm having trouble getting a vanilla
11-current system to be stable on it. I ought to file a few PRs.

You can find links to the patches below.

Patch for 11-current:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

Patch for 10-stable:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

Thanks,

Shawn Webb

pgpnUWb8TUnz_.pgp
Description: PGP signature

panic on vt / kms rv610

2014-05-14 Thread Mark Atkinson

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I updated -current to r265915 w/ amd64 kernel and I get a panic
when I startx instantly (no video output of panic).   There is a LOR
right before the panic.

This is built using the VT kernel definition.

loading the old kernel built @ r264316 continues to load fine.

here's what normal under the old kernel looks like

$ kldstat
Id Refs AddressSize Name
 1   53 0x8020 19b8a48  kernel
 21 0x81c11000 9d81 linprocfs.ko
 31 0x81c1b000 44ba6linux.ko
 41 0x81c6 2349 ums.ko
 51 0x81c63000 6809 uftdi.ko
 61 0x81c6a000 3b95 ucom.ko
 71 0x81c6e000 16fd uhid.ko
 81 0x81c7 115db3   radeonkms.ko
 91 0x81d86000 48761drm2.ko
104 0x81dcf000 2004 iicbus.ko
111 0x81dd2000 1a3f iic.ko
121 0x81dd4000 1e35 iicbb.ko
131 0x81dd6000 1066 radeonkmsfw_RV610_pfp.ko
141 0x81dd8000 5b63 radeonkmsfw_RV610_me.ko
151 0x81dde000 1361 radeonkmsfw_R600_rlc.ko

relevant boot messages on problematic r265915:

May 12 23:41:00 kern.crit moby kernel: VT: running with driver vga.
[...]
May 12 23:41:00 kern.crit moby kernel: vgapci0: VGA-compatible
display port 0xdc00-0xdcff mem
0xd000-0xdfff,0xfe9f-0xfe9f irq 16 at device 0.0 on pci1
May 12 23:41:00 kern.crit moby kernel: vgapci0: Boot video device


Point of failure (also available at http://pastebin.com/scubtJE6 so
the line wrap doesn't make you go crazy):

May 12 23:42:05 kern.crit moby kernel: info: [drm] Initialized drm
1.1.0 20060810
May 12 23:42:05 kern.crit moby kernel: drmn0: Radeon HD 2400 XT on
vgapci0
May 12 23:42:05 kern.crit moby kernel: info: [drm] RADEON_IS_PCIE
May 12 23:42:05 kern.crit moby kernel: info: [drm] initializing
kernel modesetting (RV610 0x1002:0x94C1 0x1028:0x0D02).
May 12 23:42:05 kern.crit moby kernel: info: [drm] register mmio
base: 0xFE9F
May 12 23:42:05 kern.crit moby kernel: info: [drm] register mmio
size: 65536
May 12 23:42:05 kern.crit moby kernel: info: [drm]
radeon_atrm_get_bios: === Try ATRM...
May 12 23:42:05 kern.crit moby kernel: info: [drm]
radeon_atrm_get_bios: pci_find_class() found: 0:1:0:0, vendor=1002,
device=94c1
May 12 23:42:05 kern.crit moby kernel: info: [drm]
radeon_atrm_get_bios: Get ACPI device handle
May 12 23:42:05 kern.crit moby kernel: info: [drm]
radeon_acpi_vfct_bios: === Try VFCT...
May 12 23:42:05 kern.crit moby kernel: info: [drm]
radeon_acpi_vfct_bios: Get VFCT ACPI table
May 12 23:42:05 kern.crit moby kernel: info: [drm]
radeon_acpi_vfct_bios: Failed to get VFCT table: AE_NOT_FOUND
May 12 23:42:05 kern.crit moby kernel: info: [drm]
igp_read_bios_from_vram: === Try IGP's VRAM...
May 12 23:42:05 kern.crit moby kernel: info: [drm]
igp_read_bios_from_vram: VRAM base address: 0xd000
May 12 23:42:05 kern.crit moby kernel: info: [drm]
igp_read_bios_from_vram: Map address: 0xf800d000 (262144 bytes)
May 12 23:42:05 kern.crit moby kernel: info: [drm]
igp_read_bios_from_vram: Incorrect BIOS signature: 0x
May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon_read_bios:
=== Try PCI Expansion ROM...
May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon_read_bios:
Map address: 0xf80c (131072 bytes)
May 12 23:42:05 kern.crit moby kernel: info: [drm] ATOM BIOS: 113
May 12 23:42:05 kern.crit moby kernel: drmn0: info: VRAM: 256M
0x - 0x0FFF (256M used)
May 12 23:42:05 kern.crit moby kernel: drmn0: info: GTT: 512M
0x1000 - 0x2FFF
May 12 23:42:05 kern.crit moby kernel: info: [drm] Detected VRAM
RAM=256M, BAR=256M
May 12 23:42:05 kern.crit moby kernel: info: [drm] RAM width 64bits DDR
May 12 23:42:05 kern.crit moby kernel: [TTM] Zone  kernel: Available
graphics memory: 2016864 kiB
May 12 23:42:05 kern.crit moby kernel: [TTM] Initializing pool allocator
May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon: 256M of
VRAM memory ready
May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon: 512M of
GTT memory ready.
May 12 23:42:05 kern.crit moby kernel: info: [drm] Supports vblank
timestamp caching Rev 1 (10.10.2010).
May 12 23:42:05 kern.crit moby kernel: info: [drm] Driver supports
precise vblank timestamp query.
May 12 23:42:05 kern.crit moby kernel: info: [drm] radeon: irq
initialized.
May 12 23:42:05 kern.crit moby kernel: info: [drm] GART: num cpu
pages 131072, num gpu pages 131072
May 12 23:42:05 kern.crit moby kernel: info: [drm] probing gen 2
caps for device 8086:29b1 = 1/0
May 12 23:42:05 kern.crit moby kernel: info: [drm] Loading RV610
Microcode
May 12 23:42:05 kern.crit moby kernel: firmware:
'radeonkmsfw_RV610_pfp' version 0: 2304 bytes loaded at 0x81fd60d0
May 12 23:42:05 kern.crit moby kernel: firmware:
'radeonkmsfw_RV610_me' version 0: 21504 bytes loaded at 0x81fd80d0
May 12 23:42:05 kern.crit moby kernel:

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-14 Thread Adrian Chadd

Hi!

Cool! Does it run on MIPS? :P

-a

On 14 May 2014 06:58, Shawn Webb latt...@gmail.com wrote:
Hey All,

[NOTE: crossposting between freebsd-current@, freebsd-security@, and
freebsd-stable@. Please forgive me if crossposting is frowned upon.]

I also have a sparc64 box, but I'm having trouble getting a vanilla
11-current system to be stable on it. I ought to file a few PRs.

You can find links to the patches below.

Patch for 11-current:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

Patch for 10-stable:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

Thanks,

Shawn Webb
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-14 Thread Shawn Webb

It runs on all architectures FreeBSD supports. The question is how well
it runs. The wider the testing, the better the code, of course. We're
actively testing on amd64 and i386 with limited testing on sparc64 and
ARM. I've been running with this patches on amd64 on multiple machines
for months. amd64 is rock solid from my experience. But your mileage may
vary, hence the CFT. :-)

Thanks,

Shawn

On May 14, 2014 10:02 AM -0700, Adrian Chadd wrote:
Hi!

Cool! Does it run on MIPS? :P

-a

On 14 May 2014 06:58, Shawn Webb latt...@gmail.com wrote:
Hey All,

[NOTE: crossposting between freebsd-current@, freebsd-security@, and
freebsd-stable@. Please forgive me if crossposting is frowned upon.]

I also have a sparc64 box, but I'm having trouble getting a vanilla
11-current system to be stable on it. I ought to file a few PRs.

You can find links to the patches below.

Patch for 11-current:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-current-aslr-segvguard-SNAPSHOT.diff

Patch for 10-stable:
http://www.crysys.hu/~op/freebsd/patches/20140514091132-freebsd-stable-10-aslr-segvguard-SNAPSHOT.diff

Thanks,

Shawn Webb

pgph_5tsmmLH1.pgp
Description: PGP signature

Re: [CFT] ASLR, PIE, and segvguard on 11-current and 10-stable

2014-05-14 Thread Adrian Chadd

On 14 May 2014 10:09, Shawn Webb latt...@gmail.com wrote:
 It runs on all architectures FreeBSD supports. The question is how well
 it runs. The wider the testing, the better the code, of course. We're
 actively testing on amd64 and i386 with limited testing on sparc64 and
 ARM. I've been running with this patches on amd64 on multiple machines
 for months. amd64 is rock solid from my experience. But your mileage may
 vary, hence the CFT. :-)

:)

So for MIPS, there's a documented way to run up the emulator framework
to do testing.

https://wiki.freebsd.org/FreeBSD/MipsEmulation

That way you can give it a whirl before us MIPS people with hardware
can get around to it. :P



-a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

51 matches

Mail list logo