Re: [friam] Representing tag bits in partitioned hardware cap systems

The CHERI capability model is designed to be (relatively easily) localised to specific RISC instruction sets. We prototyped against the 64-bit MIPS ISA because it was practical (and in particular because it supported 64 bits in 2010), but an adaptation to, say, ARMv8 or RISC-V would require careful thought yet fundamentally be able to reuse most of the conceptual approach -- and,  I suspect, be able to reuse most C-language level work. Adaptation to x86 would require more work, I think.

Sent from my iPad

> On 31 Dec 2014, at 16:39, Carl Hewitt <[email protected]> wrote:
> 
> Robert,
>  
> I agree that CHERI is a *very useful* pragmatic project.
>  
> However, a crucial task before us is to get tags implemented in ARM, X86, etc. so that we can
> increase endpoint security to defeat current mass surveillance and the increasing danger of preemptive massive cyberwar.
>  
> Please see the attached article.
>  
> Regards,
> Carl
>  
> PS.. Thanks to FriAM folks (plus anonymous others) for helping to debug the article :-)
> From: Robert N. M. Watson [mailto:[email protected]] 
> Sent: Wednesday, December 31, 2014 08:26
> To: Carl Hewitt
> Cc: friam-/[email protected]; General discussions concerning capability systems.; Zooko O'Whielacronx
> Subject: Re: [friam] Representing tag bits in partitioned hardware cap systems
>  
>  
> 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
> <What to Do About Our Broken Cyberspace.pdf>

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk