[cap-talk] Singletons Considered Harmful
daw at cs.berkeley.edu
Tue Mar 30 16:48:04 PDT 2010
Raoul Duke wrote:
>On Tue, Mar 30, 2010 at 11:30 AM, David Wagner <daw at cs.berkeley.edu> wrote:
>> Raoul Duke wrote:
>>>personally, i also find the bit about how a debug log is allowed to be
>>>highly unrealistic, or at least is using connotations that i do not
>>>use. anything which chances timing can be a covert channel;
>> I don't think covert channels are a good argument here.
>> Every real general-purpose I've ever seen has covert channels,
>> and eliminating logging isn't going to change that. (Put more
>> precisely, even without access to debug logging, untrusted code
>> will still be able to send bits over a covert channel.)
>i am confused, failing to parse if you mean what i said was off the
>mark, or if the page in question should elide the mention of covert
>channels wrt the validity/safety of singletons for logging.
Oops, sorry that my message was not clear!
The web page says debug logs are OK.
You criticized the web page: you argued that debug logs are
not OK, because of covert channels. (You argued that debug logs
introduce covert channel risks.)
I am not convinced by that argument.
(I don't believe that debug logs increase the risk of covert
channels, because I think the risk of covert channels is already
there even if debug logs are not allowed, so I don't think debug
logs change the risk level.)
So I think the web page is fine, and
I think what you said about covert channels is off the mark.
>>>a log can fill disks or change thread timing which clearly can
>> Aren't there many other things that code could do which
>> might change thread timing, even if you don't allow logging?
>ditto, i'm not sure if you mean this undoes what i was saying, or is
>in agreement with it.
Oops, sorry for my ambiguity.
I'm disagreeing with what you were saying.
The web page says it's OK for a language to allow debug logging.
You disagreed with the web page.
If I understand you correctly, you said that debug logs
are not OK because they can change thread timing and changing
thread timing can cause damage.
I am not convinced by that argument.
I believe that even if debug logs are prohibited, there are lots
of other things code can do that can change thread timing.
Therefore, I'm not convinced that the language needs to prohibit
debug logs. I think it's OK for languages to allow debug logs.
So I think the web page is right.
To give more context, the web page is addressing a particular
misconception about capability languages.
Misconception: "Capability languages are annoying to use because
they mark it hard to do debug logging: you have to pass a log object
around to every method that might ever want to write anything to
The web page says, "No, that is not correct. Capability languages
can safely provide facilities that make debug logging convenient."
Languages don't have to -- but language designers are free to include
this support, if they want to. Including that kind of support for
debug logs does not contradict capability principles.
So it's a mistake to say that debug logging is necessarily inconvenient
in capability languages; it ain't necessarily so.
You can have capability goodness, and have convenient logging, too.
Of course, you can also have a language that has capability goodness
but doesn't allow ambient logging. That's fine, too. If you prefer
that kind of language, more power to you. The point is just that
capability principles don't force everyone into that stance -- you
can choose between convenient logging or prohibiting ambient loggers,
according to your own personal preference, without running afoul of
(Sorry if I'm being repetitive and redundant. I realize it might
come off as aggressive; if so, that wasn't my intent. My only intent
is to try to avoid ambiguity.)
More information about the cap-talk