Cause of what David? MPIR 1.3.0 works absolutely fine on t2 if you set the library paths correctly.
On Jan 30, 3:28 am, David Kirkby <[email protected]> wrote: > On 30 January 2010 01:03, François Bissey <[email protected]> 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_over... > > * 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 [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
