[PATCH]: Bug in ppc32 ld.so

Benjamin Herrenschmidt benh at kernel.crashing.org
Sat May 11 04:33:20 EST 2002

>On 10 May, Benjamin Herrenschmidt wrote:
>>>Hi Anton,
>>>I saw:
>>>Thanks for posting that patch.  Have you by any chance alerted or sent
>>>similar mail to YDL dev lists, Debian dev lists, SuSE dev lists, and
>>>dev at linuxppc.
>>>This would be a nasty bug to track down and those distributions may want to
>>>know about this and get an udpated glibc-2.2.5 packages posted on their
>>>sites for those brave users who are using later 2.4 kernels?
>>>BTW, any idea when this change by Paul was introduced into the 2.4 kernel
>>>series (specifically which 2.4.XX kernel?).
>> I submited a debian bug report with Anton message, Olaf (suse) is on
>> the linuxppc64 list and had the patch, YDL folks have or will have it
>> rsn (thanks to IRC magic ;)
>just wait.

Well, I bet the guy who manage to actually _use_ such a hole is
probably an alien. I don't think you can seriously consider this
as a hole, but let's see how things go. In all cases, if that was
a security hole, then as Anton says, sparc64 and alpha are affected

Let's fix ld.so, and separately see if the kernel bit is a security
hole or not.

>this is from geoffk
>> This is a potential security hole, it'd be better to fix it in the kernel.
>> >From a performance viewpoint we do not want to icache synchronise all
>> zero pages we hand out. Its expensive. If a process creates code that
>> will be executed it should do the complete dcbst; sync; icbi; isync
>> sequence. I cant see how an application could gain information from a
>> stale icache, it cant read it.
>It can run it and look at the result.  That may be all the information
>it needs.
>Suppose, for instance, a process has generated an decryption function
>with the key embedded for performance reasons.  If this page gets
>swapped to disk, and then zeroed and handed to another process, and is
>still in the icache, then the new process has the ability to do a
>decryption it wouldn't otherwise be able to do.  It could be possible,
>under the right circumstances, for a malicious process to do this

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

More information about the Linuxppc-dev mailing list