Biblio

As recently studied, network-on-chip (NoC) suffers growing threats from hardware trojans (HTs), leading to performance degradation or information leakage when it provides communication service in many/multi-core systems. Therefore, defense techniques against NoC HTs experience rapid development in recent years. However, to the best of our knowledge, there are few standard benchmarks developed for the defense techniques evaluation. To address this issue, in this paper, we design a suite of benchmarks which involves multiple NoCs with different HTs, so that researchers can compare various HT defense methods fairly by making use of them. We first briefly introduce the features of target NoC and its infected modules in our benchmarks, and then, detail the design of our NoC HTs in a one-by-one manner. Finally, we evaluate our benchmarks through extensive simulations and report the circuit cost of NoC HTs in terms of area and power consumption, as well as their effects on NoC performance. Besides, comprehensive experiments, including functional testing and side channel analysis are performed to assess the stealthiness of our HTs.

Since the performance of bus interconnects does not scale with the number of processors connected to the bus, chip multiprocessors make use of on-chip networks that implement packet switching and virtual channel flow control to efficiently transport data. In this paper, we consider the test and fault-tolerance aspects of such a network-on-chip (NoC). Past work in this area has addressed the communication efficiency and deadlock-free properties in NoC, but when routing externally received data, aspects of security must be addressed. A malicious denial-of-service attack or a power virus can be launched by a malicious external agent. We propose a two-tier solution to this problem, where a local self-test manager in each processing element runs test algorithms to detect faults in local processing element and its associated physical and virtual channels. At the global level, the health of the NoC is tested using a sorting-based algorithm proposed in this paper. Similarly, we propose to handle fault-tolerance and security concerns in routing at two levels. At the local level, each node is capable of fault-tolerant routing by deflecting packets to an alternate path; when doing so, since a chance of deadlock may be created, the local router must be capable of guestimating a deadlock situation, switch to packet-switching instead of flit-switching and attempt to reroute the packet. At the global level, a routing agent plays the role of gathering fault data and provide the fault-information to nodes that seek this information periodically. Similarly, the agent is capable of detecting malformed packets coming from an external source and prevent injecting such packets into the network, thereby conserving the network bandwidth. The agent also attempts to guess attempts at denial-of-service attacks and power viruses and will reject packets. Use of a two-tier approach helps in keeping the IP modular and reduces their complexity, thereby making them easier to verify.

In the last decade, the number of available cores increased and heterogeneity grew. In this work, we ask the question whether the design of the current operating systems (OSes) is still appropriate if these trends continue and lead to abundantly available but heterogeneous cores, or whether it forces a fundamental rethinking of how systems are designed. We argue that: 1. hiding heterogeneity behind a common hardware interface unifies, to a large extent, the control and coordination of cores and accelerators in the OS, 2. isolating at the network-on-chip rather than with processor features (like privileged mode, memory management unit, ...), allows running untrusted code on arbitrary cores, and 3. providing OS services via protocols over the network-on-chip, instead of via system calls, makes them accessible to arbitrary types of cores as well. In summary, this turns accelerators into first-class citizens and enables a single and convenient programming environment for all cores without the need to trust any application. In this paper, we introduce network-on-chip-level isolation, present the design of our microkernel-based OS, M3, and the common hardware interface, and evaluate the performance of our prototype in comparison to Linux. A bit surprising, without using accelerators, M3 outperforms Linux in some application-level benchmarks by more than a factor of five.