Secure System Specification

1. Secure System Specification

2. Introduction • Goal: Describe the motivation behind and Definition of the Rosetta systems level design language • Dr. Perry Alexander • Chair, Accellera Rosetta Standards Committee • Chair, IEEE Engineering of Computer-Based Systems Technical Committee • Member, GSRC/Accellera Semantics Standards Committee • Chief Architect, VSPEC, ActiveSPEC and Co-Architect Rosetta design languages • RASSP, CEENSS, POMTT, SLDL, MoBIES PI or Co-PI ITTC IRB

3. What is Systems Level Design? • Designing at high levels of abstraction • Moving above implementation languages • Using abstract models of computation specific to domains • Concurrently considering multiple system perspectives • Functional correctness – correctness, liveness, • Performance constraints – security, safety, energy usage • Physical constraints – size, weight, portability • Integrating components from multiple domains • Software • Digital and Analog Hardware • Optical and MEMS ITTC IRB

4. Security and Reliability are Systems Problems • Constraints on Systems • Not functional properties • Cannot “test in” • Cross-Cutting Impacts • Secure Components ≠ Secure Systems • Emergent problems • Local decisions impact system performance • Heterogeneity of Information • Different kinds of components • Different modeling semantics for different issues ITTC IRB

5. Domains and Models of Computation With Domains and MoC, the design can be expressed in the semantics of the system concept and synthesized onto specific technology Design System Concept Implementation Technology Synthesis ITTC IRB

6. Multiple Models of Computation P=10uW+5uW+... Architecture x of CPU is begin x <= fir(y); wait for x’event end x; X <= F(y) after 5us Power Function Timing Cost Security ITTC IRB

7. Systems Level Design Language Properties • Support for integrating domain specific specifications • Composition of models of computation that describe systems and components • Composition of systems and components defined using different models of computation • Representation and integration of constraint information • Support for more abstract modeling • Moving up from implementation languages • Support for domain specific specification • Support for predictive analysis and verification • Within specific domains • Across multiple domains • Formal semantics is a must ITTC IRB

8. Interaction Component Component System Interaction Component Facet Facet Facet Facet Facet Facet Facet Facet Facet Facet Domain Domain Domain Domain Domain Domain Domain Anatomy of a specification Domain ITTC IRB

9. Language Semantics • Type System • Set theoretic – Traditional set theoretic type definitions • Constructed types – Similar to Haskell and PVS • Types are first-class items – Any set or set valued item can be a type • Functions • Pure functional – No side effects • No referential transparency – Closures • Based on typed lambda calculus and Haskell – Lazy evaluation with strong typing • Reflection • Specification constructs are Rosetta items • Specification constructs have values in the Rosetta value space ITTC IRB

10. Facet Definition • Facets provide parameterized mechanisms for defining models and grouping definitions Domain Facet Name Parameter List facet trigger(x::input real; y::output bit; d::design real)::continuous is s::bit; begin t1: s’ == if s=1 then if x>=0.4 then 0 else 1 end if else if x=<0.7 then 1 else 0 end if end if; t2: y@(t+d) == s; end trigger; Variables Terms ITTC IRB

11. Facet Semantics • Semantic elements • Signature – Parameters and declarations • Terms – Traditional terms and type constraints • Domain – Theory extended to define model • Semantic definition • Co-algebraic structure – Closure with respect to equational logic (B. Jacobs) • Define observations over a “hidden” internal state • Correctness – Logical consistency • Facet items • Packages – Facets containing only declarations • Domains – Facets used for domain definition • Components – Standard facet definition capability • Interactions – Packages defining functors between domains ITTC IRB

12. What’s in a Domain? • Domains represent vocabularies for specification • Semantic Units • Models of Computation • Specification Vocabulary • Hierarchy formed by extending existing domains • Domains are used as a basis for defining other domains • Morphisms define compatibility characteristics between domains • Functors between domains • Define how information from one domain translates into information in another • Simple functions defined over domain types ITTC IRB

13. state-based signal-based continuous discrete continuous-time discrete-time frequency finite-state RF digital sequential-machine Domain Semi-Lattice static Unit of Semantics CSP trace-based Model of Computation Engineering Modeling synchronous ITTC IRB

14. Domain Interactions static state-based signal-based Extensions continuous discrete CSP trace-based Homomorphisms continuous-time discrete-time Regular Morphisms frequency finite-state RF digital sequential-machine synchronous ITTC IRB

15. Domain Interactions static security state-based continuous discrete discrete-security disc-time-security continuous-time discrete-time frequency finite-state FS-security Proposed In NSF ITR SM-security RF digital sequential-machine ITTC IRB

16. Domain Specification domain state-based::logic is S::type; next(x::S)::S; begin end domain state-based; domain discrete::state-based is begin S=natural; end domain discrete; domain security::state-based is riskType::type=posreal; p,nominal::riskType; activityType::subtype(real)= sel(x::real | x>=0.0 and x=<1.0); activity::activityType begin p’=activity*nominal+latent; end domain security; domain discrete-security :: security and discrete is begin … end domain discrete-security; ITTC IRB

17. Facet Composition • Facet composition supports combining models to describe systems • Vertical composition – Multiple models of the same component • Horizontal composition – Structural modeling • The facet algebra defines composition and relational operations • Facet sum and product define vertical composition operations • Facet implication defines homomorphism relation • Projections and Functors move information • Instantiating and renaming facets defines structural composition • Including facets in other facets instantiates models • Shared variables in interfaces define basic communication ITTC IRB

18. Product: f::D is f1 * f2 Sum: f::D is f1 + f2 Implication f1 => f2 Projection Functions Proj(f::D)::set(terms) Aggregation: c1: f1(a,b); c2: f2(b,c); Equivalence: f1=f2  f1=>f2 and f1<=f2 Functors F(f::D1)::D2; Facet Algebra – Operations on Models ITTC IRB

19. Example Facet Sum • Facet access_policy defines access restrictions on available resources • Facet software_fcn defines the actual function performed by the software component • A processor component is concurrently described by both software_fcn and access_polidy facet access_policy(acl::design set(access); violation::output boolean)::discrete is begin … end facet access_policy; facet software_fcn(i::input posreal; o::output posreal)::software is begin … end facet software_fcn; processor::facet is software_fcn + access_policy; ITTC IRB

20. Facet Sum Semantics • A facet, F + G, is the co-product of individual facets: • A homomorphism exists from each original facet to the conjunction • The resulting model must exhibit properties of both facets • Defines heterogeneous models of the same component • Provides source for generating analysis models • Adding a constraint defines correctness: access_policy software_fcn G F access_policy + software_fcn access_policy + software_fcn + security_constraint ITTC IRB

21. Each facet is denoted as a co-algebra in the Rosetta value space by  Elaboration by  results in an interpreter in the space Denotation and elaboration functions are generated automatically from the functor or extension defined between D and D’ Reflection allows functors to be written directly in Rosetta Define new functors for new applications Analyzing Rosetta Specifications D  denotation  elaboration F functor Facet Co-algebra d, p, f : S where f; d Elaborated Facet (-language) D’ Facet Co-algebra d, p, f : S where f; d Elaborated Facet (-language) ITTC IRB

22. Interpreting a λ-Language • Monads and Interpreters • Domains are associated with modads that define computations within that domain • Operational monads provide a language interpretation capability • Composing Interpreters • Semantic elements are added to interpreters by composing monads (Liang and Hudak) • Exactly how domains are extended in the domain semi-lattice • Interpreting Facets • Extend the monad as the domain is extended to generate an interpreter for a declared facet • Compose monads as the facets are composed to generate an interpreter for a derived facet (very hard) • Compose monads and project into interpreters to generate specialized interpreters for aspects of a derived facet (not as hard) ITTC IRB

23. Use pushout to define the coproduct in the specification domain Use functors to generate executable models of individual domain models Use functors to generate composed executable model Use functors to generate custom analysis models Using Facet Composition discrete software_fcn access_policy software_fcn+access_policy λ _access_policy λ_software_fcn λ_(software_fcn+ access_policy) λ _access_policy λ_software_fcn ITTC IRB

24. System / Security Interaction • Facets represent software function and security policy • Functors map information between domains • Interaction from security to system adds terms estimating security properties • Interaction from system to security adds assertions describing system function • Facet sum composes functional and security models • Analysis considers impacts of Interaction • As functional model is refined to implementation, so is security policy • Other considerations in other facets • Discover emergent behaviors • Examine intellectually distant interactions ITTC IRB

25. Ongoing Work • Semantics for Domains – NSF, Accellera • Identification of basic domain set • Identification of basic semantic units • Semantic support for domain representation • Semantic support for MoC integration and interaction • Vocabulary for engineering domain specific specification domains • Predictive analysis • Simulation and emulation – NSF, NASA, DARPA • Static and formal analysis activities –NASA • Design flows including SLDLs – Accellera • Define where and when SLDLs play a role in systems design flows • Define and implement integrated SLDL tool support ITTC IRB

26. Future Activities • October 2003 – Initial standard release (tent.) • DAC 2003 –Rosetta BofF session • December 2003 – Alexander, Ashenden and Barton, The Rosetta User’s Guide, Morgan Kaufmann Publishers • Planning initiated for workshops • IEEE MoC/Rosetta Workshop, Fall 2003 aligned with EMSOFT • Rosetta Workshop at KU immediately following DAC • For more information • Rosetta – http://www.sldl.org • Accellera – http://www.accellera.org, http://www.eda.org • Standards Activities – Email to alex@eda.org ITTC IRB