SECTAR: Secure NoC Using Trojan Aware Routing
SECTAR: Secure NoC using Trojan Aware RoutingManju R‡ , Abhijit Das‡ , John Jose‡ and Prabhat Mishra ‡ Indian Institute of Technology Guwahati, Assam, India University of Florida, Gainesville, Florida, USAAbstract—System-on-Chips (SoCs) are designed using different Intellectual Property (IP) blocks from multiple third-partyvendors to reduce design cost while meeting aggressive time-tomarket constraints. Designing trustworthy SoCs need to addressthe increasing concerns related to supply-chain security vulnerabilities. Malicious implants on IPs, such as Hardware Trojans(HTs) are one of the significant security threats in designingtrustworthy SoCs. It is a major challenge to detect Trojansin complex multi-processor SoCs using conventional pre- andpost-silicon validation methodologies. Packet-based Network-onChip (NoC) is a widely used solution for on-chip communicationbetween IPs in complex SoCs. The focus of this paper is toenable trusted NoC communication in the presence of potentiallyuntrusted IPs. This paper makes three key contributions. (1) Wemodel an HT in NoC router that activates misrouting of thepackets to initiate denial of service, delay of service, and injectionsuppression. (2) We propose a dynamic shielding techniquethat isolates the identified HT infected IP. (3) We present asecure routing algorithm to bypass the HT infected NoC router.Experimental results on HT infected NoC demonstrate that theproposed method reduces effective average packet latency by38% in real benchmarks and 48% in synthetic traffic patterns.Our method also increases throughput and reduces effectiveaverage deflected packet latency by 62% in real benchmarksand 97% in synthetic traffic patterns.Index Terms—Hardware Trojan, Network-on-Chip SecurityI. I NTRODUCTIONWith the widespread commercialization of safety-criticalreal-time systems, semiconductor industries have started paying more attention to robust hardware-based security. Due totime-to-market and cost considerations, many products stillrely on supply chain to perform various activities including design automation of specific components as well asmanufacturing of integrated circuits. Functional security ofthese devices can be compromised due to involvement ofpotentially untrusted third-parties during the design cycle [1][2]. While there are various forms of supply-chain vulnerabilities, malicious implants in circuits, also known as HardwareTrojans (HTs) [3] [4], is one of the major security threatsin modern System-on-Chips (SoCs). These HTs can createsecurity vulnerabilities as well as functional inconsistenciesin the SoC [1]. Some of the HTs are hard to detect, subtlein their operation and are sophisticated to the extent that theycan even bypass the root-of-trust techniques that secure devicefirmware [2] [5]. Given that SoCs are used in a wide variety ofembedded and IoT devices, it is critical to enable trustworthycomputing using potentially untrusted components in SoCs.This work was partially supported by the NSF grant SaTC-1936040.Packet-based Network-on-Chip (NoC) provides the onchip communication infrastructure for modern Multi-ProcessorSystem-on-Chips (MPSoCs). NoC provides connectivity between a wide variety of components in a MPSoC such asprocessor cores, GPUs, memories, converters, controllers, I/O,etc. Due to its positional advantage, NoC is a prime target forattackers to insert HTs. Today’s NoCs provide more emphasison performance, scalability and backward compatibility thansecurity [6] [7]. In NoC, due to bandwidth limitations, packetsare further divided into smaller flow control units called flits.A packet consists of a head flit carrying route information, anumber of body flits carrying the data/payload and a tail flitmarking the end of the packet. Routing decisions are madeon the head flit and other flits follow the route using wormhole switching. NoC routers, the communication backbone ofMPSoCs are also vulnerable to security threats. HT infectedNoC routers can lead to denial of service [8], informationleakage [9], high jacking [10], unauthorized memory access[11], etc. They directly or indirectly result in bandwidthdepletion and performance degradation of the entire system.Detection and mitigation of HTs on NoCs impose uniquechallenges [12] [13]. To the best of our knowledge, there areno prior efforts in Trojan-aware routing that considers bothrun-time detection and avoidance of Trojans.In this paper, we model an HT on an NoC router thatmisroutes packets in the network and initiates DoS attack ona specific set of processing elements. Furthermore, misroutingpackets at times also create injection suppression that propagates across various routers, leading the system to a nearhalt. To secure NoC from such misrouting HTs, we propose atechnique called Trojan Aware Routing (TAR) which consistsof three main phases. In the first phase, we deploy a runtime detection mechanism that tracks for routing violationand exposes the HT infected NoC router. After detection,the second phase employs a dynamic shielding mechanismthat isolates the HT infected NoC router from the rest of thenetwork. With the shielding enabled, the third (final) phaseuses a bypass algorithm that route packets in the networkisolating the HT infected NoC router. In this paper, we makethe following major contributions: We implement packet misrouting on NoC to model anHT that leads to denial of service, delay of service, andinjection suppression. Our Trojan-aware routing dynamically detects a misrouting HT, shields it and route packets bypassing it. We experimentally demonstrate that our approach effectively mitigates DoS and injection suppression.
232 S2P1HT P2S1 39P2P2՛24312431162316238158150707SWSSEFig. 1: 8 8 mesh NoC with an HT at router 35The remainder of the paper is organized as follows. Wedescribe the threat model in Section II. Section III describesour Trojan-aware routing framework. Experimental resultsare presented in Section IV. Section V covers other relatedapproaches and we conclude our paper in Section VI.Fig. 2: Illustration of diverse HT impactswhere Fip are the flits of packet P such that:pFhead [{SRC, DEST, CT RL M SG}]pFbody [{CT RL M SG}, {Data}]pFtail [{CT RL M SG}, {Data}]II. T HREAT M ODELPath of packet P from source to destination can be given as:In our threat model, we consider an HT that tampersthe routing algorithm employed in NoC routers to enablemisrouting. When triggered, the HT maliciously assigns awrong output port to the head flit of a packet. All flits of thepacket also get misrouted in the same way. This can movethe packet away from its destination and can cause eitherdenial of service (DoS) or injection suppression or both. DoSis a scenario where a packet gets indefinitely delayed in thepath and never reaches its destination. Injection suppressionscenario is a by-product of DoS where new flits cannotbe injected into the network due to unavailability of routerinput buffers. Sometimes the packet may reach the destinationafter few cycles of extra delay. Usually, NoC packets carrycache miss requests, cache miss replies, evicted cache blocks,and coherence messages. An infected NoC router with theproposed HT can misroute these packets and degrade theapplication-level performance of latency-critical applications.Such type of HTs can be added to an NoC IP at any ofthe phases of an IC life cycle, including specification phase,design phase, and fabrication phase [3] [14]. In this work, weassume that the proposed HT enters the NoC IP during thepre-silicon stage, either by an attacker having access to thesystem design or by an untrusted third party EDA tool. TheseHTs can be modelled in a way such that they are internallytriggered and intermittently malicious [3] [15]. Note that if anHT is permanently malicious, it is easier to detect and bypass.We formulate the HT threat model as follows:An NoC packet P can be represented as:P {Rsrc , . . . Rk 1 , Rk , Rk 1 , . . . Rdest }pppppP {Fheadk Fbody1k Fbody2k . k Fbodynk Ftail} (1)(2)where Ri denotes router i on the NoC. Let RAi denote therouting algorithm employed in router Ri . We can infer fromEquation (1) and (2) that for a packet P ,pRAk (Fhead) Rk 1(3)where for packet P , the routing algorithm employed in routerRk will assign the next router as Rk 1 .Let HT denotes our proposed threat model such thatHT (RAk ) RA k andp RA k (Fhead) Rk 1where Rk 1 6 Rk 1Consider an 8 8 mesh NoC shown in Fig. 1. Based on thelocation of HT (router 35, shown in red color), we divide theNoC into eight different regions: N , E, S, W , N E, SE, SWand N W . When triggered, the impact of HT varies based onthe source and destination regions of packets. We categorizethe behaviour and impact of the proposed HT threat modelinto two cases. We explain them using two specific exampleswith the help of Fig. 2.Case 1: Consider a packet P 1 with source S1 on its way todestination D1 reaches router 35 as shown in Fig. 2. Insteadof forwarding P 1 to router 43 as per XY routing, the HTmisroutes P 1 to router 34. P 1, upon reaching router 34,follows XY routing, and reaches back to router 35. Note thatdestination D1 is at router 59 which is on the same columnas that of HT infected router 35. As per XY routing, P 1 can
SrcUniform RandomPackets Injected5000040000Dest CTRL BitsAlert Message7-bitsBaselineHTSrc30000Dest CTRL Bits msg dir DHT msg dir NHT msg dirmsg dir: 0: Anti-clock, 1: Clock1-bit3-bits3-bits20000DHT msg dir/NHT msg dir: 000: No Dir, 001: North, 010: West, 011: South, 100: East1000000.00Fig. 4: Structure of an alert flit0.020.040.06 0.080.10.12Packet Injection Rate0.140.180.20A. Phase 1: Trojan DetectionSomething Short and SimpleFig. 3: HT triggered injection suppressionreach destination D1 only through router 35, which is infected.Hence router 35 will always misroute and P 1 can never reachdestination D1, leading to a DoS like attack on NoC. FromFig. 1 we can see that source S1 is in region E and destinationD1 is in region N . Thus, inter-region communication of typeE N will create a DoS like scenario here. To generalise,for all inter-region communication where the destination routeris on the same column as that of HT infected router 35, aDoS attack like scenario will arise. A DoS attack like scenarioarises when there is a packet movement between the followingregions: E N, E S, W N, W S NE S,NW S, SE N , SW N.In this illustrative example, packet P 1 will be trapped ina ping-pong behaviour between router 35 and its neighborrouters 27, 34, and 36 since router 35 will never forward P 1to router 43. Packets are buffered in VCs of routers whiletaking part in routing and arbitration decisions. Prolongedping-pong of P 1 leads to VC unavailability in neighboringrouters and propagates the effect to others by back-pressure.Eventually a scenario of injection suppression arises in theentire system. Fig. 3 shows how the proposed HT threat modelcreates injection suppression in an 8 8 NoC while running theuniform random synthetic traffic. As injection rate increases,the impact of the proposed HT escalates, and results in moreinjection suppression.Case 2: Consider another packet P 2 in Fig. 2 with sourceS2 on its way to destination D2 reaches router 35. Instead offorwarding P 2 to router 36 (as per XY routing), the activatedTrojan at router 35 misroutes P 2 to router 27. Following XYrouting, router 27 now forwards packet P 2 to router 28. Sincethe destination D2 is not in the same column as that of router35, packet P 2 can eventually reach the destination. However,getting misrouted by router 35 delays the arrival of packetP 2 at destination D2. This is a scenario of delay of serviceattack. From Fig. 1 we can see that source S2 is in regionW and destination D2 is in region N E. Thus inter-regioncommunication of type W N E creates a delay of service.To generalise, a delay of service attack like scenario will arisewhen there is a communication between the following regions:E W, E NW, E SW W E, W N E,W SE.III. T ROJAN AWARE ROUTING (TAR)Our proposed TAR technique is employed in every routeron NoC. TAR involves three phases: Detection, Shielding, andBypass. The working of these phases is described as follows:MARS Research Lab, CSE@IITG 2017We use XY routing where a packet travels along the Xdirection and reach the same column as that of destination.Then, the packet travels along the Y direction to reach thedestination. Let P be a packet with source S(x1, y1) anddestination D(x2, y2). As per XY routing, when P reachesan intermediate router R(x, y), it will be forwarded along Xdirection until (x x2). When P reaches a router where(x x2), it changes the direction and starts travellingalong Y direction until (y y2). When P reaches a routerwhere (y y2), it reaches destination D(x2, y2). TheXY routing algorithm decides the output port for a packetbased on the position of destination router with respect tothe current router. The routing algorithm does not considerthe input port of the packet and its previous router for itsrouting decisions. Our proposed HT threat model exploits thisfeature of the routing algorithm and enables misrouting. Now,even if a packet is misrouted and reaches a router where itshould not have reached as per XY routing, the employedrouting algorithm will never be able to detect it. Packet willbe forwarded to destination without knowing the misroutingthat lead the packet to this router.To identify packet misrouting and HT infected router, weadd a detection module, a 1-bit alert flag and a 3-bit alert dirat every NoC router. alert flag is set only if the neighboris identified as an HT infected router and reset otherwise.alert dir either denotes no direction or the direction where theHT is detected; north, east, south, or west. In the illustrativeexample shown in Fig. 2, packet P 1 is forwarded to router34 because of the misrouting at router 35. With the detectionmodule in place, router 34 knows that P 1 has entered througheast input port from router 35. Analysing the position ofdestination D1 at router 59 with respect to router 35, detectionmodule concludes that XY routing is violated and P 1 ismisrouted. Router 34 sets its alert flag and updates alert diras east since router 35 misrouted packet P 1 and hence mustbe an HT infected router. Both alert flag and alert dir areextensively used in the subsequent phases of shielding andbypass routing.B. Phase 2: Dynamic ShieldingOnce the HT is detected by one of its neighbors (27, 34, 36,or 43), a dynamic shielding protocol is activated. The routerthat detects the HT, generates a special alert flit to be sentto its neighbors about the detection of the HT. We call suchrouters as generators. Neighbors upon receiving the alert flitpropagates the message further by creating a propagation flit.We call such routers as propagators. The structure of these
5648GNS: 34, D: 42MSG: {E, S}PES: 42, D: 43MSG: {S}PE40635547C. Phase 3: Trojan Bypass39The final phase of TAR implements a bypass routingmechanism as presented in Algorithm 1.GN32HTcompleted when alert dir is set for router 27 as north, router34 as east, router 43 as south, and router 36 as west. After theend of dynamic shielding, the detected HT infected router isisolated from rest of the network.GS2416831PE՛GSS: 34, D: 26MSG: {E, N}PE՛S: 26, D: 27MSG: {N}023157Fig. 5: Working of dynamic shielding in TARspecial flits are very similar to normal flits as shown in Fig. 4.Alert flit contains a 1-bit msg dir indicating the directionan alert flit needs to be forwarded by generators. A 3-bitDHT alert dir indicates the direction an alert flit needs to beforwarded by propagators. Alert message also contains a 3-bitNHT alert dir which indicates the direction where the HT isdetected. Fig. 4 presents all the possible values for differentfields of the alert flit. When the message of HT detection ispropagated among all the neighboring routers using alert andpropagation flits, each router accordingly updates its alert flagand alert dir. This results in a shield creation around the HTthat successfully isolates the HT infected router from rest ofthe network. Third and final phase of TAR uses this shieldingto route packets by bypassing the isolated HT infected router.With an illustrative example shown in Fig. 5, we explain theworking of our dynamic shielding phase. From the previousphase of HT detection, let us assume that router 34 hasidentified router 35 as an HT infected router. alert flag inrouter 34 is now set to 1 and alert dir as 100 (East). Asshown in Fig. 5, router 34 generates two alert flits, GN andGS . With an alert message {msg dir 0, DHT alert dir 100, NHT alert dir 011}, alert flit GN is forwarded fromrouter 34 to router 42, where msg dir 0 indicates GN to beforwarded in clockwise direction. DHT alert dir 100 (East)in GN indicates that upon reaching router 42, the messageneeds to be propagated in East direction. Router 42 generatesa propagation flit PE with an alert message {msg dir 0,DHT alert dir 000, NHT alert dir 011} to be forwardedto router 43. When PE reaches router 43, NHT alert dir 011(South) indicates that the HT is detected in South directionof router 43; which is router 35. alert flag and alert dir areupdated as 1 and south respectively in router 43 which can bea generator for other neighbors. Similarly, GS and PE 0 alsopropagates the message of HT detection to other neighbors.Here, 27, 34, 43, and 36 are generator routers and 26, 42,44, and 28 are propagation routers. The message propagationcontinues from both sides until a logical shield is createdaround the HT infected router. In this example, the shield isAlgorithm 1: Trojan bypassInput : Packet headerOutput: Output port direction of a flitTerminologyxdif f : x difference between destination & current router.ydif f : y difference between destination & current router.in dir: Input port direction of a flit.out dir: Output port direction of a flit.maxCredit(out dir1 , out dir2 ): returns out dir with more VCs./*Part I: Mitigation by generator routers */if alert f lag is SET thenif xdif f 6 0 && ydif f 6 0 thenif alert dir 6 EAST thenif xdif f 0 && in dir 6 EAST thenout dir EASTelse if alert dir 6 W EST thenif xdif f 0 && in dir 6 W EST thenout dir W ESTelse if alert dir EAST W EST thenif ydif f 0 thenout dir SOU T Helseout dir N ORT Helse if xdif f 0 thenif (ydif f 0 && alert dir N ORT H) (ydif f 0 && alert dir SOU T H) thenout dir maxCredit(EAST, W EST )else if ydif f 0 thenif (xdif f 0 && alert dir EAST ) (xdif f 0 && alert dir W EST ) thenout dir maxCredit(N ORT H, SOU T H)else if alert dir 6 N ORT H thenif ydif f 0 && in dir 6 N ORT H thenout dir N ORT Helse if alert dir 6 SOU T H thenif ydif f 0 && in dir 6 SOU T H thenout dir SOU T H/*Part II: Mitigation by propagation routers */else if alert f lag is RESET thenif (xdif f 0 && in dir W EST ) (xdif f 0 && in dir EAST ) thenif ydif f 0 thenout dir SOU T Helseout dir N ORT Helse if xdif fout direlse if xdif fout dir 0 && in dir SOU T H then W EST 0 && in dir N ORT H then EASTWhen a packet arrives at a router, bypass mechanism checksthe alert flag and alert dir of that router. Only if the alert flagis set and alert dir matches with the desired output portdirection of the packet, bypass routing in activated. In all
56D163D2P1P248554047P132 S2HTS1 39P22431162381507Fig. 6: Working of bypass algorithm in TARother cases a packet follows normal XY routing to reach itsdestination.We explain the working of Trojan bypass algorithm with anillustration as shown in Fig. 6. We consider the same exampleas that in Fig. 2 for the sake of simplicity and continuity. Apacket P 1 with source S1 on its way to destination D1 reachesrouter 36. After the completion of shielding in the previousphase, router 36 has its alert flag set and alert dir as west. Asper XY routing, the desired output port of packet P 1 at router36 is west which matches with the alert dir of router 36.Now the Trojan bypass algorithm initiates and reroute packetP 1 away from the HT infected router 35 as presented in PartI of Algorithm 1. Packet P 1 is rerouted from router 36 torouter 44 and Part II of Algorithm 1 is initiated since 44 is apropagation router. Now, packet P 1 is forwarded from router44 to router 43 and from there it directly reaches destinationD1 at router 59.Since destination D1 is in the same column as that of HTinfected router 35, it becomes impossible for P 1 to reachD1 using conventional approach and resulted in a DoS likescenario. With the Trojan bypass algorithm in place, now P 1is able to reach its destination thus mitigating the impact ofDoS. Since packet like P 1 are not trapped in the networkanymore, our bypass routing also diminishes the possibilityof injection suppression. Similarly, packet P 2 with sourceS2 on its way to destination D2 reaches router 34. Insteadof forwarding to router 35 which is HT infected, router 34reroutes P 2 towards router 42. The Trojan bypass algorithmrerouted packet P 2 in such a way that it reaches destinationD2 without any additional delay. Hence, the delay of servicescenario created by the proposed HT threat model is mitigatedby intelligent bypassing.Rerouting packets using the bypass algorithm violates normal XY routing and creates a possibility for network deadlock.To ensure deadlock prevention, we employ the concept ofintermediate destination [16]. When packet P 2 is reroutedfrom router 34 to router 42, it starts travelling in Y direction.However, when it travels from router 42 to router 43, P 2violates XY routing, since turning X from Y direction isprohibited. Using the concept of intermediate destination [16],router 42 is made the new destination for packet P 2. Now,after getting rerouted from router 34, packet P 2 reachesrouter 42 and gets ejected into its local output port, since42 is the new destination. Only after router 42 finds out thatP 2 is actually meant for destination D2 at router 62, it reinjects P 2 as a new packet destined for D2. Packet P 2 nowfollows normal XY routing like any other packet to reach thedestination. The ejection of packet P 2 and re-injection as anew packet from the intermediate destination 42 makes surethat XY routing is not violated thus eliminating the scope ofnetwork deadlock.IV. E XPERIMENTSWe evaluate the performance of TAR using effective averagepacket latency, effective average deflected packet latency,throughput, and injection suppression avoidance.A. Experimental Setup and WorkloadsWe implement the baseline system (normal NoC withoutany HT), NoC with an HT infected router, as well as theproposed TAR using the event-driven simulator, gem5 [19].We use the garnet framework in gem5's ruby memory modelfor implementing the NoC. Our baseline system is a traditional8 8 2D mesh NoC with 5 VCs per input port and usesa 128-bit flit channel for inter-router communication usingXY routing. To model the Trojan, we modify the routingmodule such that there exists a single HT router in the NoCat any given point in time. The shielding approach and bypassalgorithm is done in garnet with all micro-architectural andfunctional specifications, as discussed in Section 3.To evaluate the performance and NoC-specific parameters,we run standard synthetic traffic patterns uniform random,and bit complement by varying the injection rate. We alsoanalyse the proposed system using real application workloadsconsisting of SPEC CPU 2006 benchmarks. We model a 64tile TCMP, each with a simple CPU core and a 32 KB, 4way set associative, 64-byte block, private L1 cache. Each tilehas a 256 KB, 16-way associative, 64-byte block, shared L2cache. L2 cache sets are mapped to various tiles using theSNUCA technique. We assign a SPEC CPU 2006 benchmarkapplication to each of the 64 core to model a TCMP simulationframework. L1 cache misses trigger NoC packets, which getrouted from the source tile to the destination tile to which thecorresponding L2 cache sets are mapped. Similarly, the replypackets also travel through the NoC. We use a 1-flit requestpacket and a 5-flit reply packets.We study the performance of the NoC under differentnetwork loads by grouping the SPEC CPU 2006 benchmarksbased on their Misses Per Kilo Instructions (MPKIs). Weclassify the benchmarks into High MPKI (greater than 40),Medium MPKI (less than 40 but greater than 20), and LowMPKI (less than 20). Here we use leslie3d, lbm, GemsFDTD,and mcf under High MPKI, soplex and astar under Medium
TABLE I: Workload categorization using SPEC CPU 2006 benchmark mixes.leslie3d (16)sjeng (16)soplex (32)leslie3d (8)sjeng (8)leslie3d (8)Workload Pattern: name of benchmark (number of instances)lbm (16)GemsFDTD (16)mcf (16)bzip2 (16)omnetpp (16)sphnix (16)astar (32)bzip2 (8) omnetpp (16) sjeng( 8)GemsFDTD(8) lbm (8) mcf (8)bzip2 (8) sphnix (16)soplex (16)astar (16)bzip2 (8) omnetpp (16) sjeng( 8)soplex (8)astar ( 16)2001501005000.000.020.040.06 0.08 0.1 0.12Packet Injection Rate0.140.180.2(a) Effective average packet .060.08Packet Injection Rate0.1(d) Effective average packet latency0.12Eff. Avg. Defl. Pkt. Lat. (Cycles)Eff. Avg. Pkt. Lat. 6 0.08 0.1 0.12Packet Injection Rate0.140.180.2(c) ThroughputBit ComplementBaselineHTTAR2500.080.10.12Packet Injection Rate0.15BaselineHTTAR(b) Effective average deflected packet latencyBit Complement300Uniform Random0.2BaselineHTTARPackets/router/cycle250Eff. Avg. Defl. Pkt. Lat. (Cycles)Eff. Avg. Pkt. Lat. (Cycles)BaselineHTTAR300Workload Characteristics100% High MPKI100% Low MPKI100% Medium MPKI50% High MPKI, 50% Low MPKI50% Low MPKI, 50% Medium MPKI50% High MPKI, 50% Low MPKIUniform RandomUniform Random350Bit ket Injection e) Effective average deflected packet latency0.040.060.08Packet Injection Rate0.10.12(f) ThroughputFig. 7: Performance analysis with synthetic traffic patterns. For latency plots given in (a), (b), (d), & (e), lower the line betterand for throughput plots in (c) & (f), higher the line the better.150100500M1M2M3M4Benchmark MixesM5M6(a) Effective average packet latency500400SPEC CPU 2006 Benchmark MixesBaselineHTTARPackets/router/cycle200SPEC CPU 2006 Benchmark MixesBaselineHTTAREff. Avg. Defl. Pkt. Lat. (Cycles)Eff. Avg. Pkt. Lat. (Cycles)SPEC CPU 2006 Benchmark Mixes2503002001000M1M2M3M4Benchmark MixesM5M6(b) Effective deflected packet elineHTTARM1M2M3M4Benchmark MixesM5M6(c) ThroughputFig. 8: Performance analysis with SPEC CPU 2006 benchmark mixes. TAR reduces effective average packet latency anddeflected packet latency over HT, and maintains a comparable throughput as that of baseline. For latency plots (a) & (b),lower the bar the better and for throughput plot (c), higher the bar the better.MPKI, and sjeng, bzip2, omnetpp, and sphinx under LowMPKI. With the help of this classification, we form sixcategories of workloads; M1, M2, M3, M4, M5, and M6, eachhaving 64 benchmark instances, as given in Table I.B. Effective Average Packet LatencyTo analyse the effect in packet latency with HT triggeringand mitigation, we use average packet latency (APL), whichis defined as the number of cycles required for a packet toreach its destination. As the average packet latency on anHT infected NoC shows inconsistent values at higher injectionrates due to packet loss and injection suppression, we apply amore realistic metric effective average packet latency (EAPL)[15] which is defined as follows:P ackets EjectedwithoutHT(4)EAP L AP L P ackets EjectedwithHTFig. 7a and 7d shows the effective average packet latencyusing uniform random and bit complement traffic patterns. Asexpected when injection rate increases, packet latency alsoincreases in baseline, HT infected NoC, and TAR. But weobserve that the rate of latency increase in the case of HTinfected NoC is significantly higher than other two. This is dueto the deflection of packets by HT router and subsequent DoSas well as delay of service scenario. However, TAR reduceseffective average packet latency significantly compared to
C. Effective Average Deflected Packet LatencyAverage deflected packet latency (ADPL) is defined as theaverage packet latency of those packets which are meant totravel through the HT infected router. Consider a router Rthat is going to be HT infected. To calculate the ADPL inbaseline, we consider the packets that are passing through R.In the case of an HT infected NoC, ADPL is calculated foronly those packets that suffer Trojan-induced deflection at R.For calculation of ADPL in TAR, we consider the packets thatare deflected by the neighbors of R while applying the bypassalgorithm.Similar to effective average packet latency, to getmeaningful latency values, we use effective average deflectedpacket latency (EADPL) which is defined as follows:Def lected P ackets EjectedwithoutHTDef lected P ackets EjectedwithHT(5)Fig. 7b and Fig. 7e shows the effective average deflectedpacket latency using uniform random and bit complementtraffic patterns, respectively. We observe that as the injection rate increases, effective average deflected packet latencyincreases significantly on the HT infected NoC. With HTtriggering, few packets deflected by HT enter into a ping-pongstate between its neighbors. Eventually, some of these packetsmove out of this state and reach the destination. This leads toan increase in the deflected packet latency. As the injection rateincreases, this ping-pong effect reduces the available routerbuffers, which, in turn, increases the deflected packet latency.We observe that TAR reduces the effective average deflectedlatency significa
Packet-based Network-on-Chip (NoC) provides the on-chip communication infrastructure for modern Multi-Processor System-on-Chips (MPSoCs). NoC provides connectivity be-tween a wide variety of components in a MPSoC such as processor cores, GPUs, memories, converters, controllers, I/O, etc. Due to its positional advantage, NoC is a prime target for
May 2020 NOC April 2020 NOC March 2020 Modification of Section IV Table 11C.1 (New provision symbols: 30B#6.21N_1, 30B#6.21N_2) February 2020 NOC January 2020 Modification of Section II Chapter 1 and Chapter 2 with new Special Sections: AP30/P and AP/30A/P. December 2019 NOC November 2019 NOC October 2019 NOC September 2019
Jun 17, 2016 · USC’s mission. Five Traits of a Trojan “I am a Trojan” is a university-wide initiative dedicated to creating a common language around our shared values. The five traits of an ideal Trojan are engraved on the pedestal of the Trojan Shrine (“Tommy Trojan”), built in 1930 to commemorate
The term Trojan asteroid was coined when it was decided to name all asteroids discovered at the L4 and L5 points after warriors in the Trojan war, Greek and Trojan, respectively. The exceptions are Hector (a Trojan spy in the Greek camp) and Patroclus (a Greek spy in the Trojan camp).
Once the design of the basic NOC architecture became established, new techniques evolved to address advanced issues such as dynamic load balancing on to a node of the NOC architecture, the shortest/fastest path for the data flow through NOC, and energy efficient NOC architecture design. Most researchers have focused on the
complex system chip design, especially for NoC-based SoC, which has been increasingly applied to complex system design. This paper proposes a collaborative verification and testing platform for NoC-based SoC. Based on VMM verification methodology, a hierarchical NoC validation platform is constructed and assigned to the function verification of NoC
Zeus Trojan – Removes Accept-Encoding header altogether for targeted sites SpyEye Trojan – May remove Accept-Encoding header for Internet Explorer versions 6 or lower Bugat Trojan – Replaces header content with 14 spaces – Accept-Encoding: Tigger Trojan – Changes header name to “Accepl-Encoding”
without breaking your business model, Kaseya NOC Services can help. Designed to let you scale quickly, Kaseya NOC Services deliver the monitoring and management services you need to extend your existing in-house staff and meet your customers' demands. You can deploy Kaseya NOC Services 24x7 as a permanent 'virtual' member of your IT staff.
The Project Gutenberg EBook of First Course in the Theory of Equations, by Leonard Eugene Dickson This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org Title: First Course in the Theory of Equations .
