30°C Power On 12 to 36 watts - for fanless sealed system design ...

More documents

Recommendations

Info

ESE Magazine Jan/Feb 06 44 MILS: High-assurance security Joe Jacob, Objective Interface Systems As it becomes possible to connect systems through the Net, how can you preserve their integrity and security? NOW THAT the Internet and high-speed communications have made it possible to connect military and aerospace systems throughout the world through the U.S. Department of Defense’s Global Information Grid (GIG), information networks are more vulnerable than ever. An emerging software architecture, Multiple Independent Levels of Security (MILS), was designed to increase the level of security for safety- and mission-critical systems. It combines the best of the safety and security worlds to create a better solution than either could have devised. It draws upon FAA DO-178B Level A Safety technology and Common Criteria EAL7 Security requirements to enable highassurance security for mission-critical embedded and real-time systems, including high-assurance weapons, training and communications systems and C4I platforms. MILS dramatically reduces the size and complexity of security-critical code, thereby allowing faster and more cost-effective development and evaluation. The central idea behind MILS is to partition a system in such a way that (1) the failure or corruption of any single partition cannot affect any other part of the system or network, and (2) each partition can be security-evaluated and certified separately, so that no partition needs to be evaluated at a higher level than is required for its particular function. The MILS architecture To support these partitions, the MILS architecture is divided into three layers, the Separation Kernel, Middleware and Applications. Separation kernel: The MILS separation kernel divides the computer into separate address spaces and scheduling intervals, guarantees isolation of the partitions, and supports carefully controlled communications among them. Because the separation kernel performs these functions and only these functions, the source code can be small—roughly 4,000 lines of C language code. This makes it fast and practical to verify using formal analysis methods (mathematical verification) and to do the exhaustive testing and comprehensive documentation required for the highest level certifications. The separation kernel requires the highest level of authentication, and is the only piece of software that runs in privileged mode. Therefore, no other code, not even device drivers, has the ability to affect the processor’s protection mechanisms. Everything else, including all middleware, runs in user mode. The small size of the separation kernel is a manifestation of the most important MILS design objective: It is because of this rigorous inspection and evaluation that the MILS separation kernel can be trusted. Green Hills Software, LynuxWorks and Wind River each plan on delivering commercially available Separation Kernels. Middleware: In the MILS architecture, middleware has a broader meaning that just traditional middleware. Most of the traditional operating system functions have been moved from the operating system to “middleware services,” e.g., file systems, device drivers, trusted path, etc. Middleware services include a Partitioning Communications System (PCS) to extend the scope of the separation kernel to inter-system communication. It also includes traditional middleware like CORBA (Common Object Request Broker Architecture), DDS (Data Distribution Service) and Web services. Middleware resides in the same kind of partition as the application that it supports, either co-resident with the application or in a partition by itself. Middleware runs in unprivileged (user) mode, making these services subject to separation kernel policy enforcement. The services that previously ran in privileged mode as part of the operating system, such as memory allocation, device drivers, I/O primitives, file systems, and network stacks, now run in user mode in the MILS middleware layer. Applications: Applications manage, control, and enforce their own application-level security policies, such as firewalls, crypto services and guards. Instead of the fail-first patch-later approach, trusted components are mathematically verified so that they are “NEAT”: Nonbypassable, Evaluatable, Always invoked, and Tamperproof. The importance of the PCS When we create a distributed system configuration, we would like it to be as safe or secure as if it were just a single processor. We accomplish this by implementing end-to-end enforcement of the basic MILS separation kernel policies. The PCS is the enforcement mechanism. The collection of MILS nodes in a distributed system is called an enclave, and the PCS is present in each node in the enclave. The PCS fits between the applications and the partitions implementing U (SL) Application Application #1 Middleware Application #1 Middleware S (SL) Application PCSexpress Separation Kernel TS (SL) Application Network protocols & drivers Figure 2: PCSexpress within the MILS architecture. TS/S (MLS) Application Middleware Middleware Middleware Middleware Separation kernel Processor Figure 1: The basic MILS architecture. To open network network protocols. Objective Interface Systems is the developer of PCSexpress, the first product to conform to the secure communications architecture—the PCS—that Objective Interface invented. Designed for embedded systems, enterprise servers, workstations and global networks, PCSexpress provides off-the-shelf highassurance communications security that reduces the duration, schedule risk and cost of designing, evaluating, accrediting and deploying highly secure systems. Past efforts at making software truly secure usually added complexity and high cost. Layers of protection were added on top of the operating systems, middleware, and the applications. Sometimes these layers interfered with each other, had unintended side affects, or were not completely consistent with each other, giving both bugs and attackers the initial crack in the wall they needed to inflict damage. The MILS approach is precisely the opposite. Systems are made more secure by making the protection simpler. Because it is simpler, it can be trusted to work under all conditions. The processor, via the MILS separation kernel, is tightly controlled. The PCS provides the same assurances for distributed systems. www.ois.com/mils
Why use an RTOS? Tomoyuki Uda, Managing Director, eSOL, Inc An RTOS provides a great deal for the FPGA developer. What should you consider when choosing one? THE FLEXIBLE Nios II processor extends Altera’s FPGAs into new and varied application possibilities. With a microprocessor in the FPGA, developers can design more efficient and powerful embedded systems. With this expanded capability, developers for FPGA-based systems may be facing the decision of whether to use a Real Time Operating System (RTOS) for the first time. What features does an RTOS provide? An RTOS provides the foundation for building your embedded application. The most basic definition of an RTOS is that it provides multiple threads of execution, and a scheduler to switch between those threads. Multiple threads allow you to break up your application into its basic parts, separated by purpose and priority. Most RTOS kernels provide the following set of features: Multiple threads An RTOS allows multiple threads of execution, implemented as tasks or processes, depending on the nature of the RTOS. Preemptive, priority-based scheduling A preemptive scheduler allows interrupts and higher priority tasks to interrupt the currently running task. Synchronization services Multitasking kernel allow tasks to wait for other tasks to complete work, or wait for an event to occur. These services typically include mutual exclusion mechanisms (mutex and/or semaphores), event flags, data queues, etc. Interrupt and exception support The RTOS kernel provides a way to handle hardware interrupts and exceptions through installing interrupt and exception handlers. Predictable interrupt latency and task switch time RTOS kernels have predictable overhead for handling interrupts and switching tasks. When to use an RTOS An RTOS is useful in complex systems to streamline application development. Polling loops work well for dedicated, simple designs, but quickly get complex when the design grows. For example, running multiple network servers can work from a polling loop, however the application design becomes much simpler and more modular if each network server is run in its own task. Using an RTOS is also beneficial when an application needs to run on multiple CPUs – using an RTOS abstracts the hardwaredependence so porting the application to a different target is easier. Using an RTOS abstracts that dependency so the application concentrates only on the operations required to perform its functions, and the RTOS handles the hardware interface. Most commercial RTOSes support many CPUs and specific boards. An RTOS incorporates useful services that you would otherwise need to implement, debug, and maintain yourself in your own code library. Applications using an RTOS can dynamically allocate resources when they are required. Sharing resources reduces the overall memory requirements for the application. Choosing an RTOS When you consider how to design your application on the Nios II, you can choose to not use an RTOS at all, to use a free RTOS, or to use a commercial RTOS. If you do choose to use an RTOS, there are freely available solutions and commercial solutions. The following factors should be considered when choosing an RTOS: Cost Developers often adopt open-source solutions because they are free. While the licensing cost is free, it’s important to add up the complete cost for using any RTOS. Technical support is only offered in online forums. In a critical project, you may need additional technical support or custom services. The extra support and services are not free, and the associated fees are often more expensive than the license cost of a commercial RTOS. When considering license cost, consider the risk to your project vs. the cost of the license, support, and services. Licensing When you use an open-source operating system in your product, you assume the risk and liability for using that code. Commercial RTOS vendors assume the risk for their own OS implementation. Technical support and maintenance Receiving technical support from the same engineers who wrote and maintain the operating An RTOS incorporates useful services that you would otherwise need to implement, debug, and maintain yourself system shortens the support and development cycle. PrKERNELv4 PrKERNELv4, from sCOS, is the base of a full RTOS suite called eParts that provides a real time kernel, TCP/IP connectivity with PrCONNECT2, an embedded file system with PrFILE2, integration with a graphical user interface library, and more. The entire eParts product suite is fully integrated into Altera’s development environment for Nios II. Support is also integrated with several Altera third party partners’ software and tools, such as Lauterbach’s Trace32, the MorethanIP 10/100/1000 MAC- NET Core and the SLS USB Core Conclusion Choosing an RTOS doesn’t need to be complex. When choosing an RTOS, consider the features you need as well as associated development costs for porting, support, and software licensing. www.esolglobal.com ESE Magazine Jan/Feb 06 45
Page 3 and 4: Editorial Editor: Dick Selwood E-ma
Page 5 and 6: High-performance analog. Supercharg
Page 7 and 8: “The QNX Neutrino microkernel OS
Page 9 and 10: AEC-6810 Perfect Factory/Building A
Page 11 and 12: obust signal analysis. The mixed-si
Page 13 and 14: ��
Page 15 and 16: See us at Embedded World 2006 Nurem
Page 18 and 19: ESE Magazine Jan/Feb 06 18 MOST -
Page 20: ESE Magazine Jan/Feb 06 20 Benchma
Page 23 and 24: Some things have to go out on time
Page 25 and 26: ��
Page 27 and 28: ��
Page 29: datacom telecom wireless devices au
Page 33 and 34: Come learn how Microsoft embedded o
Page 35 and 36: equests from threads to perform sch
Page 37 and 38: Embedded PCs Fieldbus Packaged PCs
Page 39 and 40: Copyright © 2006 Kontron AG. All r
Page 41 and 42: • Q u a l i t y a n d r e l i a b
Page 43: NO SLOWING DOWN. EVER. The market w
Page 48: ESE Magazine Jan/Feb 06 48 Flash s

30°C Power On 12 to 36 watts - for fanless sealed system design ...

Create successful ePaper yourself

Delete template?

Save as template?