Re: 64bit port
H. Peter Anvin (hpa@transmeta.com)
Sun, 02 May 1999 02:34:01 -0700
Rogier Wolff wrote:
> > >
> > > This is the crux of it, see my other mail. When you have seperate,
> > > software controlled, instruction and data TLBs you can pull all of
> > > this off cleanly I believe.
> >
> > I actually think that you don't need either of those constraints. What
> > you *do* need, however, are separate r, w and x permissions on each
> > page. Also the instruction set needs to be amenable to these kinds of
> > scans; most RISCs are. You only need to keep each page in one of two
> > states: writable or executable. When you write to an executable page,
> > you get a trap, and flip it to the other state; when you execute, you
> > again get a trap, scan the page, and put it back in the executable
> > state.
>
> Yes, and because Dave knows the Sparc architecture inside and out, he
> knows he's going to implement this at the tlb level.
>
> You're thinking about permissions in the page table. Sparcs don't have
> a hardware paging table, you get to fill the TLB in software, and so
> at that time you get to do any additional checks that you may want...
>
All I said was that it wasn't necessary. I know what you can do with a
software-managed TLB, but I *also* know that the TLB-filling code tends
to be incredibly performance-critical.
Oh yes, and you really need to worry about pages that are aliased.
-hpa
--
"The user's computer downloads the ActiveX code and simulates a 'Blue
Screen' crash, a generally benign event most users are familiar with
and that would not necessarily arouse suspicions."
-- Security exploit description on http://www.zks.net/p3/how.asp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/