[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Rep:Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume



-----Message d'origine-----
De: Yann Guidon <whygee@f-cpu.org>
A: f-cpu@seul.org
Date: 21/08/02
Objet: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB right + resume

hi,

Nicolas Boulay wrote:
> -----Message d'origine-----
> De: Michael Riepe <michael@stud.uni-hannover.de>
> 
> On Tue, Aug 20, 2002 at 09:05:08AM +0000, Nicolas Boulay wrote:
> [...]
> > > 4- diseable any possiblity of buffer overflow.
> >
> > Dto.
> >
> > >>> ??? don't understand that word.
> 
> Sorry... it was supposed to mean "same as above".
> 
> >>> This is the problem number one of the computer security, if it
> became impossible to do it, you see what reputation could have the
> f-cpu...

If there was an easy way to do this, then it would already be used
by everybody.

>>>And windows is the best OS because everybody use it ? :-/ Most of the
cpu of workstation have an old ISA, and maybe i could have some new idea
some times...

Unfortunately, everybody sticks with C and the select() exploit
is possible. This could have been avoided by using ADA or JAVA.
Java sux but at least, strongly typed langages are good at avoiding
silly errors like this.

>>>Client have always right ! Client (end user) use C for many reasons,
so must provide a good way to use C ! Nothing to add more. What do you
mean by select() exploit ?

Buffer overflows are another problems and it depends a lot on
the coder and the langage. The CPU can't do much on this matter,
particularly if a (dumb) coder wants to use a (dumb) langage.

>>> Hummm ! I don't think that the coder of mozilla,etc ... are so dumb
!

I think i'll simply make the TLB user-configurable
until F-CPU rev. 1 is frozen. This way, people could explore
the necessary/useless features. This is the easiest way to solve
the TLB problems because everybody wants something different.

>>> You mean  : just puting bits in tlb and parameter their meaning ?
How could you verify for read, write, instruction fetch, load&store in
tagged region in a configurable way ? Do we implement all of this ?
nicO

John Graley wrote:
> > From: Michael Riepe [mailto:michael@stud.uni-hannover.de]
<snip>
> > > >>> What you think about the idea of tagged page that could
> > > only be used by tagged read&write instructions (to protect
> > > data page of the kernel and return stack write) ?
> >
> > I'm afraid that will help only if you compile all your
> > binaries yourself (otherwise, they might contain "trojan writes").
> 
> Surely it would be a simple matter in software to search through
executables
> looking for the op-codes of illegal instructions before execution?

ever heard about self-modifying codes ?
sure they could be avoided by not allowing WX pages. but this opens
a new domain of vulnerabilities and this would not help against
physical failures.

>>>physical failure !!! You want to be fault tolerant. What a news !
But as i said in the previous mail, that a false problem !

maybe the solution lies somewhere else, not in the TLBs.

>>> Why ? Where are your arguments ?
nicO

> Cheers, John

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/


______________________________________________________________________________
Pour mieux recevoir vos emails, utilisez un PC plus performant !
Découvrez la nouvelle gamme DELL en exclusivité sur i (france)
http://www.ifrance.com/_reloc/signhdell

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/