http://permalink.gmane.org/gmane.comp.capabilities.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.capabilities.general/14091 <pre> Oh yeah, I suppose it is. IIRC atomic::load() is just a load + compiler barrier on x86. Actually I'm not sure how this is any different from what you suggested, aside from being clearer and more portable. _______________________________________________ cap-talk mailing list cap-talk-r2jiIPW7MOYEUp5O9OQuKg&lt; at &gt;public.gmane.org http://www.eros-os.org/mailman/listinfo/cap-talk </pre> Kenton Varda 2013-05-15T19:25:39 http://permalink.gmane.org/gmane.comp.capabilities.general/14090 <pre>If there was an recording made of this seminar then would you or someone mind posting a link to it when it becomes aviable for those of us who couldnt go? On 14 May 2013 21:25, Karp, Alan H &lt;alan.karp-VXdhtT5mjnY&lt; at &gt;public.gmane.org&gt; wrote: </pre> Baldur Johannsson 2013-05-15T12:48:29 http://permalink.gmane.org/gmane.comp.capabilities.general/14089 <pre>For those of you not on the Stanford distribution list and those of you too busy to read announcements sent on it. ________________________ Alan Karp Principal Scientist Enterprise Services, Office of the CTO Hewlett-Packard Company 1501 Page Mill Road Palo Alto, CA 94304 (650) 857-3967, fax (650) 857-7029 http://www.hpl.hp.com/personal/Alan_Karp </pre> Karp, Alan H 2013-05-14T21:25:09 http://permalink.gmane.org/gmane.comp.capabilities.general/14088 <pre> On 2013 May 9, at 01:53 , Ben Laurie &lt;benl-hpIqsD4AKlfQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt; wrote: ... Thinking about this for a coupe of days, and following a short conversation with the FRIAM folks I came up with the "virtual snapshot" which is actually an old idea used in the Unix fork system call. See http://cap-lore.com/CapTheory/KK/CbMS.html . I include an order of magnitude cost estimate. </pre> Norman Hardy 2013-05-11T01:08:54 http://permalink.gmane.org/gmane.comp.capabilities.general/14087 <pre> I nearly posted this earlier - it seems particularly relevant now: http://seclists.org/bugtraq/2002/Jun/285. </pre> Ben Laurie 2013-05-09T09:07:02 http://permalink.gmane.org/gmane.comp.capabilities.general/14086 <pre> Interestingly, this is hard to do on the hardware we're building (which is a capability CPU). We've been vaguely musing about special capabilities that prevent going backwards in memory. It turns out this is nice for caching in multi-CPU systems. </pre> Ben Laurie 2013-05-09T08:53:35 http://permalink.gmane.org/gmane.comp.capabilities.general/14085 <pre> That would obviously be much slower that copying (and also requires that the receiver have write access to this memory, which has other complications). Imagine a field which stores the size of some buffer. Initially the attacker sets the size low. The receiver checks that the size is within some bound, then copies the buffer to a location on the stack. Except between the validation and the copy, the attacker replaces the size with a random value. A random integer is likely to be large. Buffer overrun. pwned. Under your proposal each receiver would need to use the same encryption key while still keeping it secret from the sender. These receivers would of course be able to interfere with each other. According to Wikipedia&lt;http://en.wikipedia.org/wiki/Advanced_Encryption_Standard&gt;: "On Intel i3/i5/i7 CPUs supporting AES-NI instruction set extensions, throughput can be over 700MiB/s per thread." Such CPUs have main memory bandwidth on the order of 20-40 GiB/s&lt;http://www.anandtech.com/show/5091</pre> Kenton Varda 2013-05-09T03:46:53 http://permalink.gmane.org/gmane.comp.capabilities.general/14084 <pre> Yes, but the particular application I have in mind is not intended to be portable. All of these apply regardless of whether the message is transmitted via shared memory or copying. I meant to ask about vulnerabilities specific to shared memory. Note that my requirement that the receiver read each location in memory only once means that if validation is required, it must be performed on a copy. The main thing I'm trying to avoid here is the need to copy large data buffers that otherwise require no validation. For example, say I'm implementing a wrapper around write() which restricts the destination of the write but allows any content to be written. Once I've validated the destination and the buffer pointer, I should be able to pass that buffer pointer directly to write() rather than first copy the buffer content into another location in my private address space. -Kenton _______________________________________________ cap-talk mailing list cap-talk-r2jiIPW7MOYEUp5O9OQuKg&lt; at &gt;public.gmane.org http://www.</pre> Kenton Varda 2013-05-08T23:00:34 http://permalink.gmane.org/gmane.comp.capabilities.general/14083 <pre> It does not. The inability to reclaim resource that is accounted to you is one of the singular failings of the UNIX design. Beyond that, however, there are cap systems that do not run on Linux to consider. Yes. Input must be validated, and offsets must be checked for bounds. Pointers in the payload may be intended to point to other parts of the payload, but may in fact point into random places in the receiver address space. That must be guarded against. Depending on the data structure, denial of service by means of cycles must be considered. My general sense is that the allowable "language" of data items that can be safely transmitted in this way is *very* limited. _______________________________________________ cap-talk mailing list cap-talk-r2jiIPW7MOYEUp5O9OQuKg&lt; at &gt;public.gmane.org http://www.eros-os.org/mailman/listinfo/cap-talk </pre> Jonathan S. Shapiro 2013-05-08T22:41:09 http://permalink.gmane.org/gmane.comp.capabilities.general/14082 <pre> For this topic, I only care about Linux/x86. :) (I certainly wouldn't make the capnproto core library depend on this kind of feature -- it doesn't even require enabling exceptions in the first place.) _______________________________________________ cap-talk mailing list cap-talk-r2jiIPW7MOYEUp5O9OQuKg&lt; at &gt;public.gmane.org http://www.eros-os.org/mailman/listinfo/cap-talk </pre> Kenton Varda 2013-05-08T22:20:22 http://permalink.gmane.org/gmane.comp.capabilities.general/14081 <pre> Fun fact I just discovered: GCC's -fnon-call-exceptions will in fact allow you to throw a C++ exception from a SIGBUS signal handler (as well as SIGSEGV, SIGFPE, and anything else that the thread brings upon itself by doing something illegal, as opposed to signals sent from other threads/processes). _______________________________________________ cap-talk mailing list cap-talk-r2jiIPW7MOYEUp5O9OQuKg&lt; at &gt;public.gmane.org http://www.eros-os.org/mailman/listinfo/cap-talk </pre> Kenton Varda 2013-05-08T21:25:20 http://permalink.gmane.org/gmane.comp.capabilities.general/14080 <pre> The persistance and messaging mechanisms used in Waterken are an interesting variant on the Eros/KeyKOS model. If you haven't looked at them I recommend a glance. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Since the IBM Selectric, keyboards have gotten 408-356-8506 | steadily worse. Now we have touchscreen keyboards. www.pwpconsult.com | Can we make something even worse? </pre> Bill Frantz 2013-05-08T21:16:01 http://permalink.gmane.org/gmane.comp.capabilities.general/14079 <pre>Many good replies to my previous mail. Thanks. Here is a different approach which I think Keykos could not do. Nor in Linux but it imaginable kernels. Linear Janus, I hear tell, supported unduplicable references that the holder could sense as unduplicable. In this case the reader knows no one else has the capability. The reader returns the cap when done. If the reader looses the cap then the sender must do something unusual and perhaps difficult to recover. I have been playing with these ideas here but there are still problems: http://cap-lore.com/Hardware/BudCap/BudCap.html http://cap-lore.com/Hardware/BudCap On 2013 May 1, at 07:42 , Ben Laurie &lt;benl-hpIqsD4AKlfQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt; wrote: </pre> Norman Hardy 2013-05-08T21:11:05 http://permalink.gmane.org/gmane.comp.capabilities.general/14078 <pre> Hmm, yes, it looks like this is indeed an issue. Thanks. You could handle it by remapping the memory to something else (say, /dev/zero) in the SIGBUS handler, and then setting a flag to cease handling requests from that sender. That said, it happens that in my particular use case, the receiving process is serving no other purpose than acting as a communications proxy for the sending process. If the sender causes the receiver to crash, they have only managed to cut off their access to the world. I'm more concerned with code execution exploits... This is a great point. I could stick a barrier like you suggest into the spot that handles endianness conversion. I wonder what the performance impact would be in general. It could be a compile-time option, since only things like my rather-unusual use case would want it. _______________________________________________ cap-talk mailing list cap-talk-r2jiIPW7MOYEUp5O9OQuKg&lt; at &gt;public.gmane.org http://www.eros-os.org/mailman/listinfo/cap-talk </pre> Kenton Varda 2013-05-08T20:04:04 http://permalink.gmane.org/gmane.comp.capabilities.general/14077 <pre>Channels! How can I resist?! Chip's return path observation is important because the return path has the two curiosities that 1) I can provide a capability to but not invoke the (typical) return path, and 2) it's use once. Both properties are valuable; KeyKos et al made great use of the use-once property of return keys, E, etc. leverage the "resolve-once" nature of promises, etc. The use-once is fundamentally the "arbiter" from actors (and the choose operation in Joule). An aside for clarity in the next paragraph: a general Joule channel is a multi-cast message stream, where the "acceptor" corresponds to a promise and distributor corresponds to the resolver (with the difference that it can be resolved and thereby multicasts to more than one target). (The acceptor and distributor are two facets of the channel, and are therefore different capabilities.) Joule is straddling the fence here: in the semantic kernel Joule, "return" was achieved by passing the distributor (i.e., the resolver) of the channel as </pre> Dean Tribble 2013-05-08T18:34:53 http://permalink.gmane.org/gmane.comp.capabilities.general/14076 <pre> Correct me if I'm wrong, but I don't think Linux allows you to "revoke" shared memory already mapped in another process. Given that, are you aware of any other risk for a receiving process that is careful to only read the memory once? _______________________________________________ cap-talk mailing list cap-talk-r2jiIPW7MOYEUp5O9OQuKg&lt; at &gt;public.gmane.org http://www.eros-os.org/mailman/listinfo/cap-talk </pre> Kenton Varda 2013-05-08T18:24:11 http://permalink.gmane.org/gmane.comp.capabilities.general/14075 <pre> So following my note of a few minutes ago I went back to look at the specification and the code. Matters in Coyotos are more complex then I had remembered, and I'm no longer sure that the packaging is more general. The reasons *why* might be of interest. KeyKOS and EROS lacked any explicit manifestation of the entry wait queue as a kernel object. One consequence was that no efficient mechanism for choosing one of several receiver threads of control to dispatch existed. Before Bill jumps in, I assert that for both efficiency and scheduling reasons this selection *must, of necessity* happen in the kernel. As a matter of implementation, you need a kernel-visible and capability-named queue object of some sort. Thus the Endpoint object was born. I then waffled on the implementation, because kernel receiver dispatch and orthogonal persistence in the style of KeyKOS/EROS *really* don't get along. Speaking years later, I now think that orthogonal persistence needs to be abandoned for concurrency reasons, but I h</pre> Jonathan S. Shapiro 2013-05-08T18:05:24 http://permalink.gmane.org/gmane.comp.capabilities.general/14074 <pre> temporarily assuring that there is no write access to the shared memory while the reader reads. Not efficiently, and less so as memory subsystems continue to evolve. We did some work on safe use of unprotected shared memory in the EROS Window System and user mode net stacks. It's practical use is very limited, and I would strongly discourage it as a pattern for general software written by anyone who is not thoroughly paranoid. In addition to the hazards of altered data, there is an exception hazard from revocation. The user code can't resolve that without being deeply in bed with the low level OS *and* language runtime. The only clean resolution is to copy, and if you are willing to do that, why look at this pattern at all? The only justification I can see for shared memory in the presence of asymmetric trust is where zero copy solutions are mandated, and those are exceptionally hard to implement even when hardware cooperates. ARM hardware, which is a critical target, is *especially* unfriendly to safes </pre> Jonathan S. Shapiro 2013-05-08T16:33:00 http://permalink.gmane.org/gmane.comp.capabilities.general/14073 <pre> On 2013 May 1, at 07:42 , Ben Laurie &lt;benl-hpIqsD4AKlfQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt; wrote: True, but this can be fixed by some combination of kernel and hardware by temporarily assuring that there is no write access to the shared memory while the reader reads. This exposes the issue of the reader finishing the reading promptly, but that must always be addressed. The platform may do a copy on write if the writer can not afford to wait on the reader. This could have been on top of Keykos but it would usually have been too costly. </pre> Norman Hardy 2013-05-08T16:02:28 http://permalink.gmane.org/gmane.comp.capabilities.general/14072 <pre>Joule and E get the "use once" property you mention in essentially the same way (as inspired by concurrent logic programming btw): The requestor continues immediately after making the request with a channel/promise/logic-variable for the result. As with the KeyKOS fork, the requestor's control flow simply continues and is not dependent on the requestee, so there is no direct multiple-return hazard. In addition, E promises and concurrent logic programming logic variables are instantiate-once, so when turning dataflow back into control flow (e.g., with the E "when"), this instantiation only triggers one control flow path per when-expression. Joule channels by contrast are multiply instantiable, which provides a primitive multicast ability. But the common Joule way to turn dataflow back into control flow would also race to react only to the first of these instantiated values. Cheers --MarkM On May 8, 2013, at 6:56 AM, "Jonathan S. Shapiro" &lt;shap-UnG0+qphKChAfugRpC6u6w&lt; at &gt;public.gmane.org&gt; wrote: _________</pre> Mark Miller 2013-05-08T15:25:14 http://permalink.gmane.org/gmane.comp.capabilities.general/14071 <pre> That's good to hear (also the implication that his work has been mechanised </pre> Toby Murray 2013-05-08T14:25:29 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.capabilities.general