Re: [friam] Representing tag bits in partitioned hardware cap systems
"Robert N. M. Watson" <[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <[email protected]> |
> On 31 Dec 2014, at 16:16, Carl Hewitt <[email protected]> wrote: > > I agree with Ben: > Cute idea, but I find it impossible to believe that the complexity + > the overhead for the false hit table + worst case behavior gives any > advantage over the tagging scheme. > > We need to bite the bullet and tag every word in the RAM and in the cache. > This could be combined with the next generation of RAM error correction :-) > > Unfortunatley, the default capability register [CR0] in CHERI is another hack that we don’t need :-( At least from our perspective, it’s a feature you want to not have to want, but end up accepting as a feature you do in fact want in the interests of getting from A to B. As a result of capability-register zero and some other related ideas (e.g., maintaining a general-purpose MMU alongside the capability-system model, blending ideas from fat pointers with capabilities), I get to have a working FGPA-based capability system running UNIX on my desk today, letting me push capability-system features into libraries and applications incrementally rather than having to design the entire software corpus from scratch. And it’s not that I don’t also want a from-scratch corpus designed with capabilities in mind .. it’s just that I can’t write it all at once and need to get work done in the mean time. But tell me it’s not neat that I can run a version of tcpdump that encapsulates processing of different flows and protocol layers within object capabilities… :-) Robert _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk