Kumba wrote: > Florian Lohoff wrote: >> On Sun, Feb 03, 2008 at 03:16:48AM +0100, Ralf Baechle wrote: >>> On Sat, Feb 02, 2008 at 05:08:31PM -0500, Kumba wrote: >>> >>>> Thomas Bogendoerfer wrote: >>>>> no suprise here. As Ralf already noted cache barrier is a restricted >>>>> instruction, it will always cause a illegal instruction when used >>>>> in user space. Nevertheless it looks like all IP28 are affected >>>>> by the simple exploit. Flo built glibc 2.7 with LLSC war workaround >>>>> and this avoids triggering the hang. >>>> Ah, didn't know the 'cache' instructions was kernel-mode only. >>>> Explains why it survived then :) >>>> >>>> How does one enable the LLSC war workaround in glibc? >>> By modifying the code ;-) >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462112 >> >> Flo > > Interesting. Is there a reason the kernel uses an #ifdef to choose > between 'bezq' and 'bezql' that's not needed in glibc itself? Or does > glibc itself lack a mechanism to detect CPU types to single out this > specific change? glibc for mips has currently no such mechanism. Note that this change breaks MIPS I CPUs, so it is not generally applicable. > And any idea if uClibc will need similar mods? It needs a similiar change to support R10000 v2.5. Thiemo
