Martin Michlmayr wrote: > FYI; read the section about MIPS I. Should be known already, for Debian this is uncritical as there is no supported MIPS I machine left.
Thiemo > ----- Forwarded message from Thiemo Seufer <[EMAIL PROTECTED]> ----- > > From: Thiemo Seufer <[EMAIL PROTECTED]> > Subject: Re: Tester with IP27/IP30 needed > Date: Tue, 5 Feb 2008 12:22:11 +0000 > To: Kumba <[EMAIL PROTECTED]> > Cc: Florian Lohoff <[EMAIL PROTECTED]>, Ralf Baechle <[EMAIL PROTECTED]>, > Thomas Bogendoerfer <[EMAIL PROTECTED]>, > [EMAIL PROTECTED], [EMAIL PROTECTED] > User-Agent: Mutt/1.5.17+20080114 (2008-01-14) > > 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 > > ----- End forwarded message ----- > > -- > Martin Michlmayr > http://www.cyrius.com/ > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
