On 30 January 2010 01:03, François Bissey <f.r.bis...@massey.ac.nz> wrote: > Hi Bill,
> It is a bit more subtle than that, it should work most of the time. The main > case where things could go south is if you have a hardened system with > the NX bit turned on - my guess. > It is a QA issue meaning that actual side effects are hard to predict > depending > on what is actually done. The check just points out to "bad practise". > > I guess I gave you too much info in one go. A lot of stuff is explained there > with what kind of steps that can be taken to get rid of them: > http://hardened.gentoo.org/gnu-stack.xml > > You inherited that stuff from gmp, it is a known issue there as well. The > problem is you have an enormous amount of assembler files so some systematic > approach is needed. By the way > > My comment about yasm is that the fix is also different if you use yasm > compared > to other assembler. In Gentoo gmp has a quite ugly patch that get rid of > all the problem in one go - on linux only - but wouldn't work with yasm. > > Francois First, it should be noted the problem is occurring with Solaris on SPARC, not x64. MPIR 1.3 builds on Open Solaris on ny Sun Ultra 27, which has an Intel Xeon W3580 3.33 GHz processor. The Intel Xeon has this "Execute Disable Bit". So one might expect the problem to exist on my Intel processor. http://ark.intel.com/Product.aspx?id=39723 but it does not. Other things to note are: * SPARC processors have long had this feature well before Intel or AMD. The protection was introduced in Solaris 2.6, which came out in July 1997. http://blogs.sun.com/gbrunett/entry/solaris_non_executable_stack_overview * The protection is not on by default on 32-bit code, though it is on 64-bit code. That could explain why this problem occurs on SPARC 64-bit, but not on SPARC 32-bit. * It is possible to disable this protection, though of course one needs root access to do this and the machine will need rebooting. Hence I do not wish to do this on 't2' just now, although I do have root access on 't2'. * Not only is it possible to enable/disable this, but it is possible to log this on Solaris, so one could determine who run what command which attempted to exploit the stack. I will however test this out later today (within the next 12 hours) on the Sun Blade 2000 I own. That will at least enable us to determine if it is the hardening in Solaris on SPARC which is causing this. The fact this has been around since 13 years on Solaris, makes me a bit suspicious this is not the reason. But the only way to be sure is to disable the protection. The only SPARC system I have running at home is busy, and I do not wish to reboot it. However, I have another SPARC which is not running now, but which I can run later today. My wife is asleep now, and since that Blade 2000 sounds like a rocket engine until the fan speed control kicks in, I can not start that machine now. Hence later today I will boot a SPARC with the protection disabled, which will determine if this is the cause or not. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
