From 3966a3a4ccf983e3b046970c4db713ca9fb09866 Mon Sep 17 00:00:00 2001 From: Paul Wortman Date: Mon, 6 Jul 2015 07:49:10 -0400 Subject: [PATCH] Push of paper changes --- PBDSecPaper.tex | 73 +++++++++++++++++++++++++++++++++++++------------ 1 file changed, 55 insertions(+), 18 deletions(-) diff --git a/PBDSecPaper.tex b/PBDSecPaper.tex index 8f35824..c6a36b1 100644 --- a/PBDSecPaper.tex +++ b/PBDSecPaper.tex @@ -79,7 +79,10 @@ \begin{abstract} \begin{itemize} -\item PBD centers around minimzing the cost of development through a ``meet-in-the-middle'' methodology where successive refinements of specifications meet with abstractions of potential implementations. The goal being to obtain the same level of abstraction as is writtien into good coding functions.~\cite{Vincentelli2002} +\item PBD centers around minimizing costs of developing and manufacturering new components along with changing the landscape of this ecosystem, through the use of a ``meet-in-the-middle'' methodology where successive refinements of specificiations meet with abstractions of pototential implemenetations. + \begin{itemize} + \item The goal being to obtain the same level of abstraction as is writtien into good coding functions.~\cite{Vincentelli2002} + \end{itemize} \item Security centers around being able to gauge the trustworthiness of components as well as the larger system made of distributed components. \item Lack of design/methodology for doing platform-based design of security elements, although conceptual use in mobile embedded systems. \item Ground work for implementing security via PBD exists; this paper is centered around connecting the dots and laying the foundation for framework that will be built upon for creating security in a doucmented, rigorous, standardized way. @@ -89,13 +92,13 @@ \section{Previous Work} \label{Previous Work} \begin{itemize} -\item Middleware security (having translation software for communicating from lower level to a higher level) - \begin{itemize} - \item ``In this dissertation, the term middleware describes software that resides between an application and the inner workings of the system hosting the application, and that abstracts the complexities of the underlying technology from the application layer.''~\cite{Lang2003} - \end{itemize} -\item Use of system-on-chip (SoC) to replace multi-chip solutions. +\item Middleware describes software that resides between an application and the inner workings of the system hosting the application. The purpose of the middleware is to abstract the complexities of the underlying technology from the application layer~\cite{Lang2003}; to act as translation software for communicating from lower level to a higher level. This is the same sort of ``abstraction bridge'' that is required by the ``meet-in-the-middle'' methodology of PBD, along with the sort of software construct that benefits the virtualization of security component mapping. +\item As systems move towards more and more complex designs and implementations (as allowed by growths in technology; Moore's Law) the ability to make simplistic changes to these designs becomes exponentially more difficult. For this reason, levels of abstraction are desired when simplifying the design/evaluation phases of systems development. \begin{itemize} - \item Use of SoC to handle encryption/security in a secure and removed manner. + \item Use of system-on-chip (SoC) to replace multi-chip solutions. + \begin{itemize} + \item Use of SoC to handle encryption/security in a secure and removed manner. + \end{itemize} \end{itemize} \end{itemize} @@ -103,27 +106,54 @@ \section{Considerations} \label{Considerations} \begin{itemize} \item What standardization is important, why is it important? + \begin{itemize} + \item IC Domain standardization: flexibile integrated circuit where customization for a particular application is achieved by programming one or more components on the chip. + \item PC Domain standardization: PC makers and application software designers develop their products quickly and efficiently around a stanrad `platform' that emerged over time. + \begin{itemize} + \item x86 ISA - possible to reuse the OS \& SW application + \item Fully spcified set of buses (ISA, USB, PCI) - use same xplansion boards of IC's for different products + \item Full specification of a set of IO devices - keyboard, mouse, audio and video devices + \item Software can also be developed independently of the new hardware availability, thus offering a real hardware-software codesign approach + \end{itemize} + \item System Domain: Aspect of the capabilities a platform offeres to develop quickly new applications + \begin{itemize} + \item A distillation of the principles is needed so that a rigorous methodology can developed and profitably used across different design domains + \end{itemize} + \item So why is standardization useful? Standardization allows for manufacturers, system developers, and software designers to all work around a single, accepted, platform. It is understood what the capabilities of the hardware are, what the limitations of system IO will be, along with what the methods/protocols of communication will be. Even these preset aspects of the `standard' have their own `contractual obligations' of how they will function, what their respective `net-lists' are, and where the limtations of such standards lie. While the act of creating a standard takes time, not only due to time of development but due to speed of adoption of wide use, it is a necessary step. Without it, it becomes far more difficult to create universally used complex systems, let alone validate their correctness and trustworthiness. + \item ``Indeed, market data indicate that more than 80\% of system development efforts are now in software versus hardware. This implies that an effective platform has to offer a powerful design environment for software to cope with development cost.''~\cite{Vincentelli2002} + \begin{itemize} + \item \textbf{Note:} ``If the instruction set architecture (ISA) is kept constant, then software porting is much easier.''~\cite{Vincentelli2002} + \end{itemize} + \end{itemize} \item Where do we gain/lose on shifting the method of design \begin{itemize} \item Gain is ease of changes in development and searching of design space - \item Loss is time in developing the standards, rigors, and documentation that would be used as new standards for the industry. Ideally all manufacturers would adopt a new commodity; rather than components, `design combinations' would be the new commodity that manufacturers would peddle (e.g. instead of saying ``my components are the best'' the dialog moves towards ``My ability to combine these components is the best'') + \begin{itemize} + \item For PBD this means that a company/manufacturer is able to lower the cost and time spent in the `early development phase'; the time spent when first drawing up system designs prior to initial prototyping. While the advantage of overcoming multiple prototpying re-designs with a series of virtualization tools will cut down on development time, it can not be forgotten that the rigorous standards and documentation need to be developed for this sort of advantage. It is here that the most effort must be focused at first, but once this hurdle is passed then the advantages of such a system can be reaped + \item For security this mean that components can be standardized from a local, network, and distributed standpoint. These different scopes of security will be tackled in Section~\ref{Security}. The main point here is that with standardization comes a form of `contract' that all parties can expect will be followed, thus allowing for a different manufacturers/developers to create different aspect while knowing that these different elements will come together in the final product. + \end{itemize} + \item Loss is time in developing the standards, rigors, and documentation that would be used as new standards for the industry. + \begin{itemize} + \item Ideally all manufacturers would adopt a new commodity; rather than components, `design combinations' would be the new commodity that manufacturers would peddle (e.g. instead of saying ``my components are the best'' the dialog moves towards ``My ability to combine these components is the best'') + \end{itemize} \item Virtualization will help offset the costs in the long game \begin{itemize} \item Essentially, how to abstract the lower level requirements of a system (assembly/C) into a simpler high level set of tools (API/block) \begin{itemize} \item A new set of tools that can be used to build bigger and greater things out of a series of smaller more manage/customizable blocks \item Flexbilitiy of low level elements will help minimize conflict when attempting to design higher level blocks - \item Need for power/energy efficient systems to minimize ``power cost buildup'' - \item Functions should be kept simple (e.g. decide output, \textbf{but} not how output manifest) + \item Need for `tunable desings' that can be centered around specific aspects (e.g. power/energy efficient systems to minimize ``power cost buildup'', or security/trust centric needs). + \item Functions should be kept simple (e.g. decide output, \textbf{but} not how output manifest). This lends to both the ideas of abstraction (choosing the simple output) and standardization/documentation (know what the outputs are, but not needing to know exactly how they manifest; just that they will) \end{itemize} \end{itemize} - \item ``Indeed, market data indicate that more than 80% of system development efforts are now in software versus hardware. This implies that an effective platform has to offer a powerful design environment for software to cope with development cost.''~\cite{Vincentelli2002} - \begin{itemize} - \item \textbf{Note:} ``If the instruction set architecture (ISA) is kept constant, then software porting is much easier.''~\cite{Vincentelli2002} - \end{itemize} \end{itemize} \item Hardware/Software Codesign \begin{itemize} + \item There are different coding languages toi handle different aspects (i.e. SW/HW) + \begin{itemize} + \item Software: bad at timing and concurrency semantics + \item Hardware: Hardware semantics are very specific (and tough to simulate; thus existence of languages like SystemC) + \end{itemize} \item Previous issues and considerations \begin{itemize} \item Codesign of software simulations of hardware allows for development of high level software abstraction to interact with low level hardware abstraction(?) @@ -132,6 +162,9 @@ \section{Considerations} \item ``If the functional aspects are indistinguishable from the implementation aspects, then it is very difficult to evolve the design over multiple hardware generations.''~\cite{Vincentelli2007} \end{itemize} \item Manufacturer's standpoint boils down to: ``minimize mask-making costs but flexible enough to warrant its use for a set of applications so that production volume will be high over an extended chip lifetime.''~\cite{Vincentelli2007} + \begin{itemize} + \item This is exactly why industry would love for platform-based design to pick up. The monetary costs saved would be enough to warrent adoption of the technology, \textbf{but} the monetary costs of developing such a system (e.g. design, evalutation, validation) does not carry the same attraction (simply because companies are selfish and want to \textbf{make} money). + \end{itemize} \end{itemize} \section{Platford-based design} @@ -140,18 +173,21 @@ \section{Platford-based design} \item PBD (Platform-based design) \begin{itemize} \item Monetary considerations: re-use, flexibility of elements, re-programmable - \item Design of architecture platform is result of trade-off in complex space.~\cite{Vincentelli2002} + \begin{itemize} + \item Costs of producing chips becomes more expensive, thus pushing for the systems that are produced to be ``multi-capable'' (e.g. re-use value).~\cite{Keutzer2000} + \end{itemize} + \item The greatest challenge in the hardware design space is placement and arragement of components based on an array of differing variables. Design of architecture platform is result of trade-off in complex space, and worse yet some directly compete/contradict each other.~\cite{Vincentelli2002} \begin{itemize} \item The size of application space that can be supported by the architectures belonging to the architecture platform. This represents the flexability of the platform. - \item The Size of the architecture space that satisfies the constraints embodied in the architecture providers have in designing their hardware instances. + \item The Size of the architecture space that satisfies the constraints embodied in the architecture what providers have in designing their hardware instances. + \item Even at this level of abstraction these two aspects of hardware design can compete with each other. Ex: A manufacturer has pre-determined sizes that constrain their development space apriori. \end{itemize} - \item Two main concerns for effective platform-based design: + \item As with any new technology/design methodoloy/concept there are expensive initial costs for development, evaluation, and validation until more rigorous documentation can be made. As with any early development, it pays to think everything through first before diving into prototyping (want roughly 90/10 split between planning and action). This can be aided through the development of virtualization tools; which unfortunately come with their own development, evaluation, and validation costs. Harping on this, two main concerns for effective platform-based design: \begin{itemize} \item Software development \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 Costs of producing chips becomes more expensive, thus pushing for the systems that are produced to be ``multi-capable'' (e.g. re-use value).~\cite{Keutzer2000} \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} \begin{itemize} \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} @@ -214,6 +250,7 @@ \section{Conclusion} \item Need for development of platform-based design for security elements of all types \item Advantages: swap out old security modules with newer ones (re-use of base system), degree of system customization to meet system hardware/software needs \item As with any new shift in design methodoloy the largest cost in this new system would be the need for rigorous documentation and standardization of the process, components, and communication elements of said components. +\item This is why the development of groundwork for PBD-Security designs will be a slow and arduous, but the resulting `paydirt' will be a new set of virtualization tools at abstraction levels with design spaces yet true explored at regualr levels. The hope of this paper is to begin designing a frame work that pushes for not only better system design and developemtn (PBD) but alos for proper incorporation and planning of system security in an intelligent, rigorous and documented/standardized way. \end{itemize} %references section