On Thu, Apr 15, 2010 at 08:50:01AM +0800, Ben Kloosterman wrote:
> If you can write a Fortran to CIL compiler it will work which is not that
> hard. However changing the desktop market from Windows and OSx is not my
> goal as it is too difficult and needs big marketing. My goal is a Niche
> where people want high security , reliability and low latency. Mobile phones
> , military uses ,Application servers etc I expect a lot of viruses will
> target phones in future and people will always be tricked into allowing
> something.

Well that makes some sense.

> Yes confirmations are regarded as bad and capability systems don't have them
> except for the install. Basically with capability security every application
> has a list of capabilities which the installer will confirm, obviously some
> things will be red flags ( ie high risk)  , one big change is that .NET
> assemblies are signed by a certificate so you have some idea who the code
> comes from.  Eg a Device Driver will be red flag and caution but most apps
> will just copy an assembly to a new dir ( green)  , A app throws up a red
> flag it can report why and the risk. I think red flags will be  infrequent
> enough. Like ACL system whether to allow non technical users the right to
> change device drivers , services and shared lib is a matter of policy.

But who sets the policy then?  Who owns the device?

> Note the difference though with an ACL OS the moment an app is installed it
> has access to everything the user (or root) has access to.  
> 
> Lastly the OS trusted parts are untouchable except for a trusted updater
> which will download the files from a central repository configured at
> install. 

Who decides who is trusted?

> You may ask how does it open data files etc , by the user clicking in a
> trusted file manager the user obviously is approving the action so no need
> to pop up a dialog etc ( the same on a console if the user specifies the
> file a file descriptor is passed into the app) . There is a lot of
> information on this and the Research OS are Eros, Capros and Coyotos. 

I guess given the application code is trusted/safe there should be
much less worry about buffer overrun exploits from the data file being
loaded.  Sounds reasonable in that case.

> Yes but you can't have ring 0 having write access and ring 3 not it has to
> be global once you set a page as Read only the only access is by changing
> the page to RW. Both MOSA and Sharp OS run with an MMU but still a single
> address space ( with all ring 0 code) which is ok for them as they are a
> more simple monolithic design hence they can mark pages as code or read only

So they use the MMU as an MPU essentially.

> SOOOS is a microkernel design and I believe to gain traction/acceptance I
> will need good performance ( with the history of Micro Kernels eg Mach3 and
> Minix) . With no pages I can't do it in HW though I can use segments. Note
> on Intel even with no MMU you can have a readonly flat code segment which
> grows up  and a rw data & stack segment which grows from the top down( or
> visa versa) , you only need the SW check to make sure they don't overlap( on
> x64 on i386 the HW has a seg limit) 

Yeah there is certainly historical issues to overcome to convince anyone
a microkernel is good for anything.

> That's attractive though I will need to add a 2 Meg shared.NET lib. Its
> better to start small.

I guess getting 32 or 64MB isn't too hard even for embedded systems
these days.

> It's the non mutable and parallelism that attracts me esp when new PC are
> able to run 12 threads in a single 6 core CPU.

I just saw that there are 32 core mips chips out there (that are real
cheap and rather power efficient too) with lots of fast IO on them
(caviumnetworks makes some for example).  I wonder if uclinux runs on
something like that. :)

-- 
Len Sorensen
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to