From: Kaoru Fukui <k_fukui@highway.ne.jp>
To: benh@kernel.crashing.org
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: [PATCH]: Bug in ppc32 ld.so
Date: Sat, 11 May 2002 03:27:46 +0900 (JST) [thread overview]
Message-ID: <200205101830.DAA02518@mail.highway.ne.jp> (raw)
In-Reply-To: <20020510180647.19812@smtp.wanadoo.fr>
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/
next prev parent reply other threads:[~2002-05-10 18:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-10 17:08 Re:[PATCH]: Bug in ppc32 ld.so Kevin B. Hendricks
2002-05-10 18:06 ` Benjamin Herrenschmidt
2002-05-10 18:27 ` Kaoru Fukui [this message]
2002-05-10 18:33 ` [PATCH]: " Benjamin Herrenschmidt
2002-05-10 18:38 ` Kevin B. Hendricks
2002-05-10 21:13 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200205101830.DAA02518@mail.highway.ne.jp \
--to=k_fukui@highway.ne.jp \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).