[e-lang] Taming of Pict

[Toby Murray]

Hi Matej,

Interesting stuff.

Some quick questions on Pict:

 - Pict channels are typed. Say one has a channel that is typed to carry
values of type T. Can one declare this channel so that it is read-only
(ie. can only be used to read values of type T) or write only (can only
be used to write values of type T).
 - If one has a read-write channel (can be read and written to), can one
get a read-only capability to this channel, and another write-only
capability to this same channel? Then one could hand the read-only
capability to one module and the write-only capability to a second
module, allowing the second to write values to the first, but not vice
versa.


In the article you say:

"From the security point of view Pict is in principle as good as E."

I presume you mean Pict, like E, implements object-capability semantics
(equivalently it implements the "rules of allowed reference graph
dynamics" as you say in the paper). 

However, Pict could well be far more secure than E because the Pict
implementation (compiler, basically) is likely far smaller than the E
runtime.

I'd much rather run an OS kernel written in Tamed Pict than one written
in E, simply because Pict is so much more compact -- hence the TCB that
underpins Pict is much smaller than that which underpins E.

Perhaps more questions later as I keep reading.

Cheers

Toby


On Thu, 2008-01-24 at 17:49 +0100, Matej Kosik wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Friends,
> 
> During the summer, I have posted a lightweight article about taming of Pict (turning Pict into a
> proper object-capability language) and to a nearby conference (SOFSEM).
> 
> (paper)
> http://altair.sk:60001/mediawiki/upload/d/de/Sofsem2008.pdf
> 
> (slides)
> http://altair.sk:60001/mediawiki/upload/6/65/Sofsem2008-presentation.beamer.pdf
> 
> (prepared talk)
> http://altair.sk:60001/mediawiki/upload/4/4b/Sofsem2008-presentation.article.pdf
> 
> The talk is already over. It did not go to detail about the language (there was not much time) but
> hopefully covered usefullness object-capabilities.
> 
> The open problem were not solved yet (related to possibilities of untrusted components to waste as
> much memory and as much CPU without proper bounds). As soon as I complete boring commercial Erlang
> project, I will try tackle that. I believe they are solvable. The question is only the price---how
> much will TCB grow and how much flexible mechanisms for constraining "memory consumption" and "CPU
> consumption" will be available.
> 
> Two people helped me:
> - - Frank Piessens (as a shepherd helped me a lot with turning "conditionally accepted" paper to
> "accepted")
> - - Norman Hardy (helped me filter out some errors I was not able to recognize)
> I am grateful to both of them.
> 
> Best regards,
> - --
> Matej Kosik
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHmMG2L+CaXfJI/hgRAno1AKCPIcjR3D0vodIFkowcN8aQ1jze+ACg2SA2
> DmmOq80j+LNTvi9gOQxPt9s=
> =Rk7h
> -----END PGP SIGNATURE-----
> _______________________________________________
> e-lang mailing list
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang