From 9d5f2b80d2fce155d62db75070fae6d9794eab0a Mon Sep 17 00:00:00 2001 From: Paul Wortman Date: Mon, 6 Jul 2015 15:03:00 -0400 Subject: [PATCH] Push of more edits Signed-off-by: Paul Wortman --- PBDSecPaper.tex | 47 +++++++++++++++++++++++++++++++---------------- 1 file changed, 31 insertions(+), 16 deletions(-) diff --git a/PBDSecPaper.tex b/PBDSecPaper.tex index c6a36b1..d52dc7b 100644 --- a/PBDSecPaper.tex +++ b/PBDSecPaper.tex @@ -188,38 +188,32 @@ \section{Platford-based design} \item Set of tools that insulate the details of architecture from application software \item \textbf{Note Bene:} The more abstract the programmer's model, the richer is the set of platform instances, but the more difficult is to choose the ``optimal'' architecture platform instance and map automatically into it.~\cite{Vincentelli2002} \end{itemize} - \item ``In PBD, the partitioning of the design into hardware and software is not the essence of system design as many think, tather it is a consequence of decisions taken at a higher level of abstraction.''~\cite{Vincentelli2007} + \item ``In PBD, the partitioning of the design into hardware and software is not the essence of system design as many think, rather it is a consequence of decisions taken at a higher level of abstraction.''~\cite{Vincentelli2007} \begin{itemize} + \item The types of decisions that are made at these higher levels lend to the design traits that are requirements at lower levels. For example, a lower level consideration may be heat dissipation concerns which manifests itself as size constraints at higher levels. This sort of complexities in cost of design are exactly why abstraction/virtualization are required/desired. Additional levels of abstraction (along with virtualization tools for design space exploration) aid in simplifying the design process. \item ``Critical decisions are about the architecture of the system, e.g., processors, buses, hardware accelerators, and memories, that will carry on the computation and communication tasks associated with the overall specification of the design.''~\cite{Vincentelli2007} \end{itemize} - \item ``In the PBD refinement-based design process, platforms should be defined to eliminate large loop iterations for affordable designs.''~\cite{Vincentelli2007} - \begin{itemize} - \item ``The should restrict the design space via new forms of regularity and structure that surrender some design potential for lower cost and first-pass sucess. The library of functional and communication components is the design space that we are allowed to explore at the appropriate level of abstraction.''~\cite{Vincentelli2007} - \end{itemize} - \item ``Establishing the number, location, and components of intermediate ``platforms'' is the essence of PBD.''~\cite{Vincentelli2007} - \begin{itemize} - \item ``In fact, designs with different requirements and specification may use different intermediate platforms, hence different layers of regularity and design-space constraints. The tradeoffs involved in the selection of the number and characteristics of platforms relate to the size of the design space to be explored and the accuracy of the estimation of the chracteristics of the solution adopted. Naturally, the larger the step across platforms, the more difficult is predicting performance, optimizing at the higher levels of abstraction, and providing a tight lower bound. In fact, the design space for this approach may actually be smaller than the one obtained with smaller steps because it becomes harder to explore meaningful design alternatives and the restriction on search impedes complete design-space exploration. Ultimately, predictions/abstractions may be so inaccurate that design optimizations are misguided and the lower bounds are incorrect.''~\cite{Vincentelli2007} - \end{itemize} + \item There are elements of recursive behavior that need to be tackled from a virtualized tool standpoint. In a PBD refinement-based design process, platforms shoould be defined to eliminate large loop iterations for affordable designs~\cite{Vincentelli2007}. This refinement should restrict the design space via new forms of regularity and structure that surrender some design potential for lower cost and first-pass sucess. The library of functional and communication components is the design space that we are allowed to explore at the appropriate level of abstraction~\cite{Vincentelli2007}. + \item Due to the recursive nature of platform-based design, establishing the number, location, and components of intermediate ``platforms'' is the essence of PBD~\cite{Vincentelli2007}. ``In fact, designs with different requirements and specification may use different intermediate platforms, hence different layers of regularity and design-space constraints. The tradeoffs involved in the selection of the number and characteristics of platforms relate to the size of the design space to be explored and the accuracy of the estimation of the chracteristics of the solution adopted. Naturally, the larger the step across platforms, the more difficult is predicting performance, optimizing at the higher levels of abstraction, and providing a tight lower bound. In fact, the design space for this approach may actually be smaller than the one obtained with smaller steps because it becomes harder to explore meaningful design alternatives and the restriction on search impedes complete design-space exploration. Ultimately, predictions/abstractions may be so inaccurate that design optimizations are misguided and the lower bounds are incorrect.''~\cite{Vincentelli2007} \item ``The identification of precisely defined layers where the mapping processes take place is an important design decision and should be agreed upon at the top design management level.''~\cite{Vincentelli2007} \begin{itemize} \item ``Each layer supports a design stage where the performance indexes that characterize the architectural components provide an opaque abstraction of lower layers that allows accurate performance estimations used to guide the mapping process.''~\cite{Vincentelli2007} \end{itemize} - \item ``This approach results in better reuse, because it decouples independent aspects, that would otherwise be tired, e.g., a given functional specification to low-level implementation details, or to a specific communication paradigm, or to a scheduling algorithm.''~\cite{Vincentelli2007} - \begin{itemize} - \item ``It is very important to define only as many aspects as needed at every level of abstraction, in the interest of flexibility and rapid design-space exploration.''~\cite{Vincentelli2007} - \end{itemize} + \item ``This approach results in better reuse, because it decouples independent aspects, that would otherwise be tired, e.g., a given functional specification to low-level implementation details, or to a specific communication paradigm, or to a scheduling algorithm.''~\cite{Vincentelli2007} Coupled with well developed software virtualization tools, this would allow for better exploration of initial design spaces but does come at a cost of a rigorous, documented, standardization. ``It is very important to define only as many aspects as needed at every level of abstraction, in the interest of flexibility and rapid design-space exploration.''~\cite{Vincentelli2007} The issue of platform-based design is not so much an over-engineering of design/development, but rather a need to strike a balance between all aspects of design; much like what already happens in hardware and software design. \end{itemize} \end{itemize} \section{Security} \label{Security} \begin{itemize} +\item Software: capabilities, speed, uniqueness + \begin{itemize} + \item + \end{itemize} \item Hardware: tolerance, capabilities, power distribution, signal lag, cross-talk \begin{itemize} - \item PUF? (Think layer above this) \item Trusted Computing Group (TCG) created Trusted Platform Modules (TPM) which are able to validate their own functionality and if they have been tampered with. This is, in essence, a method of `self-analysis'; thus the ground work for a `self-analyzing' security component is already in place. This self checking can be used as a method for allowing the larger system of security components to locate damaged/error-prone componenets so that they can be replaced/fixed thus raising the overall trustworthiness of the system of components. \end{itemize} -\item Software: capabilities, speed, uniqueness \item How to define ``trustworthiness''? \begin{itemize} \item Differentiate between trustworthy and dependable @@ -227,6 +221,11 @@ \section{Security} \begin{itemize} \item Arbitrary scale of trust; needs to be understandable/standardized \end{itemize} + \item ``In order to develop a component-based trustworthy system, the development process must be reuse-oriented, component-oriented, and must integrate formal languages and rigorous methods in all phases of system life-cycle.''~\cite{Mohammed2009} + \begin{itemize} + \item Component-Based Software Engineering (CBSE) is widely adopted in the software industry as the mainstream approach to software engineering~\cite{Mohammed2009}. + \end{itemize} + \item ``Most prevalent trust models only focus on assessing trustworthiness of systems at runtime, and do not provide necessary predictions of the trust of systems before they are built. This makes imporving trustworthiness of the composed system to be costly and time-consuming. Therefore it is important to consider trust of the composed software system at the development time itself.''~\cite{Gamage} \end{itemize} \item Scopes of security/trustworthiness \begin{itemize} @@ -234,7 +233,6 @@ \section{Security} \item Network (communication) \item Within distributed system \end{itemize} -\item Mapping of Security onto PBD structure \item Automation of security development \begin{itemize} \item Could have security elements that attempt to optimize themselves to the system they are in based on a few pivot points (power, time, efficiency, level of randomness?) @@ -242,6 +240,11 @@ \section{Security} \item Could trade out specific security components as an easier way to increase security without requireing re-design/re-construction of the underlying element. \end{itemize} \end{itemize} +\item Mapping of Security onto PBD structure + \begin{itemize} + \item ``Despite occasional cryptology-related attacks, most seucirty vulnerabilities result from poor software design and implementation, such as the ever-lasting buffer overrun bugs. Thus approaches to designing secure software, not just from a traditional cryptology viewpoint, but with a software engineering perspective, are needed to counter the current unsatisfactory situation.''~\cite{Ren2006} + \item ``...allows security concerns to be recognized early in the development process and can be given sufficient attention in subsequent stages. By controlling system security during architectural refinement, we can decrease software production costs and speed up the time to market. This approach aslo enchances the role of the software architects by requiring that their decisions be not only for functional decomposition, but also for [non-functional requirements] fulfillment.''`\cite{ZhouFoss2006} + \end{itemize} \end{itemize} \section{Conclusion} @@ -274,6 +277,18 @@ \section{Conclusion} \bibitem{Keutzer2000} Kurt Keutzer, Sharad Malik, A.~Richard Newton, Jan M.~Rabaey, and A.~Sangiovanni-Vincentelli, \emph{System-Level Design: Orthogonalization of Concerns and Platform-Based Design}, Computer-Aided Design of Integrated Circuits and Systems (Dec 2000) +\bibitem{Mohammed2009} Mubarak Sami Mohammad, +\emph{A Formal Component-Based Software Engineering Approach for Developing Trustworthy Systems}, Doctoral Dissertation (April 2009) + +\bibitem{Ren2006} Jie Ren, \emph{ +A Connector-Centric Approach to Architectural Access Control}, Dissertation (2006) + +\bibitem{ZhouFoss2006} Jie Zhou and Jim Alves-Foss, \emph{ +Architecture-Based Refinements for Secure Computer Systems Design}, Proceedings of the 2006 International Conference on Privacy, Security and Trust (2006) + +\bibitem{Gamage} Dimuthu U.~Gamage, Lahiru S.~Gallege, James H.~Hill, and Rajeev R.~Raje, +\emph{Trust of Composition of System Properties} + \end{thebibliography} \end{document}