Patent Description:
Various embodiments of the present disclosure are directed to providing mitigation against "glitch" style attacks on a communication network, such as, an IVN. As used herein, a glitch style attack is any attempt to mislead a node on the network based on exploiting different sampling times of the network nodes. For example, a malicious actor (e.g., malicious electronic control unit (ECU), or the like) can transmit a message where voltage levels are "glitched" such that different nodes sample different voltage levels for the same bit. Messages received at the receiving nodes are all valid but can differ from each other due to the different sampled voltage levels. Compounding this problem is the fact the receivers cannot distinguish fake information from authentic information. As a result, the receiving nodes may make different decisions and/or take different action based on the received message.

The present disclosure provides systems and methods that can be implemented to mitigate attempts to mislead receiving nodes based on exploiting sampling time of receiving nodes. In particular, the present disclosure provides systems and methods arranged to monitor the communication bus and force bit levels to remain constant through the entire bit width to prevent or mitigate against glitch style attacks. A centralized approach as well a distributed approach are described. It is noted that although the present disclosure often references vehicles, vehicle ECUs, and IVNs in describing illustrative examples, the claims can be applied to a variety of broadcast communication networks where sampling mechanisms would be susceptible to glitch style attacks. For example, broadcast communication networks are found in industrial, commercial, retail, transportation, aircraft, military, etc., systems and the present disclosure is applicable to all such systems.

In the following description, numerous specific details such as processor and system configurations are set forth in order to provide a more thorough understanding of the described embodiments. However, the described embodiments may be practiced without such specific details. Additionally, some well-known structures, circuits, and the like have not been shown in detail, to avoid unnecessarily obscuring the described embodiments.

<FIG> illustrates an example system <NUM>, which can be implemented in a vehicle, such as, for example, an automobile, a motorcycle, an airplane, a boat, a personal watercraft, an all-terrain vehicle, or the like. System <NUM> includes a number of electronic control units (ECUs), for example, ECU 102a, ECU 102b, and ECU 102c are depicted. System <NUM> further includes attack prevention device <NUM>. System <NUM> includes a communication bus <NUM>, which can be a CAN bus, a FlexRay bus, a CAN FD bus, an inter-integrated circuit (I2C) bus, a serial peripheral interface (SPI) bus, an automotive ethernet bus, or a local interconnected network (LIN) bus, or an interconnect or bus for memory or other circuitry (intellectual property (IP) cores, or the like). Additionally, where implemented in contexts outside of the automotive space, the communication bus <NUM> can be a network bus adapted to the particular implementation, such as, for example, a communication network for manufacturing equipment, or the like.

In general, each of ECU 102a, ECU 102b, and ECU 102c include circuitry arranged to generate messages and transmit the messages onto communication bus <NUM> and/or consume messages from communication bus <NUM>. The depicted ECUs (e.g., ECU 102a, ECU 102b, and ECU 102c) can be any of a variety of devices, such as, for example, sensor devices, actuator devices, microprocessor control devices, memory, IP cores, or the like. For example, the ECUs include circuitry arranged to manipulate voltage levels on communication bus <NUM> (e.g., see <FIG>) to communicate messages via the communication bus <NUM>. As depicted, system <NUM> includes ECU 102a, ECU 102b, and ECU 102c. This is done for clarity of presentation. However, in practice (e.g., in a modern automobile, or the like) hundreds of ECUs may be provided in system <NUM>, such as, ECUs for engine control, transmission, airbags, antilock braking, cruise control, electric power steering, audio systems, power windows, power doors, power mirror adjustment, battery, recharging systems for hybrid/electric cars, environmental control systems, entertainment, auto start stop systems, blind spot monitoring, lane keeping assist systems, collision avoidance systems, and more complex systems in the case of autonomous, or semi-autonomous vehicles.

ECUs are arranged to generate and/or consume messages, where the messages can include data or commands. Specifically, ECUs can convey messages via communication bus <NUM>. In particular, this figure depicts a number of messages (MSGs), such as, message 108a, message 108b, message 108c, and message 108d. The number of messages is depicted for purposes of clarity and ease of explanation. Additionally, each of ECUs 102a, 102b, and 102c are coupled to communication bus <NUM> at different connection points. For example, ECU 102a couples to communication bus <NUM> at connection point 110a, ECU 102b couples to communication bus <NUM> at connection point 110b, and ECU 102c couples to communication bus <NUM> at connection point 110a. During operation, one of ECUs 102a, 102b, or 102c may be malicious. For example, ECU 102c may transmit a malicious message with a glitch such that the other ECUs (e.g., ECU 102a and ECU 102b) receive different bits due to their sampling the voltage levels of the communication bus <NUM> at different points in time.

Attack prevention device <NUM> is arranged to mitigate such attacks. To this end, attack prevention device <NUM> couples to bus at connection point 110d and includes processing circuitry <NUM>, sampling circuitry <NUM>, and memory <NUM>. Memory <NUM> includes instructions <NUM> (e.g., firmware, or the like) that can be executed by processing circuitry <NUM> and/or sampling circuitry <NUM>. During operation, sampling circuitry <NUM> can sample voltage levels on communication bus <NUM> at connection point 110d at multiple points in time, resulting in sampled voltages <NUM>. Further, processing circuitry <NUM> can execute instructions <NUM> to identify a glitch style attack based on sampled voltages <NUM> and processing circuitry <NUM> and/or sampling circuitry <NUM> can execute instructions <NUM> to apply mitigation actions (e.g., adjust the voltage levels on communication bus <NUM>, or the like) to either correct the received messages or to corrupt the received messages. This is described in greater detail below.

Processing circuitry <NUM> can include any of a variety of processors, such as, for example, commercial central processing units, application specific integrated circuits, or the like. Processing circuitry <NUM> can be a microprocessor or a commercial processor and can include one or multiple processing core(s) and can also include cache. Sampling circuitry <NUM> can include circuitry such as, analog to digital converters, voltage measurement circuitry, voltage waveform observation circuitry (e.g., oscilloscope circuitry, or the like) arranged to sample voltage levels on communication bus <NUM> and to control or drive voltage levels on communication bus <NUM>.

Memory <NUM> can be based on any of a wide variety of information storage technologies. For example, memory <NUM> can be based on volatile technologies requiring the uninterrupted provision of electric power or non-volatile technologies that do not require and possibly including technologies entailing the use of machine-readable storage media that may or may not be removable. Thus, each of these storages may include any of a wide variety of types (or combination of types) of storage devices, including without limitation, read-only memory (ROM), random-access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDR-DRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory (e.g., ferroelectric polymer memory), ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, one or more individual ferromagnetic disk drives, or a plurality of storage devices organized into one or more arrays (e.g., multiple ferromagnetic disk drives organized into a Redundant Array of Independent Disks array, or RAID array). Additionally, memory <NUM> can include storage devices.

<FIG> illustrates system <NUM>, which is a portion of system <NUM> of <FIG> in more detail. In particular, system <NUM> can correspond to a centralized attack mitigation system. That is, attack prevention device <NUM> and particularly sampling circuitry <NUM> can be coupled anywhere on <NUM> relative to the other nodes (e.g., ECUs 102a, 102b, and 102c). Further, as depicted, communication bus <NUM> can comprise a pair of conductors, such as conductor <NUM> and conductor <NUM>. During operation, ECUs (e.g., ECU 102a, ECU 102b, ECU 102c, or the like) can communicate signals via conductor <NUM> and conductor <NUM> (e.g., at sampling points 110a, 110b, and 110a) while sampling circuitry <NUM> can observe and/or control analog voltages on conductor <NUM> and conductor <NUM> (e.g., at connection point 110d). It is noted that although a two-conductor bus is depicted herein, the present disclosure is applicable to multiple different bus structures, such as, those with a single conductor or more than two conductors.

<FIG> illustrates system <NUM>, which can be a portion of system <NUM> of <FIG> in more detail. In particular, system <NUM> can correspond to a distributed attack mitigation system. That is, attack prevention device <NUM> and particularly sampling circuitry <NUM> is coupled between a protected node (e.g., ECU 102a) and the communication bus <NUM>. Systems <NUM> and <NUM> are described in greater detail below. However, prior to that example voltage waveforms and glitches are described.

As a specific example, communication bus <NUM> can be an IVN comprising a CANH conductor (e.g., conductor <NUM>) and a CANL conductor (e.g., conductor <NUM>). Accordingly, <FIG> illustrates graph <NUM>, showing example waveforms <NUM> undergoing voltage transitions. Although the present disclosure can be implemented for IVNs (e.g., the CAN bus, or the like) and the waveforms <NUM> are described with reference to the CAN bus, examples are not limited in this regard. <FIG> depicts nominal recessive and dominant bus voltages for a CAN bus. The CAN bus is comprised of two conductors, as such two waveforms <NUM> are depicted.

When an ECU (e.g., ECU 102a, ECU 102b, ECU 102c, or the like) sends a <NUM> bit, it does so by increasing a first voltage (VCANH coupled to CANH) to at least VCANH0 and decreasing a second voltage (VCANL coupled to CANL) to at least VCANL0. For example, VCANH0 may be about <NUM> volts (V), while the VCANL0 may be about <NUM>. It is noted that the term "about" may mean within a threshold value (e.g., as specified by the CAN standard, such as, CAN Specification version <NUM> promulgated by Bosch GmbH) and can be dependent upon the bus standard, which may dictate the tolerance. In the recessive state, either the CAN bus (e.g., communication bus <NUM>) is idle or an ECU is transmitting a logic <NUM>. In the dominant state, at least one ECU is transmitting a logic <NUM>. Thus, each waveform on the CAN bus can go through a number of voltage transitions.

These voltage transitions are measured as a voltage over time and correspond to a portion of the overall voltage waveform. In particular, waveforms <NUM> can have a rising edge transition <NUM> or a falling edge transition <NUM>. Additionally, waveforms <NUM> can have a steady state transition <NUM> and a steady state transition <NUM>. That is, waveforms <NUM> can have a steady state transition <NUM> for both the recessive state as well as a steady state transition <NUM> for the dominant state. To send a message (e.g., message <NUM>, message <NUM>, message <NUM>, message <NUM>, or the like) on the CAN bus, an ECU must cause a number of voltage transitions (e.g., rising edge transition <NUM>, falling edge transition <NUM>, steady state transition <NUM>, and/or steady state transition <NUM>) on the CAN bus to communicate bits indicating the contents of the message. Accordingly, during operation, analog voltage waveforms corresponding to messages (e.g., messages 108a 108b, 108c, etc.) can be observed on conductor(s) of communication bus <NUM>.

Although the present disclosure (e.g., <FIG> and <FIG>, etc.) reference a CAN bus with dominant and recessive voltage levels, the present disclosure can be applied to other types of busses, for example, pull-up and/or pull-down busses, on-chip busses, etc. Examples are not limited in this context.

<FIG> illustrates a voltage waveform <NUM>, associated with a glitch style attack, in accordance with non-limiting example(s) of the present disclosure. Voltage waveform <NUM> can be transmitted over a number of time periods 502a, 502b, 502c, 502d, 502e, and 502f and sampled by receiving ECUs (e.g., ECU 102a and ECU 102b) during each of time periods 502a, 502b, 502c, 502d, 502e, and 502f at respective connection points 110a and 110b. It is noted that voltage waveform <NUM> can correspond to voltage waveforms transmitted on a bus (e.g., CANH conductor of a bus, CANL conductor of a bus, or the like) and as such, may not necessarily correspond to a particular binary value. However, for ease of description, the high voltage level (e.g., the dominant CANH voltage) may be referred to as logic <NUM> while the lower voltage level (e.g., the recessive CANH voltage) may be referred to as logic <NUM>, without limiting the claims. It is to be appreciated that alternative voltage levels and corresponding digital representations may be practiced. Voltage waveform <NUM> further depicts glitches during time periods 502c and 502d. For example, glitch 504a depicts a recessive glitch where a malicious ECU (e.g., ECU 102c, or the like) allows the voltage level of the bus (e.g., communication bus <NUM>) to drop from the dominant level to the recessive level during the glitch 504a. Similarly, glitch 504b depicts a dominant glitch where a malicious ECU (e.g., ECU 102c, or the like) drives the voltage level of the bus (e.g., communication bus <NUM>) from the recessive level to dominant level during the glitch 504b.

ECUs 102a and 102b sampling voltage waveform at connection points 110a and 110b would receive a series of bits that each appear correct from the perspective of the receiving ECUs 102a and 102b, but which are in fact different from each other. For example, ECU 102a would receive bit series [<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>] while ECU 102b would receive bit series [<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>]. As such, receiving ECUs 102a and 102b would receive different messages based on voltage waveform <NUM>.

<FIG> illustrates a method <NUM> for mitigating a glitch style attack, in accordance with non-limiting example(s) of the present disclosure. Method <NUM> can be implemented by an attack prevention device, such as, attack prevention device <NUM> of system <NUM>. In particular, method <NUM> can be implemented by attack prevention device <NUM> to mitigate glitch attacks perpetrated by one of ECUs 102a, 102b, or 102c against the other ECUs. It is noted that methods (or logic flows) described herein, including method <NUM> and other methods described herein, are representative of exemplary methodologies for performing novel aspects of the disclosed architecture. While, for purposes of simplicity of explanation, the one or more methodologies shown herein, for example, in the form of a flow chart or flow diagram, are shown and described as a series of acts, it is to be understood and appreciated that the methodologies are not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.

Method <NUM> can begin at block <NUM>. At block <NUM> "sample, by circuitry of an attack prevention device, a voltage waveform at a point on a communication bus, the communication bus coupled to a number of electronic control units (ECUs)" a voltage waveform can be sampled at point on a communication bus where the communication bus is coupled to a number of ECUs. For example, attack prevention device <NUM> can sample voltage levels on communication bus <NUM> at connection point 110d. In particular, processing circuitry <NUM> and/or sampling circuitry <NUM> can execute instructions <NUM> to sample voltage levels on communication bus <NUM> at connection point 110d. With some implementations, attack prevention device <NUM> repeatedly (e.g., on a fixed period, or the like) samples voltage levels on communication bus <NUM> at connection point 110d to generate sampled voltages <NUM>.

Continuing to block <NUM> "identify a glitch in the voltage waveform" a glitch in the voltage waveform can be identified. For example, attack prevention device <NUM> can detect a glitch in the voltage waveform transmitted on communication bus <NUM> based on sampled voltages <NUM>. For example, processing circuitry <NUM> and/or sampling circuitry <NUM> can execute instructions <NUM> to identify a glitch (e.g., glitch 504a, glitch 504b, etc.) based on sampled voltages <NUM>.

Continuing to method <NUM> "modify the voltage level on the communication bus to mitigate effects of the glitch on received messages" the voltage level on the bus can be modified to mitigate effects of the glitch identified at block <NUM>. For example, attack prevention device <NUM> can modify the voltage level on communication bus <NUM> to mitigate effects from the identified glitch (see <FIG>). That is, processing circuitry <NUM> and/or sampling circuitry <NUM> can execute instructions <NUM> to modify voltage levels on communication bus <NUM> to mitigate the effects from the glitch identified based on <NUM>. As a specific example, processing circuitry <NUM> and/or sampling circuitry <NUM> can execute instructions <NUM> to drive detected recessive bits on the communication bus <NUM> to the dominant voltage level to corrupt any received messages based on an identified glitch (e.g., an identified recessive glitch, or the like). As another example, processing circuitry <NUM> and/or sampling circuitry <NUM> can execute instructions <NUM> to execute method <NUM> at method <NUM>.

<FIG> illustrates a method <NUM> for adjusting voltage levels on a bus to mitigate effects of an identified glitch attack, in accordance with non-limiting example(s) of the present disclosure. Method <NUM> can be implemented by attack prevention device <NUM> operating in a centralized manner, such as, for example, system <NUM> of <FIG>. Method <NUM> can begin at decision block <NUM>. At decision block <NUM> "is the glitch a recessive glitch?" a determination whether the glitch is a recessive glitch is made. For example, attack prevention device <NUM> can determine whether the glitch (e.g., identified at block <NUM> of method <NUM>, or the like) is a recessive glitch (e.g., like glitch 504a) or not. From decision block <NUM>, method <NUM> can continue to either block <NUM> or block <NUM>. For example, method <NUM> can continue from decision block <NUM> to block <NUM> based on a determination that the glitch is a recessive glitch while method <NUM> can continue from decision block <NUM> to block <NUM> based on a determination that the glitch is not a recessive glitch.

At block <NUM> "overdrive the voltage level on the bus to force the voltage level to stay dominant" the voltage level on the bus can be overdriven to stay at the dominant level. For example, attack prevention device <NUM> can overdrive the malicious ECU to force the voltage level on communication bus <NUM> to stay dominant for the entire duration of time periods. In particular, processing circuitry <NUM> and/or sampling circuitry <NUM> can execute instructions <NUM> to drive voltage levels on communication bus <NUM> to the dominant level to overdrive the glitch 504a by the malicious ECU. For example, <FIG> depicts voltage waveform 800a, which is like voltage waveform <NUM> except that the voltage level is overdriven during time period 502c to correct glitch 504a, resulting in voltage level overdrive <NUM> and corrected dominant glitch <NUM>.

At block <NUM> "identify the next recessive bit(s)" the next number of recessive bits can be identified. For example, attack prevention device <NUM> can identify the next recessive bit transmitted on communication bus <NUM>, the next two (<NUM>) recessive bits transmitted on communication bus <NUM>, the next three (<NUM>) recessive bits transmitted on communication bus <NUM>, or the like. In particular, processing circuitry <NUM> and/or sampling circuitry <NUM> can execute instructions <NUM> to cause processing circuitry <NUM> and/or sampling circuitry <NUM> to sample voltage levels on communication bus <NUM> to identify the next number of recessive bits on communication bus <NUM>.

Continuing to block <NUM> "overdrive the recessive bit(s) to corrupt the received messages" the number of identified recessive bits can be overdriven to corrupt any received messages. For example, attack prevention device <NUM> can overdrive the identified recessive bits to force the voltage level to be dominant during the time in which the recessive bit(s) are transmitted on communication bus <NUM>, which will corrupt any received messages. In particular, processing circuitry <NUM> and/or sampling circuitry <NUM> can overdrive the voltage levels on communication bus <NUM> during the time in which the recessive bits are identified to corrupt messages received based on the recessive bits and the identified glitch 504b. For example, <FIG> depicts voltage waveform 800a, which is like voltage waveform <NUM> except that the voltage level of the recessive bit after glitch 504b (e.g., time period 502f) is overdriven (e.g., voltage level overdrive <NUM>) resulting in corruption of the received messages.

<FIG> illustrates a method <NUM> for adjusting voltage levels on a bus to mitigate effects of an identified glitch attack, in accordance with non-limiting example(s) of the present disclosure. Method <NUM> can be implemented by attack prevention device <NUM> operating in a distributed manner, such as, for example, system <NUM> of <FIG>. Method <NUM> can begin like method <NUM>, with decision block <NUM>. From decision block <NUM>, method <NUM> can continue to either block <NUM> or block <NUM>. For example, method <NUM> can continue from decision block <NUM> to block <NUM> based on a determination that the glitch is a recessive glitch while method <NUM> can continue from decision block <NUM> to block <NUM> based on a determination that the glitch is not a recessive glitch.

Block <NUM> of method <NUM> can be like block <NUM> of method <NUM>, where the voltage level on the bus can be overdriven to stay at the dominant level. For example, attack prevention device <NUM> can overdrive the malicious ECU to force the voltage level on communication bus <NUM> to stay dominant for the entire duration of time periods. In particular, processing circuitry <NUM> and/or sampling circuitry <NUM> can execute instructions <NUM> to drive voltage levels on communication bus <NUM> to the dominant level to overdrive the glitch 504a by the malicious ECU.

At block <NUM> "overwrite the voltage level to the protected node to correct the recessive glitch" the voltage level to the protected node can be overwritten to correct the recessive glitch. For example, attack prevention device <NUM> can overwrite the voltage level on communication bus <NUM> such the voltage level received by the protected node (e.g., ECU 102a) is recessive. This is depicted in <FIG>, which illustrates voltage waveform 800b. In particular, at block <NUM> processing circuitry <NUM> and/or sampling circuitry <NUM> can execute instructions <NUM> to cause voltage level overwrite <NUM> in time period 502d to such that glitch 504b is corrected dominant glitch <NUM> and ECU 102a receives a recessive voltage level in time period 502d as intended. It is noted that at block <NUM>, the voltage level on the communication bus <NUM> is not overwritten and as such, other ECUs (e.g., ECU 102b and/or ECU 102c) besides the protected ECU (e.g., ECU 102a) may sample the voltage level at the glitch 504b.

It is important to note that voltage level overdrive <NUM> may be applied after an initial stabilization period of each time period (e.g., time period 502a, etc.). For example, attack prevention device <NUM> can repeatedly sample voltage levels on communication bus <NUM> during each time period and after the voltage level has stabilized identify glitches and adjust voltage levels as outlined herein.

<FIG> illustrates a method <NUM> for mitigating an attack against a glitch style attack mitigation defense such as proposed in the present disclosure, in accordance with non-limiting example(s) of the present disclosure. Method <NUM> can be implemented by an attack prevention device, such as, attack prevention device <NUM> of system <NUM>. In particular, method <NUM> can be implemented by attack prevention device <NUM> to defend against attacks on a glitch attack mitigation defense perpetrated by one of ECUs 102a, 102b, or 102c against the attack prevention device <NUM> of system <NUM>.

Continuing to block <NUM> "identify multiple glitches in the voltage waveform" a number of glitches in the voltage waveform can be identified. For example, attack prevention device <NUM> can detect multiple glitches in the voltage waveform transmitted on communication bus <NUM> based on sampled voltages <NUM>. Said differently, attack prevention device <NUM> can detect instability in the stable region of the voltage waveform, indicative of multiple repeated glitches. For example, processing circuitry <NUM> and/or sampling circuitry <NUM> can execute instructions <NUM> to identify multiple glitches (e.g., like glitch 504a, like glitch 504b, etc.) in a single time period, within a threshold distance from each other, or the like.

Continuing to block <NUM> "identify the next recessive bit(s)" the next number of recessive bits can be identified. For example, attack prevention device <NUM> can identify the next recessive bit transmitted on communication bus <NUM>, the next two (<NUM>) recessive bits transmitted on communication bus <NUM>, the next three (<NUM>) recessive bits transmitted on communication bus <NUM>, or the like. In particular, processing circuitry <NUM> and/or sampling circuitry <NUM> can execute instructions <NUM> to cause processing circuitry <NUM> and/or sampling circuitry <NUM> to sample voltage levels on communication bus <NUM> to identify the next number of recessive bits on communication bus <NUM>.

Continuing to block <NUM> "overwrite the recessive bit(s) to corrupt the received messages" the number of identified recessive bits can be overwritten to corrupt any received messages. For example, attack prevention device <NUM> can overwrite the identified recessive bits to force the voltage level to be dominant during the time in which the recessive bit(s) are transmitted on communication bus <NUM>, which will corrupt any received messages. In particular, processing circuitry <NUM> and/or sampling circuitry <NUM> can overwrite the voltage levels on communication bus <NUM> during the time in which the recessive bits are identified to corrupt messages received based on the recessive bits and the identified glitches.

<FIG> illustrates an example of a storage device <NUM>. Storage device <NUM> may comprise an article of manufacture, such as, any non-transitory computer readable medium or machine readable medium, such as an optical, magnetic or semiconductor storage. Storage device <NUM> may store various types of computer executable instructions <NUM>, such as instructions to implement method <NUM>, method <NUM>, method <NUM> and/or method <NUM>. Examples of a computer readable or machine-readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of computer executable instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like. The examples are not limited in this context.

<FIG> illustrates an in-vehicle communication architecture <NUM> according to one or more embodiments of the disclosure. For example, one or more vehicular devices, components, or circuits, such as circuitry <NUM> and/or circuitry <NUM>, may communicate with each other via a communications communication framework <NUM>, which may be an in-vehicle network, such as a CAN bus, implemented to facilitate glitch attack mitigation as described above.

The in-vehicle communication architecture <NUM> includes various common communications elements, such as a transmitter, receiver, transceiver, and so forth. The embodiments, however, are not limited to implementation by the in-vehicle communication architecture <NUM>. As shown in this figure, the vehicular circuitry <NUM> and circuitry <NUM> may each be operatively connected to one or more respective data devices, such as, data device <NUM> and/or data device <NUM> that can be employed to store information local to the respective circuitry <NUM> and/or circuitry <NUM>, such as fingerprints, distributions, densities, voltage signals, or the like. It may be understood that the circuitry <NUM> and circuitry <NUM> may be any suitable vehicular component, such as sensor, an ECU, microcontroller, microprocessor, processor, ASIC, field programmable gate array (FPGA), any electronic device, computing device, or the like. Moreover, it may be understood that one or more computing devices (containing at least a processor, memory, interfaces, etc.) may be connected to the communication framework <NUM> in a vehicle.

Further, the communication framework <NUM> may implement any well-known communications techniques and protocols. As described above, the communication framework <NUM> may be implemented as a CAN bus protocol or any other suitable in-vehicle communication protocol. The communication framework <NUM> may also implement various network interfaces arranged to accept, communicate, and connect to one or more external communications networks (e.g., Internet). A network interface may be regarded as a specialized form of an input/output (I/O) interface. Network interfaces may employ connection protocols including without limitation direct connect, Ethernet (e.g., thick, thin, twisted pair <NUM>/<NUM>/<NUM> Base T, and the like), token ring, wireless network interfaces, cellular network interfaces, IEEE <NUM>. 7a-x network interfaces, IEEE <NUM> network interfaces, IEEE <NUM> network interfaces, and the like. Further, multiple network interfaces may be used to engage with various communications network types. The communication framework <NUM> may employ both wired and wireless connections.

<FIG> illustrates an embodiment of a system <NUM>. System <NUM> is a computer system with multiple processor cores such as a distributed computing system, supercomputer, high-performance computing system, computing cluster, mainframe computer, mini-computer, client-server system, personal computer (PC), workstation, server, portable computer, laptop computer, tablet computer, handheld device such as a personal digital assistant (PDA), or other device for processing, displaying, or transmitting information. Similar embodiments may comprise, e.g., entertainment devices such as a portable music player or a portable video player, a smart phone or other cellular phone, a telephone, a digital video camera, a digital still camera, an external storage device, or the like. Further embodiments implement larger scale server configurations. In other embodiments, the system <NUM> may have a single processor with one core or more than one processor. Note that the term "processor" refers to a processor with a single core or a processor package with multiple processor cores. In at least one embodiment, the computing system <NUM> is representative of the components of system <NUM>. More generally, the computing system <NUM> is configured to implement all logic, systems, logic flows, methods, apparatuses, and functionality described herein with reference to <FIG>.

As used in this application, the terms "system" and "component" and "module" are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary system <NUM>. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the uni-directional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various
connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

As shown in this figure, system <NUM> comprises a motherboard or system-on-chip (SoC) <NUM> for mounting platform components. Motherboard or system-on-chip (SoC) <NUM> is a point-to-point (P2P) interconnect platform that includes a first processor <NUM> and a second processor <NUM> coupled via a point-to-point interconnect <NUM> such as an Ultra Path Interconnect (UPI). In other embodiments, the system <NUM> may be of another bus architecture, such as a multi-drop bus. Furthermore, each of processor <NUM> and processor <NUM> may be processor packages with multiple processor cores including core(s) <NUM> and core(s) <NUM>, respectively. While the system <NUM> is an example of a two-socket (<NUM>) platform, other embodiments may include more than two sockets or one socket. For example, some embodiments may include a four-socket (<NUM>) platform or an eight-socket (<NUM>) platform. Each socket is a mount for a processor and may have a socket identifier. Note that the term platform refers to the motherboard with certain components mounted such as the processor <NUM> and chipset <NUM>. Some platforms may include additional components and some platforms may only include sockets to mount the processors and/or the chipset. Furthermore, some platforms may not have sockets (e.g., SoC, or the like).

The processor <NUM> and processor <NUM> can be any of various commercially available processors, including without limitation an Intel® Celeron®, Core®, Core (<NUM>) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors; AMD® Athlon®, Duron® and Opteron® processors; ARM® application, embedded and secure processors; IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and Sony® Cell processors; and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be employed as the processor <NUM> and/or processor <NUM>. Additionally, the processor <NUM> need not be identical to processor <NUM>.

Processor <NUM> includes an integrated memory controller (IMC) <NUM> and point-to-point (P2P) interface <NUM> and P2P interface <NUM>. Similarly, the processor <NUM> includes an IMC <NUM> as well as P2P interface <NUM> and P2P interface <NUM>. IMC <NUM> and IMC <NUM> couple the processors processor <NUM> and processor <NUM>, respectively, to respective memories (e.g., memory <NUM> and memory <NUM>). Memory <NUM> and memory <NUM> may be portions of the main memory (e.g., a dynamic random-access memory (DRAM)) for the platform such as double data rate type <NUM> (DDR3) or type <NUM> (DDR4) synchronous DRAM (SDRAM). In the present embodiment, the memories memory <NUM> and memory <NUM> locally attach to the respective processors (i.e., processor <NUM> and processor <NUM>). In other embodiments, the main memory may couple with the processors via a bus and shared memory hub.

System <NUM> includes chipset <NUM> coupled to processor <NUM> and processor <NUM>. Furthermore, chipset <NUM> can be coupled to storage device <NUM>, for example, via an interface (I/F) <NUM>. The I/F <NUM> may be, for example, a Peripheral Component Interconnect-enhanced (PCI-e). Storage device <NUM> can store instructions executable by circuitry of system <NUM> (e.g., processor <NUM>, processor <NUM>, GPU <NUM>, ML accelerator <NUM>, vision processing unit <NUM>, or the like). For example, storage device <NUM> can store instructions for method <NUM> and/or method <NUM>, or the like.

Processor <NUM> couples to a chipset <NUM> via P2P interface <NUM> and P2P <NUM> while processor <NUM> couples to a chipset <NUM> via P2P interface <NUM> and P2P <NUM>. Direct media interface (DMI) <NUM> and DMI <NUM> may couple the P2P interface <NUM> and the P2P <NUM> and the P2P interface <NUM> and P2P <NUM>, respectively. DMI <NUM> and DMI <NUM> may be a highspeed interconnect that facilitates, e.g., eight Giga Transfers per second (GT/s) such as DMI <NUM>. In other embodiments, the processor <NUM> and processor <NUM> may interconnect via a bus.

The chipset <NUM> may comprise a controller hub such as a platform controller hub (PCH). The chipset <NUM> may include a system clock to perform clocking functions and include interfaces for an I/O bus such as a universal serial bus (USB), peripheral component interconnects (PCIs), serial peripheral interconnects (SPIs), integrated interconnects (I2Cs), and the like, to facilitate connection of peripheral devices on the platform. In other embodiments, the chipset <NUM> may comprise more than one controller hub such as a chipset with a memory controller hub, a graphics controller hub, and an input/output (I/O) controller hub.

In the depicted example, chipset <NUM> couples with a trusted platform module (TPM) <NUM> and UEFI, BIOS, FLASH circuitry <NUM> via I/F <NUM>. The TPM <NUM> is a dedicated microcontroller designed to secure hardware by integrating cryptographic keys into devices. The UEFI, BIOS, FLASH circuitry <NUM> may provide pre-boot code.

Furthermore, chipset <NUM> includes the I/F <NUM> to couple chipset <NUM> with a high-performance graphics engine, such as, graphics processing circuitry or a graphics processing unit (GPU) <NUM>. In other embodiments, the system <NUM> may include a flexible display interface (FDI) (not shown) between the processor <NUM> and/or the processor <NUM> and the chipset <NUM>. The FDI interconnects a graphics processor core in one or more of processor <NUM> and/or processor <NUM> with the chipset <NUM>. Additionally, ML accelerator <NUM> and/or vision processing unit <NUM> can be coupled to chipset <NUM> via I/F <NUM>. ML accelerator <NUM> can be circuitry arranged to execute ML related operations (e.g., training, inference, etc.) for ML models. Likewise, vision processing unit <NUM> can be circuitry arranged to execute vision processing specific or related operations. In particular, ML accelerator <NUM> and/or vision processing unit <NUM> can be arranged to execute mathematical operations and/or operands useful for machine learning, neural network processing, artificial intelligence, vision processing, etc..

Various I/O devices <NUM> and display <NUM> couple to the bus <NUM>, along with a bus bridge <NUM> which couples the bus <NUM> to a second bus <NUM> and an I/F <NUM> that connects the bus <NUM> with the chipset <NUM>. In one embodiment, the second bus <NUM> may be a low pin count (LPC) bus. Various devices may couple to the second bus <NUM> including, for example, a keyboard <NUM>, a mouse <NUM> and communication devices <NUM>.

Furthermore, an audio I/O <NUM> may couple to second bus <NUM>. Many of the I/O devices <NUM> and communication devices <NUM> may reside on the motherboard or system-on-chip (SoC) <NUM> while the keyboard <NUM> and the mouse <NUM> may be add-on peripherals. In other embodiments, some or all the I/O devices <NUM> and communication devices <NUM> are add-on peripherals and do not reside on the motherboard or system-on-chip (SoC) <NUM>.

The components and features of the devices described above may be implemented using any combination of processing circuitry, discrete circuitry, application specific integrated circuits (ASICs), logic gates and/or single chip architectures, etc. Further, the features of the devices may be implemented using microcontrollers, programmable logic arrays and/or microprocessors or any combination of the foregoing where suitably appropriate. It is noted that hardware, firmware and/or software elements may be collectively or individually referred to herein as "logic" or "circuit.

Some embodiments may be described using the expression "one embodiment" or "an embodiment" along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Further, some embodiments may be described using the expression "coupled" and "connected" along with their derivatives.

It is emphasized that the Abstract of the Disclosure is provided to allow a reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment. In the appended claims, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "wherein," respectively. Moreover, the terms "first," "second," "third," and so forth, are used merely as labels, and are not intended to impose numerical requirements on their objects.

Claim 1:
A method, comprising:
sampling, by circuitry of an attack prevention electronic control unit (ECU), a voltage waveform on a communication bus, the communication bus coupled to a plurality of ECUs, wherein sampling the voltage waveform comprises:
iteratively sampling the voltage level on the communication bus over a period of time to generate a plurality of voltage level samples; and
generating the voltage waveform from the plurality of voltage level samples;
identifying a glitch in the voltage waveform comprising determining whether the voltage level during a portion of the period of time unexpectedly changes; and
modifying the voltage level on the communication bus based on the glitch comprising:
identifying a recessive voltage level on the communication bus, and
overdriving the voltage level on the communication bus to change the recessive voltage level to a dominant voltage level.