Discussion:
Differences between zelenka and zandonai
(too old to reply)
Mike Hommey
2010-10-31 08:20:01 UTC
Permalink
Hi,

Firefox uses a technique they call "frame poisoning" to mitigate
dangling pointer bugs. It reserves a poison area at a fixed location
in the address space (and tries other places if that can't be done)
and makes dangling pointers point there so that the application ends
up crashing instead of being exploitable.

There is validation test in their test suite that verifies if that
technique works properly. While upstream version doesn't support s390,
adding support for it is pretty straightforward. The only problem I have
now is that while this works properly on zelenka, it doesn't work on
zandonai during the test suite run part of the build.

Is there a difference in the kernel or hardware that would explain this
behaviour?

I'm attaching the test program in question. It can be simply built with
g++ -o TestPoisonArea TestPoisonArea.cpp

Thanks,

Mike
Philipp Kern
2010-10-31 09:40:02 UTC
Permalink
Mike,
Post by Mike Hommey
Firefox uses a technique they call "frame poisoning" to mitigate
dangling pointer bugs. It reserves a poison area at a fixed location
in the address space (and tries other places if that can't be done)
and makes dangling pointers point there so that the application ends
up crashing instead of being exploitable.
There is validation test in their test suite that verifies if that
technique works properly. While upstream version doesn't support s390,
adding support for it is pretty straightforward. The only problem I have
now is that while this works properly on zelenka, it doesn't work on
zandonai during the test suite run part of the build.
Is there a difference in the kernel or hardware that would explain this
behaviour?
they are hosted on the same physical box, so there's no difference in hardware
at all. However, zandonai runs a backports kernel (2.6.32-bpo.5-s390x), and
zelenka runs a release kernel (2.6.26-2-s390x). I don't know why that is.
Post by Mike Hommey
I'm attaching the test program in question. It can be simply built with
g++ -o TestPoisonArea TestPoisonArea.cpp
Simly compiling and running it does seem to work, however.

(sid-s390-sbuild)***@zandonai:/build$ g++ -o TestPoisonArea TestPoisonArea.cpp
(sid-s390-sbuild)***@zandonai:/build$ ./TestPoisonArea
INFO | negative control allocated at 0x77fd9000
INFO | positive control allocated at 0x77cac000
INFO | poison area assumed at 0xf0dea000 (preferred addr)
TEST-PASS | reading negative control
TEST-PASS | executing negative control
TEST-PASS | writing negative control
TEST-PASS | reading positive control | Segmentation fault
TEST-PASS | executing positive control | Segmentation fault
TEST-PASS | writing positive control | Segmentation fault
TEST-PASS | reading poison area | Segmentation fault
TEST-PASS | executing poison area | Segmentation fault
TEST-PASS | writing poison area | Segmentation fault

Kind regards,
Philipp Kern
Mike Hommey
2010-10-31 10:10:02 UTC
Permalink
Post by Philipp Kern
Mike,
Post by Mike Hommey
Firefox uses a technique they call "frame poisoning" to mitigate
dangling pointer bugs. It reserves a poison area at a fixed location
in the address space (and tries other places if that can't be done)
and makes dangling pointers point there so that the application ends
up crashing instead of being exploitable.
There is validation test in their test suite that verifies if that
technique works properly. While upstream version doesn't support s390,
adding support for it is pretty straightforward. The only problem I have
now is that while this works properly on zelenka, it doesn't work on
zandonai during the test suite run part of the build.
Is there a difference in the kernel or hardware that would explain this
behaviour?
they are hosted on the same physical box, so there's no difference in hardware
at all. However, zandonai runs a backports kernel (2.6.32-bpo.5-s390x), and
zelenka runs a release kernel (2.6.26-2-s390x). I don't know why that is.
Post by Mike Hommey
I'm attaching the test program in question. It can be simply built with
g++ -o TestPoisonArea TestPoisonArea.cpp
Simly compiling and running it does seem to work, however.
INFO | negative control allocated at 0x77fd9000
INFO | positive control allocated at 0x77cac000
INFO | poison area assumed at 0xf0dea000 (preferred addr)
TEST-PASS | reading negative control
TEST-PASS | executing negative control
TEST-PASS | writing negative control
TEST-PASS | reading positive control | Segmentation fault
TEST-PASS | executing positive control | Segmentation fault
TEST-PASS | writing positive control | Segmentation fault
TEST-PASS | reading poison area | Segmentation fault
TEST-PASS | executing poison area | Segmentation fault
TEST-PASS | writing poison area | Segmentation fault
During the build, this is what happens:
INFO | negative control allocated at 0x40028000
INFO | positive control allocated at 0x4002a000
INFO | poison area assumed at 0xf0dea000 (preferred addr)
TEST-PASS | reading negative control
TEST-PASS | executing negative control
TEST-PASS | writing negative control
TEST-PASS | reading positive control | Segmentation fault
TEST-PASS | executing positive control | Segmentation fault
TEST-PASS | writing positive control | Segmentation fault
TEST-UNEXPECTED-FAIL | reading poison area
TEST-PASS | executing poison area | Illegal instruction
TEST-UNEXPECTED-FAIL | writing poison area

It's interesting to see the addresses used for negative and positive
control are significantly different, while running the program on
zelenka and zandonai by hand give an address in 0x77xxxxxx.

Could that be related to personality ?

Mike
--
To UNSUBSCRIBE, email to debian-s390-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@glandium.org
Philipp Kern
2010-10-31 12:50:01 UTC
Permalink
Post by Mike Hommey
INFO | negative control allocated at 0x40028000
INFO | positive control allocated at 0x4002a000
INFO | poison area assumed at 0xf0dea000 (preferred addr)
TEST-PASS | reading negative control
TEST-PASS | executing negative control
TEST-PASS | writing negative control
TEST-PASS | reading positive control | Segmentation fault
TEST-PASS | executing positive control | Segmentation fault
TEST-PASS | writing positive control | Segmentation fault
TEST-UNEXPECTED-FAIL | reading poison area
TEST-PASS | executing poison area | Illegal instruction
TEST-UNEXPECTED-FAIL | writing poison area
It's interesting to see the addresses used for negative and positive
control are significantly different, while running the program on
zelenka and zandonai by hand give an address in 0x77xxxxxx.
Could that be related to personality ?
schroot should yield the same personality as for the buildd, given that the
same chroot definition is used.

Kind regards,
Philipp Kern
Mike Hommey
2010-11-01 09:30:01 UTC
Permalink
Post by Philipp Kern
Post by Mike Hommey
INFO | negative control allocated at 0x40028000
INFO | positive control allocated at 0x4002a000
INFO | poison area assumed at 0xf0dea000 (preferred addr)
TEST-PASS | reading negative control
TEST-PASS | executing negative control
TEST-PASS | writing negative control
TEST-PASS | reading positive control | Segmentation fault
TEST-PASS | executing positive control | Segmentation fault
TEST-PASS | writing positive control | Segmentation fault
TEST-UNEXPECTED-FAIL | reading poison area
TEST-PASS | executing poison area | Illegal instruction
TEST-UNEXPECTED-FAIL | writing poison area
It's interesting to see the addresses used for negative and positive
control are significantly different, while running the program on
zelenka and zandonai by hand give an address in 0x77xxxxxx.
Could that be related to personality ?
schroot should yield the same personality as for the buildd, given that the
same chroot definition is used.
I found the trigger: GNU make. I don't why, though.

# cat test.mk
foo:
./TestPoisonArea
# make -f test.mk foo
./TestPoisonArea
INFO | negative control allocated at 0x40021000
INFO | positive control allocated at 0x40023000
INFO | poison area assumed at 0xf0dea000 (preferred addr)
TEST-PASS | reading negative control
TEST-PASS | executing negative control
TEST-PASS | writing negative control
TEST-PASS | reading positive control | Segmentation fault
TEST-PASS | executing positive control | Segmentation fault
TEST-PASS | writing positive control | Segmentation fault
TEST-UNEXPECTED-FAIL | reading poison area
TEST-PASS | executing poison area | Illegal instruction
TEST-UNEXPECTED-FAIL | writing poison area

Mike
--
To UNSUBSCRIBE, email to debian-s390-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@glandium.org
Loading...