$ paxctl -v /usr/bin/liferea PaX control v0.5 Copyright 2004,2005,2006,2007 PaX Team <pageexec@freemail.hu> - PaX flags: ----M--x-e-- [/usr/bin/liferea] MPROTECT is enabled RANDEXEC is disabled EMUTRAMP is disabled $ DISPLAY=:0.0 strace -etrace=open,mmap,mprotect liferea mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x6aee3400a000 open("/etc/gtk-2.0/x86_64-pc-linux-gnu/gtk.immodules", O_RDONLY) = 15 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x6aee3400a000 open("/usr/share/liferea/css/liferea.css", O_RDONLY) = 15 open("/root/.liferea_1.7/liferea.css", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/liferea/css/adblock.css", O_RDONLY) = 15 open("/root/.liferea_1.7/cache/style.css.8XQ8IV", O_RDWR|O_CREAT|O_EXCL, 0666) = 15 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x6aee3400a000 mmap(NULL, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EPERM (Operation not permitted) --- SIGSEGV (Segmentation fault) @ 0 (0) --- mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x6aee232a6000 Liferea did receive signal 11 $ paxctl -m /usr/bin/liferea $ paxctl -v /usr/bin/liferea PaX control v0.5 Copyright 2004,2005,2006,2007 PaX Team <pageexec@freemail.hu> - PaX flags: -----m-x-e-- [/usr/bin/liferea] MPROTECT is disabled RANDEXEC is disabled EMUTRAMP is disabled $ DISPLAY=:0.0 strace -etrace=open,mmap,mprotect liferea <runs and works> I've CC'es hardened@ to look athe the root of the issue more precisely. As my solution disables some security features here I was adviced to look at xulrunner for ./configure options to disable their JIT. If it will be an option xulrunner should export it as an USE flag. Patch for ebuild will follow.
Created attachment 248174 [details, diff] patch disables MPROTECT PaX feature
Created attachment 248176 [details] emerge --info
Another workaround is to remove the liferea cache, at least on my system it gives life back to liferea. But this should be fixed properly. I have hit this too before, but have not had the time to investigate it properly.
Is this the outcome of an update from a previous version of liferea?
> Is this the outcome of an update from a previous version of liferea? Nope. It is the first version I tried liferea on hardened. Would you like me to check older versions?
(In reply to comment #5) > > Is this the outcome of an update from a previous version of liferea? > > Nope. It is the first version I tried liferea on hardened. Would you like me to > check older versions? > You could probably try the latest stable version which is 1.6.3 by the time of writing. Thanks.
(In reply to comment #6) > You could probably try the latest stable version which is 1.6.3 by the time of > writing. Thanks. > Are 1.6 and 1.7 using the same cache?
> > Nope. It is the first version I tried liferea on hardened. Would you like me to > > check older versions? > > > > You could probably try the latest stable version which is 1.6.3 by the time of > writing. Thanks. The same SIGSEGV happens on stable liferea too (all caches deleted, etc.): # LANG=C DISPLAY=:0.0 strace liferea ... open("/root/.liferea_1.6/cache/style.css.9PV7IV", O_RDWR|O_CREAT|O_EXCL, 0666) = 21 fcntl(21, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) fstat(21, {st_dev=makedev(8, 7), st_ino=33071, st_mode=S_IFREG|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2010/09/21-20:28:10, st_mtime=2010/09/21-20:28:10, st_ctime=2010/09/21-20:28:10}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x6e9276043000 lseek(21, 0, SEEK_CUR) = 0 write(21, "body, table, div {font-family: S"..., 4096) = 4096 write(21, "x;\n}\n\n.enclosure * object {\n\tmar"..., 532) = 532 lstat("/root/.liferea_1.6/cache/style.css", {st_dev=makedev(8, 7), st_ino=33068, st_mode=S_IFREG|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=16, st_size=4628, st_atime=2010/09/21-20:27:40, st_mtime=2010/09/21-20:27:40, st_ctime=2010/09/21-20:27:40}) = 0 fsync(21) = 0 close(21) = 0 munmap(0x6e9276043000, 4096) = 0 rename("/root/.liferea_1.6/cache/style.css.9PV7IV", "/root/.liferea_1.6/cache/style.css") = 0 rt_sigaction(SIGTERM, {0xb892e934710, [TERM], SA_RESTORER|SA_RESTART, 0x6e9281bec490}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGINT, {0xb892e934710, [INT], SA_RESTORER|SA_RESTART, 0x6e9281bec490}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGHUP, {0xb892e934710, [HUP], SA_RESTORER|SA_RESTART, 0x6e9281bec490}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGBUS, {0xb892e935340, [BUS], SA_RESTORER|SA_RESTART, 0x6e9281bec490}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGSEGV, {0xb892e935340, [SEGV], SA_RESTORER|SA_RESTART, 0x6e9281bec490}, {SIG_DFL, [], 0}, 8) = 0 poll([{fd=6, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=3, events=POLLIN}], 8, 0) = 0 (Timeout) mmap(NULL, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EPERM (Operation not permitted) --- SIGSEGV (Segmentation fault) @ 0 (0) --- rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 futex(0x6e9281f1d800, FUTEX_WAKE_PRIVATE, 2147483647) = 0 write(1, "\nLiferea did receive signal 11 ("..., 53 Liferea did receive signal 11 (Segmentation fault). ) = 53 exit_group(1) = ? If I mark binary as NOMPROTECT (paxctl -m) everything runs fine.
(In reply to comment #3) > Another workaround is to remove the liferea cache, at least on my system it > gives life back to liferea. > But this should be fixed properly. In my case cache deletion does not fix SIGSEGV. Are you using xulrunner to render HTML?
(In reply to comment #9) > In my case cache deletion does not fix SIGSEGV. Are you using xulrunner to > render HTML? > Is there a choice other then webkit for 1.7? Does liferea die even with a empty feedlist? If not can you try to figure out which feed kills liferea for you? I cannot currently reproduce, because as I said all my problems have resolved themselves by removing the cache/style.css. (and are you seriously running liferea as root?)
> Does liferea die even with a empty feedlist? If not can you try to figure out > which feed kills liferea for you? I cannot currently reproduce, because as I > said all my problems have resolved themselves by removing the cache/style.css. It dies on default feedlist (if i remove .liferea_1.7/. Will trackdown exact one tomorrow. > (and are you seriously running liferea as root?) Just for liferea test.
*** Bug 340297 has been marked as a duplicate of this bug. ***
> Is there a choice other then webkit for 1.7? Seems there isn't. I also use gtk-webkit (lddtree shown me The Truth). > Does liferea die even with a empty feedlist? If not can you try to figure out > which feed kills liferea for you? I cannot currently reproduce, because as I > said all my problems have resolved themselves by removing the cache/style.css. It dies on empty feedlist. According to strace it copies 'style.css' to'~/.liferea_1.7/cache' and dies right after.
Created attachment 250077 [details] strace -oliferea.log -f liferea
(In reply to comment #14) > Created an attachment (id=250077) [details] > strace -oliferea.log -f liferea > This looks like my strace. I poke around in the C code but couldn't find where the mmap is done. I suspect one of the many libraries liferea links against.
> This looks like my strace. I poke around in the C code but couldn't find where > the mmap is done. I suspect one of the many libraries liferea links against. > I haven't got the exact backtrace, but I think it's webkit's JS JIT engine.
(In reply to comment #16) > I haven't got the exact backtrace, but I think it's webkit's JS JIT engine. > It is. WebKit only does this mmap only in one place, in the JIT. And if you pass EXTRA_ECONF="--disable-jit" to webkit merge process the crash disapperes.
I hit this bug, too and re-merging webkit-gtk with the --disable-jit configure option solved it. Thanks! now could we get a hardened useflag into webkit-gtk?
[ CCed gnome@ ] @gnome: what do you think of adding 'USE=+jit' useflag for net-libs/webkit-gtk? Something like the following: --- webkit-gtk-1.2.5.ebuild.orig 2010-10-11 16:47:37.000000000 +0300 +++ webkit-gtk-1.2.5.ebuild 2010-11-06 23:19:01.966114845 +0200 @@ -15,7 +15,7 @@ SLOT="0" KEYWORDS="~alpha ~amd64 ~arm ~ia64 ~ppc ~sparc ~x86 ~x86-fbsd ~x86-freebsd ~amd64-linux ~ia64-linux ~x86-linux ~x86-macos" # geoclue is missing -IUSE="coverage debug doc +gstreamer introspection" # aqua +IUSE="coverage debug doc +gstreamer introspection +jit" # aqua # use sqlite, svg by default # dependency on >=x11-libs/gtk+-2.13 for gail @@ -82,7 +82,8 @@ $(use_enable coverage) $(use_enable debug) $(use_enable gstreamer video) - $(use_enable introspection)" + $(use_enable introspection) + $(use_enable jit)" # Disable web-sockets per bug #326547 # quartz patch above does not apply anymore #$(use aqua && echo "--with-target=quartz")"
From my *personal* point of view (I am not sure about other gnome team members opinions), I think jit should be enabled always if possible and, then, I would probably prefer to simply pass "--disable-jit" when "hardened" USE flag is enabled, for example (if there is no way to make jit work on hardened)
didn't jit caused all sorts of headaches in previous revisions of webkit ?
(In reply to comment #21) > didn't jit caused all sorts of headaches in previous revisions of webkit ? > If I don't misremember, jit is being enable automatically on x86/amd64/arm and it doesn't seem to cause many problems (but this one with hardened)
i think there's a bug in webkit's JIT compiler code because it seemingly ignores the failed mmap(RWX) so you should report that upstream at least. second, once that bug is fixed, i expect the JIT compiler will fall back to the alternative automatically so in the end there will be no need for tweaking configure/USE flags/whatnot.
(In reply to comment #23) > i think there's a bug in webkit's JIT compiler code because it seemingly > ignores the failed mmap(RWX) so you should report that upstream at least. s/bug/feature/ apparently as it's an explicit CRASH() on mmap failure so seemingly they never intended to pursue the automatic fallback path. so i guess in the end the USE flag is the best approach (but that costs performance and cannot be controlled on a per-app basis).
*** Bug 344177 has been marked as a duplicate of this bug. ***
Created attachment 258793 [details, diff] patch disables MPROTECT PaX feature Fixed comment to reflect the reason we need it here.
(In reply to comment #26) > Created an attachment (id=258793) [details] > patch disables MPROTECT PaX feature > > Fixed comment to reflect the reason we need it here. > Looks like it will wait for making jit optional but, as asked in comment #20, why not only pass --disable-jit when hardened is used? I think other people are expected to always use jit
(In reply to comment #20) > From my *personal* point of view (I am not sure about other gnome team members > opinions), I think jit should be enabled always if possible and, then, I would > probably prefer to simply pass "--disable-jit" when "hardened" USE flag is > enabled, for example (if there is no way to make jit work on hardened) > You don't need to be on hardened profile to use a hardened-sourses or grsec/pax enable kernel so i would use jit use flag instead. We allready do it on some of the qt packages that we set +jit as default in IUSE and the security history on webkit dont looks good ether so i would prefer to have mprotect on for any app that use it.
(In reply to comment #28) It's possible to disable jit when either of USE=-jit / profile=hardened is true. Otherwise, I am all for some way of letting webkit-gtk run with MPROTECT enabled. Having MPROTECT disabled in a browser that's open to all kinds of threats defies the whole purpose of PaX in my opinion.
I've commited the patch disabling MPROTECT PaX feature to avoid SIGSEGVs on net-news/liferea's startup. Reassigning to gnome guys due to the fact that the issue lies in webkit's jit
+*webkit-gtk-1.2.6 (04 Jan 2011) + + 04 Jan 2011; Pacho Ramos <pacho@gentoo.org> + -files/webkit-gtk-1.1.15.2-unaligned.patch, -webkit-gtk-1.1.15.4.ebuild, + -files/webkit-gtk-1.1.15.4-darwin-quartz.patch, + -files/webkit-gtk-1.1.15.4-icu44.patch, +webkit-gtk-1.2.6.ebuild, + metadata.xml: + Version bump: Fixes crashes with newer libpng (>= 1.4), security fixes + CVE-2010-4198 CVE-2010-4197 CVE-2010-4204 CVE-2010-4206 CVE-2010-1791 + CVE-2010-3812 CVE-2010-3813. Also makes JIT support optional as it causes + problems with hardened (bug #338213). Remove old. + Now hardened will be able to mask "jit" use flag :-) 1.2.6 will probably go to stable soon since it fixes security bugs (bug 350598)
*** Bug 333263 has been marked as a duplicate of this bug. ***
webkit-gtk-1.2.6 is stable and we have masked the jit use flag on the hardened profile.
