This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> Date: Sat, 11 May 2002 03:37:38 +1000
> From: Anton Blanchard <anton@samba.org>
> Cc: libc-alpha@sources.redhat.com
> Content-Disposition: inline
> User-Agent: Mutt/1.3.28i
> 
> 
> > 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.

> For some ppc64 machines Im going to switch to using the per page execute
> bit to lazily do icache synchonisation, but for the others (and most of
> the ppc32 cpus) we have do not have this luxury.
> 
> Anton
> 


-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]