From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a05:6214:627:: with SMTP id a7mr5976492qvx.13.1634224591033; Thu, 14 Oct 2021 08:16:31 -0700 (PDT) X-Received: by 2002:a25:1dd7:: with SMTP id d206mr6991654ybd.486.1634224590769; Thu, 14 Oct 2021 08:16:30 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 14 Oct 2021 08:16:30 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=146.5.2.231; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 146.5.2.231 References: <07f8mgdot9tmh8mqen2ogd5dds2gojoleh@4ax.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <2c73d584-81a4-47ce-b86a-0ff8bdd776b9n@googlegroups.com> Subject: Re: The Ravenscar profile and capabilities paradigm From: Shark8 Injection-Date: Thu, 14 Oct 2021 15:16:31 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:63000 List-Id: On Wednesday, October 13, 2021 at 9:46:34 PM UTC-6, Doctor Who wrote: > On Tue, 12 Oct 2021 08:01:26 -0700 (PDT), Shark8=20 > >On Monday, October 11, 2021 at 1:24:48 PM UTC-6, Doctor Who wrote:=20 > >> On Mon, 11 Oct 2021 16:32:13 +0100, Simon Wright wrote:=20 > >> >Doctor Who writes:=20 > >> >=20 > >> >> someone knows how to introduce the capabilities paradigm in Ada,=20 > >> >> specifically for programs written using the Ravenscar profile ?=20 > >> >=20 > >> >Google hasn't helped me to understand what you're getting at. Perhaps= =20 > >> >you could expand?=20 > >> wikipedia has a good explanation:=20 > >> https://en.wikipedia.org/wiki/Capability-based_security=20 > >Ah.=20 > >Limited Private, unknown-discriminant types.=20 > >=20 > >Package Capabilities is=20 > > -- Enumeration of the particular capabilities.=20 > > Type Capability is ( Read, Copy, Whatever );=20 > > -- A Boolean set for delineating a set of Capabilities.=20 > > Type Capability_List is Array(Capability) of Boolean;=20 > > -- An instance of a set of capabilities; note that:=20 > > -- (1) LIMITED means there is no predefined assignment/copy.=20 > > -- (2) PRIVATE means there is no public view to the components.=20 > > -- (3) Unknown discriminants mean there is no object-creation w/o a fun= ction-call.=20 > > Type Instance(<>) is limited private;=20 > > -- Create an instance; add any other needed parameters.=20 > > Function Create( Capabilities : Capability_List ) return Instance;=20 > > -- No permissions.=20 > > Function No_Permissions return Instance;=20 > >Private=20 > > Type Instance is record=20 > > Permissions : Capability_List:=3D (raise Program_Error with "Capabiliti= es-Instance must be initialized.");=20 > > -- (others =3D> False); -- Or maybe default to no permissions.=20 > > -- OTHER DATA, IF NEEDED; PERHAPS TASK-/PROCESS-ID.=20 > > End record;=20 > >=20 > > Function Create( Capabilities : Capability_List ) return Instance is=20 > > ( Permissions =3D> Capabilities );=20 > > Function No_Permissions return Instance is=20 > > ( Create( Capability_List'(others =3D> False) ) );=20 > >End Capabilities;=20 > >=20 > >You could also extend things with a Task-ID, assuming you want this prev= alent/pervasive across the OS, you could make a TASK INTERFACE with an acce= ssor (Function Get_Capabilities(Task : OS_Task_Interface) return Capabiliti= es.Instance is (Capabilities.No_Permissions); -- Override to give permissio= ns.) and/or possibly a registry to manage permissions (on a finer-grained l= evel) if you need it. A lot depends on how you architect/model it, but the = "limited private unknown-discriminant type" perfectly fits what you need at= the fundamental levels. > a Process Capability looks like this:=20 >=20 > Operations:=20 > a. "Read", address; > data;=20 > b. "Write", address, data; > ;=20 > c. "Take", index; > ; capability=20 > d. "Give", index; capability > ;=20 > e. "Find", index, count; capability > result, index;=20 > f. "Start"; > ;=20 > g. "Stop"; > ;=20 Does it? Why? Or is this just one possible implementation of 'capabilities' operations? Operations on a type correspond to subprograms in Ada; nothing you present = seems (at first glance) incompatible with the structure/types I gave you. >=20 > Semantics: The "Read" and "Write" operations allow access to the=20 > process's memory. For example, in the "Read" operation, the literal=20 > string "Read" (or a recognizable OP code) is passed along with an=20 > address. The data word at the address is returned.=20 I think you're jumping the gun. You need to have a good model, and why are you jumping straight into implem= entation? (Literal string? Recognizable OP code? -- All implementation details; forge= t them right now, concentrate on the modeling of the problem, not the detai= ls of how to implement, and AFTER getting the model down, THEN consider cod= e.) > The "Give" and "Take" operations allow access to the process's C-list.=20 > For example, the "Give" operation passes the string "Give", an index=20 > into the C-list, and a capability to be stored at the passed index.=20 > Such a stored capability could be invoked by the process if it were=20 > "Start"ed.=20 This part of your explanation makes it sound like you do not understand the= code I presented, or the reasoning behind it; forgive me for poorly commun= icating it. The reason you want a "limited private type with unknown discriminants" is = because: 1) It hides the implementation, meaning clients cannot alter it indiscrimi= nately. 2) It prohibits automatic initialization, forcing the usage of an initiali= zation subprogram. 3) It forces usage of the public interface for clients, private details ca= n manipulate it though. 4) Any public operations, again, have to go through the public interface. 5) Copying is strictly prohibited, hence "limited". In the model I had envisioned the Capabilities-list (Capabilities.Instance)= would be an integral part of the TASK, and there would likely be a Get_Cap= abilities function which would return the proper value, some set-operations= , and a new creation-function: Function Create( Object : OS_Task_Interface; Capabilities : Capability_Li= st ) return Instance is Parent : Instance renames Get_Capabilities( Object ); Caps : Capability_List renames Parent.Permissions; Begin Return Intersect( Caps, Capabilities ); -- The granted capabilities ca= nnot be ones the parent does not have, nor may it be ones not requested. End Create; The above, I think, does the work you are putting into TAKE and GIVE. > The "Find" operation allows a slightly optimized sort of compare=20 > operation for capabilities. The process's C-list is searched, starting=20 > at the passed index, for the passed capability until either:=20 >=20 > 1. The passed capability is found in the C-list. In this case, the=20 > operation returns "Yes" and the first index where the capability was=20 > found, or=20 >=20 > 2. The count is exhausted. In this case the operation returns "No" and=20 > the passed index plus count. Why are you bothering with a list? Why are you even bothering with an index? The implementation I gave you has the capabilities enumerated; you would ad= d an operation to the capabilities package: Function Has( Object : Instance; Permission : Capability) return Boolean is Begin Return Object.Permissions( Permission ); -- Just use the enumeration-ind= ex of the permissions field. End Has; Done. >=20 >=20 > in addition there is a Nil Capability:=20 > Nil Capability: When a process is initially created its C-list=20 > contains only Nils. These are empty place holders. Nil always returns=20 > "Empty". This... sounds like you are not understanding, at all, the Ada code I prese= nted you. Look at the creation function No_Permissions.