On Tue, Feb 05, 2008 at 02:11:06AM -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? > > And any idea if uClibc will need similar mods? The kernel has rather detailed knowledge about which workarounds are required for what platform and is optimized based on this knowledge. Userspace is different. The basic promise is that userspace will run on any platform above certain minimum specs. That is something like MIPS II code is expected to run find on MIPS III or MIPS32 r1 or MIPS64 r2 hardware for example. This promise includes even workarounds as far as practicable and occasionally requires doing things that are somewhat suboptimal for performance or coding style. But it keeps things deterministic for users. Ralf
