Re: [f-cpu] little feed-back from the libre softawre meeting

[Michael Riepe <michael@stud.uni-hannover.de>]

On Sat, Jul 13, 2002 at 06:28:35PM +0200, Christophe Avoinne wrote:
[...]
> 1) Permission bits : rwx
>     - 'r' and 'w' are relevant for data memory (DCACHE, data "load" and
> "store" operations), but what could be the meaning of 'x' ?
>     - 'x' is relevant for code memory (ICACHE, instruction "load"
> operations, but what could be the meaning of 'r' or 'w' ?.
> It seems to me that DCACHE only needs 'r' and 'w' bits and ICACHE 'x' bit.
> But my question is about knowing if there would be two different TLB or an
> unified one ?

Different TLB entries for data and code `views' of the same page of
memory? That may introduce yet another aliasing problem.

BTW: why should a page NOT be both writable and executable?

> 2) Supervisor/user bits :
>     - 's' : some instructions which are considered as priviledged requires
> this bit set.

Inside the TLB?

> But I aggree with you : we should have like 'sr','sw','ur','uw' for data
> memory and 'sx','ux' for code memory (that way we can protect some user
> applications for accessing supervisor code pages with 'sx = 1' and 'ux' = 0
> in fact) if we want a more fined-grain protection.
> 
> 3) How to share code between memory spaces, especially for kernel or shared
> library codes :
>     - code pages can be shared between space memories; using a bit to tell
> if VMID must be checked for this page allows kernel code or shared library
> to run without excessive cache flushing because of a VMID differs between
> two processes.

In reality, processes sharing a code page will have individual TLB entries
for it, with different VMIDs. The page is shared, the TLB entry isn't.

> 4) Group bits : are we speaking about equivalence of unix group bits ? that
> is 'u','g' and 'o' ?

Not useful, IMHO. We only have two different user IDs: ordinary user and
supervisor.

> 5) Ring bits : well instead of Supervisor/user bit we have several bits to
> encode a level ring. A page must have a ring of lower priority to be
> accessed.

Big can of worms. If privileged code always has at least the same
access rights as unprivileged code, you have a built-in security hole
(see Intel). Contrary to popular belief, one must be able to give
privileged code *less* access rights than unprivileged code.

> 6) Inheritance bits : mostly a software issue I think, so I wouldn't detail
> them here.

Who inherits what?

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/