Add Capability class.

Add Capability class.

Currently throws UnimplementedError in constructor patches. All implementation is still missing.

R=floitsch@google.com, sgjesse@google.com

Committed: https://code.google.com/p/dart/source/detail?r=32274

[Lasse Reichstein Nielsen, 2014-01-29 13:46:32]

I think we should start by implementing capabilities.

They are unrelated to the isolate features we want to build on top of them, and
we seem to want them for other things too.

This is a draft of the class with documentation.
The actual implementation is obviously going to take some internal hacking in
each platform to make them roundtrip through send ports and preserve identity.

[floitsch, 2014-01-29 15:26:25]

Not sure about the identity requirement. Otherwise LGTM.

https://codereview.chromium.org/148883009/diff/1/sdk/lib/isolate/capability.dart
File sdk/lib/isolate/capability.dart (right):

https://codereview.chromium.org/148883009/diff/1/sdk/lib/isolate/capability.d...
sdk/lib/isolate/capability.dart:13: * A capability object preserves its identity
when sent through other isolates.
Do we need the identity requirement?
Equality would probably be enough.

I would say that the main advantage of capabilities is that they are
non-forgeable, can be transferred through isolate-communication, and are
guaranteed to be == only if they originate from the same capability.

They could just contain a random 8-byte string inside.

[Lasse Reichstein Nielsen, 2014-01-29 15:58:13]

https://codereview.chromium.org/148883009/diff/1/sdk/lib/isolate/capability.dart
File sdk/lib/isolate/capability.dart (right):

https://codereview.chromium.org/148883009/diff/1/sdk/lib/isolate/capability.d...
sdk/lib/isolate/capability.dart:13: * A capability object preserves its identity
when sent through other isolates.
I think identity is preferable.
It allows you to use "identical", which doesn't have the problem of accidentally
swapping the order of operands of an '==', which will allow a trick-capability
to claim equality with everything (users can implement Capability, but not
extend it - that's why I made the constructor a factory).

Whatever is stored inside must be completely hidden from user code, and not
accessed through dart code (or you might be able to fake it by extracting the
data and having suitable noSuchMethod behavior provide it).
Using 64 random bits might be fine (if you trust your random generater to not
leak information, I wouldn't trust Math.random in V8).

[floitsch, 2014-01-29 16:52:35]

https://codereview.chromium.org/148883009/diff/1/sdk/lib/isolate/capability.dart
File sdk/lib/isolate/capability.dart (right):

https://codereview.chromium.org/148883009/diff/1/sdk/lib/isolate/capability.d...
sdk/lib/isolate/capability.dart:13: * A capability object preserves its identity
when sent through other isolates.
On 2014/01/29 15:58:13, Lasse Reichstein Nielsen wrote:
> I think identity is preferable.
No doubt about that. The question is, if it's not too expensive.

> It allows you to use "identical", which doesn't have the problem of
accidentally
> swapping the order of operands of an '==', which will allow a trick-capability
> to claim equality with everything (users can implement Capability, but not
> extend it - that's why I made the constructor a factory).
I'm not sure this is an issue: inside the same isolate you are dead anyways.
Using reflection you can get whatever you want. You would have access to the
capability that is stored somewhere to compare against.
> 
> Whatever is stored inside must be completely hidden from user code, and not
> accessed through dart code (or you might be able to fake it by extracting the
> data and having suitable noSuchMethod behavior provide it).
If you had access to the what's inside, then you already have access to the
token.

> Using 64 random bits might be fine (if you trust your random generater to not
> leak information, I wouldn't trust Math.random in V8).
We will need something like this anyways. We can't transmit anything else.

[Søren Gjesse, 2014-01-29 17:03:34]

lgtm

[Lasse Reichstein Nielsen, 2014-01-30 12:07:02]

I'm now convinced that switching to equality, instead of identity, is an
acceptable compromise. It will make implementation simpler in general and less
problematic for dart2js which doesn't have weak maps.

For someone to inject a class that claims to be a capability into your equality
check, it requires them to be in the same isolate. At that point, you have lost
anyway - isolates is the security boundary of Dart, so malicious code in your
own isolate means that you are compromised, and they can probably get your
capability object directly.

[Lasse Reichstein Nielsen, 2014-01-31 09:55:32]

Ping Siva: Do you see any problems with implementing this description in the VM?

[Lasse Reichstein Nielsen, 2014-01-31 09:55:32]

Ping Siva: Do you see any problems with implementing this description in the VM?

[kasperl, 2014-01-31 12:14:06]

https://codereview.chromium.org/148883009/diff/20001/sdk/lib/isolate/capabili...
File sdk/lib/isolate/capability.dart (right):

https://codereview.chromium.org/148883009/diff/20001/sdk/lib/isolate/capabili...
sdk/lib/isolate/capability.dart:8: * An unforgable object that comes back as
equal when passed through other
unforgable -> unforgeable

[Lasse Reichstein Nielsen, 2014-02-04 09:23:48]

Committed patchset #3 manually as r32274 (presubmit successful).