Re:[PATCH]: Bug in ppc32 ld.so

Re:[PATCH]: Bug in ppc32 ld.so

[Kevin B. Hendricks]

Hi Anton,

I saw:

http://sources.redhat.com/ml/libc-alpha/2002-05/msg00052.html

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@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?).

Thanks,

Kevin


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

Re:[PATCH]: Bug in ppc32 ld.so

[Benjamin Herrenschmidt]

>Hi Anton,
>
>I saw:
>
>http://sources.redhat.com/ml/libc-alpha/2002-05/msg00052.html
>
>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@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 ;)

Ben.


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

Re: [PATCH]: Bug in ppc32 ld.so

[Kaoru Fukui]

On 10 May, Benjamin Herrenschmidt wrote:
>
>>Hi Anton,
>>
>>I saw:
>>
>>http://sources.redhat.com/ml/libc-alpha/2002-05/msg00052.html
>>
>>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@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.

Kaoru
-----------

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
intentionally.


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

Re: [PATCH]: Bug in ppc32 ld.so

[Benjamin Herrenschmidt]

>On 10 May, Benjamin Herrenschmidt wrote:
>>
>>>Hi Anton,
>>>
>>>I saw:
>>>
>>>http://sources.redhat.com/ml/libc-alpha/2002-05/msg00052.html
>>>
>>>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@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
too.

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


>Kaoru
>-----------
>
>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
>intentionally.
>
>
>
>


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

Re:[PATCH]: Bug in ppc32 ld.so

[Kevin B. Hendricks]

Hi Ben,

Its seems Geoff Keating and Anton are debating whether this patch should
not be included in glibc and instead the new kernel behavior be reverted
to icache synchronizing zero'd pages handed out by the kernel.

It seems Geoff thinks there may be a security risk in allowing the stale
code in the instruction cache code to be run and some benefit result by a
malicious process (not just library loading obviously).

So people might want to wait on this patch until things get flushed out
(puin intended!).

Either way, I would rather have a ld.so doing the complete icbi cache flush
anyway since it makes me feel safer inside!  I have been bitten by too
many cache flush related errors and I favor great overkill!

The discussion is on the libc-alpha mailing list (just follow the link I
sent and go to followups at the bottom).

Do you know where in the kernel this change was made by Paul  (head.S with
the zero page code? idle.c - with its zero page code during idle, or
misc.S where the cache flush routines are now or ...).  I am trying to
figure out when (what specific 2.4 kernel revision)  this came into.

Thought you might like to know.

Thanks,

Kevin

On May 10, 2002 02:06, Benjamin Herrenschmidt wrote:
> >Hi Anton,
> >
> >I saw:
> >
> >http://sources.redhat.com/ml/libc-alpha/2002-05/msg00052.html
> >
> >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@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 ;)
>
> Ben.


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

Re:[PATCH]: Bug in ppc32 ld.so

[Benjamin Herrenschmidt]

>Hi Ben,
>
>Its seems Geoff Keating and Anton are debating whether this patch should
>not be included in glibc and instead the new kernel behavior be reverted
>to icache synchronizing zero'd pages handed out by the kernel.
>
>It seems Geoff thinks there may be a security risk in allowing the stale
>code in the instruction cache code to be run and some benefit result by a
>malicious process (not just library loading obviously).
>
>So people might want to wait on this patch until things get flushed out
>(puin intended!).
>
>Either way, I would rather have a ld.so doing the complete icbi cache flush
>anyway since it makes me feel safer inside!  I have been bitten by too
>many cache flush related errors and I favor great overkill!

I fully agree with you ! Whatever we decide to do with the kernel
cache flush code, let's do the proper icbi in ld.so.

>The discussion is on the libc-alpha mailing list (just follow the link I
>sent and go to followups at the bottom).
>
>Do you know where in the kernel this change was made by Paul  (head.S with
>the zero page code? idle.c - with its zero page code during idle, or
>misc.S where the cache flush routines are now or ...).  I am trying to
>figure out when (what specific 2.4 kernel revision)  this came into.

clear_user_page, somewhere in arch/ppc/mm

>Thought you might like to know.
>
>Thanks,
>
>Kevin
>
>On May 10, 2002 02:06, Benjamin Herrenschmidt wrote:
>> >Hi Anton,
>> >
>> >I saw:
>> >
>> >http://sources.redhat.com/ml/libc-alpha/2002-05/msg00052.html
>> >
>> >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@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 ;)
>>
>> Ben.
>


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