Patent Application
20200042750
The present disclosure relates generally to serial communication over a shared serial bus and, more particularly, to protecting devices from unauthorized access prior to security procedures being implemented by a bootloader.
Mobile communication devices may include a variety of components including circuit boards, integrated circuit (IC) devices and/or System-on-Chip (SoC) devices. The components may include processing devices, user interface components, storage and other peripheral components that communicate through a shared data communication bus, which may include a multi-drop serial bus or a parallel bus. General-purpose serial interfaces known in the industry include the Inter-Integrated Circuit (I2C or I2C) serial bus and its derivatives and alternatives. The Mobile Industry Processor Interface (MIPI) Alliance defines standards for I3C, the Radio Frequency Front-End (RFFE) interface and other interfaces.
In one example, the I3C serial bus may be used to connect sensors and other peripherals to a processor. In some implementations, multiple bus masters are coupled to the serial bus such that two or more devices can serve as bus master for different types of messages transmitted on the serial bus. In another example, the RFFE interface defines a communication interface for controlling various radio frequency (RF) front-end devices, including power amplifier (PA), low-noise amplifiers (LNAs), antenna tuners, filters, sensors, power management devices, switches, etc. These devices may be collocated in a single IC device or provided in multiple IC devices. In a mobile communications device, multiple antennas and radio transceivers may support multiple concurrent RF links In another example, system power management interface (SPMI) defined by the MIPI Alliance provides a hardware interface that may be implemented between baseband or application processors and peripheral components. In some implementations, the SPMI is deployed to support power management operations within a device.
Many electronic devices include multiple components that may communicate with each other over a bus. One such example, is a system that includes a plurality of devices that use a System Power Management Interface (SPMI) to communicate over a two line serial bus. In such systems one device may operate as a “master” while other devices may operate as “slaves”, where the master is the sender of communications over the bus. In some systems, the “master” device may dynamically change such that any device coupled to the bus may become a “master” device. During boot-up, security of the devices on the bus is often setup during a boot loader security procedure (e.g., a secondary boot loader). However, prior to such security being established, the devices on the bus may be susceptible to rogue software making unwanted changes to the system (i.e., accessing and changing the devices on the bus).
Therefore, there is a need for a process to secure devices coupled to the bus during the time when the secondary boot loader has not yet setup.
A first aspect provides a device including a storage device and a communication circuit. The storage device may include an access block with a list of device addresses with which the device is either permitted or not permitted to communicate over a shared bus prior to a bootloader procedure being initiated on the device. The communication circuit may be adapted to: (a) obtain a first command to be transmitted over the shared bus to a first device address; (b) determine whether the first device address is in the list of device addresses in the access block; (c) allow or prevent transmission of the first command over the shared bus based on whether the first device address is in the list of device addresses; and/or (d) bypass or ignore the determination of whether the first device address is in the list of device addresses after the bootloader procedure is completed. The bootloader procedure may include a security procedure executed after a basic input/output system (BIOS) is loaded for the device.
In one example, allowing or preventing transmission of the first command includes: transmit the first command if: (a) the first device address is in the list of device addresses with which the device is permitted to communicate; or (b) the first device address is not in the list of device addresses with which the device is not permitted to communicate; and terminating transmission of the first command if: (c) the first device address is in the list of device addresses with which the device is not permitted to communicate; or (d) the first device address is not in the list of device addresses with which the device is permitted to communicate.
In some implementations, the first command may be one of a read or write command from/to a register in another device associated with the first device address.
In some examples, each device address in the list of device addresses may define: (a) one or more devices, (b) one or more register addresses, and/or (c) one or more ranges of addresses.
According to another example, the communication circuit may be further adapted to: (A) receive a second command over the shared bus from another device having a second device address; (B) determine whether the second device address is in the list of device addresses in the access block; an/or (C) terminate processing of the second command if: (a) the second device address is in the list of device addresses with which the device is not permitted to communicate; or (b) the second address is not in the list of device addresses with which the device is permitted to communicate.
Additionally, the communication circuit may be further adapted to: transmit the second command if: (a) the second device address is in the list of device addresses with which the device is permitted to communicate; or (b) the second device address is not in the list of device addresses with which the device is not permitted to communicate.
The second command may be one of a read or write command from/to a register in the device associated with the second device address.
The communication circuit may be a System Power Management Interface (SPMI).
A second aspect provides a method, comprising: (A) storing an access block with a list of device addresses with which a device is either permitted or not permitted to communicate over a shared bus prior to a bootloader procedure being initiated on the device; (B) obtaining, at a communication circuit, a first command to be transmitted over the shared bus to a first device address; (C) determining whether the first device address is in the list of device addresses in the access block; (D) allowing or preventing transmission of the first command over the shared bus based on whether the first device address is in the list of device addresses, and/or (E) bypassing or ignoring the determination of whether the first device address is in the list of device addresses after the bootloader procedure is completed. The bootloader procedure may be a security procedure executed after a basic input/output system (BIOS) is loaded for the device.
According to one example, allowing or preventing transmission of the first command may include transmiting the first command if: (a) the first device address is in the list of device addresses with which the device is permitted to communicate; or (b) the first device address is not in the list of device addresses with which the device is not permitted to communicate; and terminating transmission of the first command if: (c) the first device address is in the list of device addresses with which the device is not permitted to communicate; or (d) the first device address is not in the list of device addresses with which the device is permitted to communicate. The first command may be one of a read or write command from/to a register in another device associated with the first device address. In some example, each device address in the list of device addresses may define: (a) one or more devices, (b) one or more register addresses, and/or (c) one or more ranges of addresses.
Additinally, the method may further comprise: (a) receiving a second command over the shared bus from another device having a second device address; and/or (b) determining whether the second device address is in the list of device addresses in the access block. The processing of the second command may be terminated if: (a) the second device address is in the list of device addresses with which the device is not permitted to communicate; or (b) the second address is not in the list of device addresses with which the device is permitted to communicate. Moreover, the method may further comprise: processing the second command if: (a) the second device address is in the list of device addresses with which the device is permitted to communicate; or (b) the second device address is not in the list of device addresses with which the device is not permitted to communicate. In one example, the communication circuit may be a System Power Management Interface (SPMI).
The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring such concepts.
Several aspects of the invention will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively referred to as “elements”). These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.
Devices that include multiple SoC and other IC devices often employ a shared communication interface that may include a serial bus or other data communication link to connect processors with modems and other peripherals. The serial bus or other data communication link may be operated in accordance with multiple standards or protocols defined. For example, the serial bus may be operated in accordance with an I2C, I3C, SPMI, and/or RFFE protocol, or other protocol that may be configured for half-duplex operation. Increased utilization of serial buses, and/or the imposition of more stringent timing constraints in support of applications, peripherals and sensors can result in demand for reduced transmission latencies. Transmission latency may include the time required to terminate a transaction in process on the serial bus, bus turnaround (between transmit mode and receive mode), bus arbitration and/or command transmissions specified by protocol.
In order to mitigate or prevent the device coupled to a shared bus of a host system from being accessed/changed by rogue software prior to security being established on the host system, a device may be pre-configured (or pre-loaded) with access control blocks that define addresses (e.g., device addresses and/or register addresses or address ranges) with which the device is permitted or not permitted to communicate. Such addresses may identify other devices on the bus, register addresses, and/or groups of devices/registers on the bus. Consequently, when a command is generated or received at a device, the address in the command is checked to see if the address is identified in the access control block (either as permitted or not permitted). The command is blocked if it is a not permitted address or if it is absent from the permitted addresses. This process of checking the access control block and blocking commands may be performed only during a defined period of time (e.g., while the bootloader security procedure has not completed). In various implementations, the blocking of commands using the access control block may be performed at a transmitter circuit, a receiver circuit, and/or a processing circuit which generates a command to be transmitted or which was received over the bus. The checking of the access control block addresses may be disabled or bypassed after the bootloader security procedure is done.
Examples of Apparatus that Employ Serial Data Links
According to certain aspects, a serial data link may be used to interconnect electronic devices that are subcomponents of an apparatus such as a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a notebook, a netbook, a smartbook, a personal digital assistant (PDA), a satellite radio, a global positioning system (GPS) device, a smart home device, intelligent lighting, a multimedia device, a video device, a digital audio player (e.g., MP3 player), a camera, a game console, an entertainment device, a vehicle component, a wearable computing device (e.g., a smart watch, a health or fitness tracker, eyewear, etc.), an appliance, a sensor, a security device, a vending machine, a smart meter, a drone, a multicopter, or any other similar functioning device.
The ASIC 104 may have one or more processors 112, one or more modems 110, on-board memory 114, a bus interface circuit 116 and/or other logic circuits or functions. The processing circuit 102 may be controlled by an operating system that may provide an application programming interface (API) layer that enables the one or more processors 112 to execute software modules residing in the on-board memory 114 or other processor-readable storage 122 provided on the processing circuit 102. The software modules may include instructions/code and data stored in the on-board memory 114 or processor-readable storage 122. The ASIC 104 may access its on-board memory 114, the processor-readable storage 122, and/or storage external to the processing circuit 102. The on-board memory 114, the processor-readable storage 122 may include read-only memory (ROM) or random-access memory (RAM), electrically erasable programmable ROM (EEPROM), flash cards, or any memory device that can be used in processing systems and computing platforms. The processing circuit 102 may include, implement, or have access to a local database or other parameter storage that can maintain operational parameters and other information used to configure and operate the apparatus 100 and/or the processing circuit 102. The local database may be implemented using registers, a database module, flash memory, magnetic media, EEPROM, soft or hard disk, or the like. The processing circuit 102 may also be operably coupled to external devices such as the antenna 124, a display 126, operator controls, such as switches or buttons 128, 130 and/or an integrated or external keypad 132, among other components. A user interface module may be configured to operate with the display 126, keypad 132, etc. through a dedicated communication link or through one or more serial data interconnects.
The processing circuit 102 may provide one or more buses 118a, 118b, 120 that enable certain devices 104, 106, and/or 108 to communicate. In one example, the ASIC 104 may include a bus interface circuit 116 that includes a combination of circuits, counters, timers, control logic and other configurable circuits or modules. In one example, the bus interface circuit 116 may be configured to operate in accordance with communication specifications or protocols. The processing circuit 102 may include or control a power management function that configures and manages the operation of the apparatus 100.
In one example, a master device 202 may include an interface controller 204 that may manage access to the serial bus, configure dynamic addresses for slave devices 2220-222N and/or generate a clock signal 228 to be transmitted on a clock line 218 of the serial bus 220. The master device 202 may include configuration registers 206 or other storage 224, and other control logic 212 configured to handle protocols and/or higher level functions. The control logic 212 may include a processing circuit such as a state machine, sequencer, signal processor or general-purpose processor. The master device 202 includes a transceiver 210 and line drivers/receivers 214a and 214b. The transceiver 210 may include receiver, transmitter and common/shared circuits, where the common/shared circuits may include timing, logic and storage circuits and/or devices. In one example, the transmitter encodes and transmits data based on timing in the clock signal 228 provided by a clock generation circuit 208. Other timing clocks 226 may be used by the control logic 212 and other functions, circuits or modules.
At least one device 2220-222N may be configured to operate as a slave device on the serial bus 220 and may include circuits and modules that support a display, an image sensor, and/or circuits and modules that control and communicate with one or more sensors that measure environmental conditions. In one example, a slave device 2220 configured to operate as a slave device may provide a control function, module or circuit 232 that includes circuits and modules to support a display, an image sensor, and/or circuits and modules that control and communicate with one or more sensors that measure environmental conditions. The slave device 2220 may include configuration registers 234 or other storage 236, control logic 242, a transceiver 240 and line drivers/receivers 244a and 244b. The control logic 242 may include a processing circuit such as a state machine, sequencer, signal processor or general-purpose processor. The transceiver 210 may include receiver, transmitter and common circuits, where the common circuits may include timing, logic and storage circuits and/or devices. In one example, the transmitter encodes and transmits data based on timing in a clock signal 248 provided by clock generation and/or recovery circuits 246. The clock signal 248 may be derived from a signal received from the clock line 218. Other timing clocks 238 may be used by the control logic 242 and other functions, circuits or modules.
The serial bus 220 may be operated in accordance with RFFE, I2C, I3C, SPMI, or other protocols. At least one device 202, 2220-222N may be configured to operate as a master device and a slave device on the serial bus 220. Two or more devices 202, 2220-222N may be configured to operate as a master device on the serial bus 220.
In some implementations, the serial bus 220 may be operated in accordance with an I3C protocol. Devices that communicate using the I3C protocol can coexist on the same serial bus 220 with devices that communicate using I2C protocols. The I3C protocols may support different communication modes, including a single data rate (SDR) mode that is compatible with I2C protocols. High-data-rate (HDR) modes may provide a data transfer rate between 6 megabits per second (Mbps) and 16 Mbps, and some HDR modes may be provide higher data transfer rates. I2C protocols may conform to de facto I2C standards providing for data rates that may range between 100 kilobits per second (kbps) and 3.2 Mbps. I2C and I3C protocols may define electrical and timing aspects for signals transmitted on the 2-wire serial bus 220, in addition to data formats and aspects of bus control. In some aspects, the I2C and I3C protocols may define direct current (DC) characteristics affecting certain signal levels associated with the serial bus 220, and/or alternating current (AC) characteristics affecting certain timing aspects of signals transmitted on the serial bus 220. In some examples, a 2-wire serial bus 220 transmits data on a data line 216 and a clock signal on the clock line 218. In some instances, data may be encoded in the signaling state, or transitions in signaling state of the data line 216 and the clock line 218.
In various examples, the device 302 may be implemented with one or more baseband processors 306, modems 304, RFICs 312, multiple communications links 310, 336, multiple RFFE buses 330, 332, 334 and/or other types of buses. The device 302 may include other processors, circuits, modules and may be configured for various operations and/or different functionalities. In the example illustrated in
The MIPI Alliance system power management interface (SPMI) specifies a hardware interface that may be implemented between baseband or application processors and peripheral components to support a variety of data communication functions including data communication related to power management operations.
In the system 400 illustrated in
Bus latency can affect the ability of a serial bus to handle high-priority, real-time and/or other time-constrained messages. Low-latency messages, or messages requiring low bus latency, may relate to sensor status, device-generated real-time events and virtualized general-purpose input/output (GPIO). In one example, bus latency may be measured as the time elapsed between a message becoming available for transmission and the delivery of the message or, in some instances, commencement of transmission of the message. Other measures of bus latency may be employed. Bus latency typically includes delays incurred while higher priority messages are transmitted, interrupt processing, the time required to terminate a datagram in process on the serial bus, the time to transmit commands causing bus turnaround between transmit mode and receive mode, bus arbitration and/or command transmissions specified by protocol.
Multi-drop interfaces such as RFFE, SPMI, I3C, etc. can reduce the number of physical input/output (I/O) pins used to communicate between multiple devices. Protocols that support communication over a multi-drop serial bus define a datagram structure used to transmit command, control and data payloads. Datagram structures for different protocols define certain common features, including addressing used to select devices to receive or transmit data, clock generation and management, interrupt processing and device priorities. In some examples herein, the RFFE and SPMI protocols may be employed to illustrate certain aspects disclosed herein. However, the concepts disclosed herein are applicable to other serial bus protocols and standards. Some similarities exist between RFFE and SPMI datagram structures.
Securing Devices Pre-Boot Loader
However, prior to security procedures 514 being established (e.g., in the bootloader stages 506 and/or 508), devices in the system are unsecured and may be susceptible to unauthorized access. That is, prior to security procedures 514, devices within the system may be accessed (e.g., read from or written to) by a rogue device coupled to the same bus.
To secure devices prior to security procedures implemented during a bootloader stage, access control blocks may be used at each device, where the access control blocks define device addresses, device address ranges, and/or register address(es) with which a device is allowed to communicate.
To mitigate or prevent the first device 602 from being accessed/changed by rogue software (e.g., over the bus 606) prior to security being established by a bootloader, the first device 602 may be pre-configured (or pre-loaded) with the security access control blocks 616 and 618 that define addresses (e.g., device addresses and/or register addresses or address ranges) with which the first device 602 is permitted or not permitted to communicate. Such addresses may identify other devices on the bus 606, register addresses, and/or groups of devices/registers on the bus. Consequently, when a command is generated or received at the first device 602, the address in the command is checked to see if the address is identified in the security access control block (either as permitted or not permitted). The command is blocked if it is a not to/from a permitted address or if it is absent from the permitted addresses identified by the security access block.
In some examples, this process of checking the security access control block 616 or 618 and blocking commands may be performed only during a defined period of time (e.g., while the security procedure has not completed). In various implementations, the blocking of commands using the security access control block may be performed at the transmitter circuit 612, the receiver circuit 614, and/or a processing circuit which generates a command to be transmitted or which was received over the bus 606. The checking of the security access control block addresses may be disabled or bypassed, for instance, a bootloader security procedure is completed.
In one example, the bus interface circuit 116 in
In a second example, only a transmitter device 804, having a transmitter circuit 816, may include a transmit security access block 818; a corresponding receiver device (not shown) may not include a receiver security access block.
In a third example, only a receiver device 806, having a receiver circuit 820, may include a receive security access block 822; a corresponding transmitter device (not shown) may not include a transmitter security access block.
In a fourth example, a device 824 may include a transceiver device 826 and a processing circuit 830 (which may process commands to/from the bus), but the security access block may reside between the transceiver device 826 and the processing circuit 830.
Similarly, a receive security access block 904 may include, for instance, a list of allowed device identifiers 914 (or device identifier ranges) from which commands can be received, a list of denied/blocked device identifier 916 from which commands cannot (or should not) be received or processed, a list of allowed register addresses 918 (or register address ranges) from which commands can be received, and/or a list of denied/blocked register addresses 920 (or register address ranges) from which commands cannot (or should not) be received. A device with such receive security access block 904 may permit or allow the reception or processing of commands (from the bus) that are intended for (or identify) at least one of the allowed device identifiers 914 or allowed register addresses 918. Likewise, a device with such receive security access block 902 may block or prevent the reception of commands over the bus which are intended for (or identify) at least one of the denied/blocked device identifiers 916 or denied/blocked register addresses 920.
Examples of Devices and Methods Having Integrated Access Control Blocks
In the illustrated example, the processing circuit 1004 may be implemented with a bus architecture, represented generally by the bus 1010. The bus 1010 may include any number of interconnecting buses and bridges depending on the specific application of the processing circuit 1004 and the overall design constraints. The bus 1010 links together various circuits including the processing circuit 1004, the transceiver circuit 1006, and the storage device 1008. The transceiver circuit 1006 may serve to couple to a shared or common bus 1012.
The storage device 1008 (e.g., non-volatile storage, etc.) may include memory devices and mass storage devices, and may be referred to herein as computer-readable media and/or processor-readable media. The storage device 1008 may be used for storing a transmit security access control block and/or a receive security access control block, which serve to restrict access to/from the device 1002 prior to any security procedure being implemented as part of a bootloader.
At block 1102, a list of device addresses stored (or pre-stored), the list indicates device addresses which a device is either permitted or not permitted to communicate over a shared bus prior to a bootloader procedure being initiated on the device. In one example, the bootloader procedure may be a security procedure executed after a basic input/output system (BIOS) is loaded for the device. In some implementations, each device address in the list of device addresses may define: (a) one or more devices, (b) one or more register addresses, and/or (c) one or more ranges of addresses. In various examples, the list of device addresses may be stored or pre-loaded during manufacturing of the device or during an initial setup (e.g., by a vendor, manufacturer, or distributor).
At block 1104, a first command to be transmitted over the shared bus to a first device address is obtained (e.g., received from a host processing circuit). For instance, the first command may be one of a read or write command from/to a register in another device associated with the first device address.
At block 1106, a determination is made as to whether the first device address is in the list of device addresses in the access block.
At block 1108, transmission of the first command over the shared bus is allowed or prevented based on whether the first device address is in the list of device addresses. In one example, allowing or preventing transmission of the first command includes: transmiting the first command if: (a) the first device address is in the list of device addresses with which the device is permitted to communicate; or (b) the first device address is not in the list of device addresses with which the device is not permitted to communicate. Additionally, allowing or preventing transmission of the first command may also include: terminating transmission of the first command if: (c) the first device address is in the list of device addresses with which the device is not permitted to communicate; or (d) the first device address is not in the list of device addresses with which the device is permitted to communicate.
At block 1110, the determination of whether the first device address is in the list of device addresses is bypassed or ignored after the bootloader procedure is completed.
According to another example the method may further include receiving a second command over the shared bus from another device having a second device address. A determination is then made as to whether the second device address is in the list of device addresses in the access block. Processing of the second command may be terminated if: (a) the second device address is in the list of device addresses with which the device is not permitted to communicate; or (b) the second address is not in the list of device addresses with which the device is permitted to communicate. Alternatively, the second command may be processed if: (a) the second device address is in the list of device addresses with which the device is permitted to communicate; or (b) the second device address is not in the list of device addresses with which the device is not permitted to communicate.
It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Further, some steps may be combined or omitted. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for.”
