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 autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Doctor Who Newsgroups: comp.lang.ada Subject: Re: The Ravenscar profile and capabilities paradigm Date: Thu, 14 Oct 2021 18:38:16 +0200 Organization: A noiseless patient Spider Message-ID: References: <07f8mgdot9tmh8mqen2ogd5dds2gojoleh@4ax.com> <2c73d584-81a4-47ce-b86a-0ff8bdd776b9n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: reader02.eternal-september.org; posting-host="9d6f07ceea5260769296cea618469afe"; logging-data="5089"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18VN3EcrBGVPVkgKcgesaXO" User-Agent: ForteAgent/8.00.32.1272 Cancel-Lock: sha1:nVinteYEauL2jt47MySE7F9eUeE= Xref: reader02.eternal-september.org comp.lang.ada:63001 List-Id: On Thu, 14 Oct 2021 08:16:30 -0700 (PDT), Shark8 wrote: >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 >> >On Monday, October 11, 2021 at 1:24:48 PM UTC-6, Doctor Who wrote: >> >> On Mon, 11 Oct 2021 16:32:13 +0100, Simon Wright wrote: >> >> >Doctor Who writes: >> >> > >> >> >> someone knows how to introduce the capabilities paradigm in Ada, >> >> >> specifically for programs written using the Ravenscar profile ? >> >> > >> >> >Google hasn't helped me to understand what you're getting at. Perhaps >> >> >you could expand? >> >> wikipedia has a good explanation: >> >> https://en.wikipedia.org/wiki/Capability-based_security >> >Ah. >> >Limited Private, unknown-discriminant types. >> > >> >Package Capabilities is >> > -- Enumeration of the particular capabilities. >> > Type Capability is ( Read, Copy, Whatever ); >> > -- A Boolean set for delineating a set of Capabilities. >> > Type Capability_List is Array(Capability) of Boolean; >> > -- An instance of a set of capabilities; note that: >> > -- (1) LIMITED means there is no predefined assignment/copy. >> > -- (2) PRIVATE means there is no public view to the components. >> > -- (3) Unknown discriminants mean there is no object-creation w/o a function-call. >> > Type Instance(<>) is limited private; >> > -- Create an instance; add any other needed parameters. >> > Function Create( Capabilities : Capability_List ) return Instance; >> > -- No permissions. >> > Function No_Permissions return Instance; >> >Private >> > Type Instance is record >> > Permissions : Capability_List:= (raise Program_Error with "Capabilities-Instance must be initialized."); >> > -- (others => False); -- Or maybe default to no permissions. >> > -- OTHER DATA, IF NEEDED; PERHAPS TASK-/PROCESS-ID. >> > End record; >> > >> > Function Create( Capabilities : Capability_List ) return Instance is >> > ( Permissions => Capabilities ); >> > Function No_Permissions return Instance is >> > ( Create( Capability_List'(others => False) ) ); >> >End Capabilities; >> > >> >You could also extend things with a Task-ID, assuming you want this prevalent/pervasive across the OS, you could make a TASK INTERFACE with an accessor (Function Get_Capabilities(Task : OS_Task_Interface) return Capabilities.Instance is (Capabilities.No_Permissions); -- Override to give permissions.) and/or possibly a registry to manage permissions (on a finer-grained level) 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: >> >> Operations: >> a. "Read", address; > data; >> b. "Write", address, data; > ; >> c. "Take", index; > ; capability >> d. "Give", index; capability > ; >> e. "Find", index, count; capability > result, index; >> f. "Start"; > ; >> g. "Stop"; > ; >Does it? >Why? >Or is this just one possible implementation of 'capabilities' operations? it is the one I would like to implement. >Operations on a type correspond to subprograms in Ada; nothing you present seems (at first glance) incompatible with the structure/types I gave you. exactly >> >> Semantics: The "Read" and "Write" operations allow access to the >> process's memory. For example, in the "Read" operation, the literal >> string "Read" (or a recognizable OP code) is passed along with an >> address. The data word at the address is returned. >I think you're jumping the gun. >You need to have a good model, and why are you jumping straight into implementation? http://www.webstart.com/jed/papers/DCCS/ >(Literal string? Recognizable OP code? -- All implementation details; forget them right now, concentrate on the modeling of the problem, not the details of how to implement, and AFTER getting the model down, THEN consider code.) >> The "Give" and "Take" operations allow access to the process's C-list. >> For example, the "Give" operation passes the string "Give", an index >> into the C-list, and a capability to be stored at the passed index. >> Such a stored capability could be invoked by the process if it were >> "Start"ed. >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 communicating it. >The reason you want a "limited private type with unknown discriminants" is because: >1) It hides the implementation, meaning clients cannot alter it indiscriminately. >2) It prohibits automatic initialization, forcing the usage of an initialization subprogram. >3) It forces usage of the public interface for clients, private details can 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_Capabilities function which would return the proper value, some set-operations, and a new creation-function: > Function Create( Object : OS_Task_Interface; Capabilities : Capability_List ) return Instance is > Parent : Instance renames Get_Capabilities( Object ); > Caps : Capability_List renames Parent.Permissions; > Begin > Return Intersect( Caps, Capabilities ); -- The granted capabilities cannot 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 >> operation for capabilities. The process's C-list is searched, starting >> at the passed index, for the passed capability until either: >> >> 1. The passed capability is found in the C-list. In this case, the >> operation returns "Yes" and the first index where the capability was >> found, or >> >> 2. The count is exhausted. In this case the operation returns "No" and >> 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 add an operation to the capabilities package: >Function Has( Object : Instance; Permission : Capability) return Boolean is >Begin > Return Object.Permissions( Permission ); -- Just use the enumeration-index of the permissions field. >End Has; >Done. >> >> >> in addition there is a Nil Capability: >> Nil Capability: When a process is initially created its C-list >> contains only Nils. These are empty place holders. Nil always returns >> "Empty". >This... sounds like you are not understanding, at all, the Ada code I presented you. >Look at the creation function No_Permissions.