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

[Anton Blanchard <anton at samba dot org>]

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

Lets first look at the ld.so behaviour. Due to the bugs where programs
forget to properly icache synchronise, Paul and I want to have a debug
option where we pass pages out to userspace that have been seeded with
an illegal instruction. (actually the kernel will fill it with a page of
harmless supervisor instructions, execute the page, then do the clear
or copy).

With this debug option, ld.so will break straight away. If there is
a performance issue with the icbis then you should use the AUX ELF entries
Ben Herrenschmidt provided in the kernel that exports cacheline size. At
the moment it is hardwired to think the cache is 16 bytes which means
we do 2 or 8 times too many operations on most chips. ld.so batches
the invalidation sequence so extra icbis will probably be lost in the
noise of the sync instruction (which could take > 1000 cycles on a
POWER4 class machine for example).

Now also consider a virtually tagged icache (I believe 440 has this).
Since I know who owns what VSIDs I can avoid any icache synchronisation
if you owned that VSID. The icache now contains contents of another
process you own so there is no security hole. ld.so breaks again.

I strongly suggest this fix goes into glibc. These bugs are extremely
unfunny to chase down, and the optimisation is asking for trouble.

As for the possibility of a malicious process gaining information
from a stale icache, I think this it would be incredibly hard to
gain anything useful. I'd like some other opinions on this.

Anton