Re: [PATCH] Athlon Prefetch workaround for 2.6.0test6

[Andi Kleen]

On Mon, Sep 29, 2003 at 09:08:20PM +0100, Jamie Lokier wrote:
> My thinking: Segments can be used by x86 virtualising programs which
> use a segment to move a "window" of address range accessible to the
> virtualised code.  It should _never_ be possible for the virtualised
> code, which may be malicious, to trigger reads outside the protected
> address range by various combinations of threads and triggering LDT
> modifications in the virtualiser.

Agreed. But access_ok() takes care of that. It does not guarantee
that the right instruction is checked, but whoever uses non zero
code segment bases can add their own checker or more likely
not use prefetch at all (it is likely ancient legacy code 
code anyways). 

> Btw, you assume that regs->xcs is a valid segment value.  I think that
> the upper 16 bits are not guaranteed to be zero in general on the
> IA32, although they clearly are zero for the majority of IA-32 chips.
> Are they guaranteed to be zero on AMD's processors?

That would be new to me. Can you quote a line that says that from
the architecture manual?

Also remember the code only runs on AMD.

> > If it gets any more complicated I would be inclined to just
> > handle the in kernel prefetches using __ex_table entries and give up
> > on user space.
> 
> __ex_table entries would have been a less controversial fix all along :)
> 
> Perhaps it is better to just not decode at all when CS != __KERNEL_CS
> && CS != __USER_CS?  Just fault.

Yep, I considered that too.

I think I will do that for x86-64 and 32bit can handle it all in 
user space as I suspect the patch is unmergeable anyways.

> > The x86-64 version just ignores all bases, that should be fine
> > too. Anybody who uses non zero code segments likely doesn't care about
> > performance and won't use prefetch ;-)
> 
> Does the x86-64 version ignore bases in 32 bit programs?

The CPU doesn't, the prefetch fix does.

I will add a check for __USER32_CS/__USER_CS and __KERNEL_CS to make
sure it will never wrap.

I'm dropping the original segment checking/code checking proposal for 32bit. 
It obviously was misguided and Linus was right from the beginning 
to reject it.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/