Securely modifying access to a debug port

In some aspects, the techniques described herein relate to a device including: a debug port; a trusted execution environment (TEE), the TEE storing a public key; and a controller, the controller configured to: receive a command to access the debug port, the command including a signature generated using a private key corresponding to the public key; provide the command to the TEE, wherein the TEE validates the command by validating the signature using the public key to obtain a validation result; and modify access to the debug port based on the validation result.

FIELD OF THE TECHNOLOGY

At least some embodiments disclosed herein relate generally to memory devices (e.g., semiconductor memory devices) and, in particular, to improvements in cryptographically securing debug ports on such devices.

BACKGROUND

Some memory devices may utilize debug ports during manufacturing as well as for software debugging by an authorized party. To properly secure the device, all other accesses to the debug port should be strictly forbidden. Current solutions to prevent malicious access to debug ports include either disabling debut ports entirely prior to release from manufacturing and/or disabling debug access in the kernel of such devices. Both approaches effectively remove debug capability after a device is released from manufacturing.

DETAILED DESCRIPTION

The example embodiments are directed towards securing access to a debug port of a computing device. In the various embodiments, access to a debug port is controlled via cryptographic keys. During manufacturing, a public key of a key management server (KMS) is stored in a secure area of the computing device, such as a trusted execution environment (TEE). The KMS can then generate a command to access the debug port (e.g., enable or disable with corresponding access permissions). The KMS signs this command using a private key corresponding to the public key stored in the TEE. In response, the computing device validates the signature and modifies access to the debug port based on the command. In further embodiments, a method for updating the public key in the TEE is also described, which enables temporary authority to access the debug port.

The example embodiments dynamically enable and disable a debug port securely; therefore, even final products can retain such debug ports. Using the example embodiments, debug ports can be enabled or disabled remotely, therefore, providing remote debugging capabilities. Further, using the example embodiments, debug ports can be enabled and disabled for boot loaders, and debug port access can be delegated to third parties.

In some aspects, the techniques described herein relate to a device including: a debug port; a trusted execution environment (TEE), the TEE storing a public key; and a controller, the controller configured to receive a command to access the debug port, the command including a signature generated using a private key corresponding to the public key; provide the command to the TEE, wherein the TEE validates the command by validating the signature using the public key to obtain a validation result; and modify access to the debug port based on the validation result.

In some aspects, the techniques described herein relate to a device, wherein validating the command further includes validating one of a monotonic counter or nonce value included in the command.

In some aspects, the techniques described herein relate to a device, wherein the public key and the private key include an Elliptic Curve Digital Signature Algorithm (ECDSA) key pair.

In some aspects, the techniques described herein relate to a device, wherein the public key is written to the TEE during the manufacturing of the device.

In some aspects, the techniques described herein relate to a device, wherein the command to access a debug port includes a command to enable a debug port or a command to disable a debug port.

In some aspects, the techniques described herein relate to a device, wherein the command further includes a set of access permissions for accessing the debug port.

In some aspects, the techniques described herein relate to a device, wherein the TEE further includes a register and modifying access to the debug port includes updating the register based on the command.

In some aspects, the techniques described herein relate to a device, wherein updating a register based on the command includes updating bits of the register based on the set of access permissions.

In some aspects, the techniques described herein relate to a device, wherein the controller is further configured to replace the public key with a new public key included in a digital certificate signed using the private key.

In some aspects, the techniques described herein relate to a method including: receiving, by a controller of a computing device, a command to access a debug port, the command including a signature generated using a private key; validating, via a trusted execution environment (TEE), the command by validating the signature using a public key stored in the TEE to obtain a validation result; and modifying, by the controller, access to the debug port based on the validation result.

In some aspects, the techniques described herein relate to a method, wherein validating the command further includes validating one of a monotonic counter or nonce value included in the command.

In some aspects, the techniques described herein relate to a method, wherein the public key and the private key include an Elliptic Curve Digital Signature Algorithm (ECDSA) key pair.

In some aspects, the techniques described herein relate to a method, wherein the public key is written to the TEE during the manufacturing of the computing device.

In some aspects, the techniques described herein relate to a method, wherein the command to access a debug port includes a command to enable a debug port or a command to disable a debug port.

In some aspects, the techniques described herein relate to a method, wherein the command further includes a set of access permissions for accessing the debug port.

In some aspects, the techniques described herein relate to a method, wherein modifying access to the debug port includes updating a register based on the command.

In some aspects, the techniques described herein relate to a method, wherein updating a register based on the command includes updating bits of the register based on the set of access permissions.

In some aspects, the techniques described herein relate to a method, further including replacing the public key with a new public key included in a digital certificate signed using the private key.

In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium for tangibly storing computer program instructions capable of being executed by a computer processor, the computer program instructions defining steps of: receiving, by a controller of a computing device, a command to access a debug port, the command including a signature generated using a private key; validating, via a trusted execution environment (TEE), the command by validating the signature using a public key stored in the TEE to obtain a validation result; and modifying, by the controller, access to the debug port based on the validation result.

In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium, wherein the command further includes a set of access permissions for accessing the debug port and modifying access to the debug port includes updating a register based on the command, wherein bits of the register are updated based on the set of access permissions.

FIG.1is a block diagram of a computing system including a memory device having a secure debug port.

In an implementation, a computing system100includes a memory device102and a key management server104. The memory device102may be part of a larger computing device (not illustrated inFIG.1but depicted inFIGS.6and7). Memory device102is communicatively coupled to the key management server104either directly or via an intermediary host device or processor.

The key management server104stores a private key118and generates signed debug commands via a command generator116. The key management server104can include further components to handle network requests, validation of users, etc., which are all non-limiting and may be built using standard components (e.g., application servers, databases, etc.).

Memory device102includes a controller to receive commands and provide access to a debug port108. Debug port108may comprise a physical or software-defined port of the memory device102that enables certain sensitive access to the memory device102for debugging or troubleshooting. Memory device102also includes a TEE110or similar type of secure computing environment that can prevent unauthorized access to contents therein. TEE110may also perform various cryptographic operations such as signature validation.

As illustrated, the TEE110may include a debug register114dedicated to controlling the operation of debug port108. Although a single register is illustrated, the debug register114may be made up of multiple registers. In some implementations, the debug register114can be situated within the TEE110, and access to the debug port108may be mediated by the TEE110(based on the value in debug register114). In other implementations, debug register114may be outside the TEE110(but within memory device102) and accessible by the controller106. In these implementations, debug register114may be configured to only be writable by the TEE110and only readable to another device (i.e., controller106).

TEE110also includes a server public key112. This server public key112can be a key generated by key management server104and written to the TEE110during manufacturing. As will be discussed, in some implementations, server public key112can be replaced with a new public key generated by a third party.

Various operations of the computing system100are briefly described herein, and further reference is made toFIG.2throughFIG.5. As discussed, the key management server104can generate an asymmetric key pair and write the server public key112to the TEE110during manufacturing. Then, the key management server104can generate and sign debug commands that control access to the debug port108. The key management server104can transmit these commands (ultimately) to controller106, which can validate the signature of the debug commands using the TEE110. If the TEE110validates the signature, it updates the debug register114to enable, disable, and configure the debug port108according to parameters in the debug command. Details of these operations are provided inFIGS.2and3. Further, in some implementations, the key management server104can generate a digital certificate that includes a new public key to replace the server public key112. The key management server104can transmit this digital certificate to controller106, which can validate the digital certificate using the current server public key112and then replace the server public key112if the digital certificate is valid. Ultimately, the TEE110may revert the change in public key when the digital certificate expires, returning server public key112to a designated location. Details of these operations are provided inFIGS.4and5.

FIG.2is a flow diagram illustrating a key generation process. In some implementations, a manufacturer alone or in combination with a KMS can perform method200.

In step202, method200can include generating an asymmetric key pair.

In some implementations, the asymmetric key pair can include a public key portion and a private key portion. Various algorithms can be used to generate an asymmetric key pair, including, but not limited to, Rivest-Shamir-Adleman (RSA), Elliptic Curve Digital Signature Algorithm ECDSA), or similar algorithms. The specific choice of key generation algorithm is not limiting, and any such public-key infrastructure (PKI) algorithm that can generate an asymmetric key pair may be used. In some implementations, a manufacturer may generate the asymmetric key pair. In other implementations, a KMS may generate the asymmetric key pair and return the asymmetric key pair to the manufacturer for further processing. As used herein, the asymmetric key pair is referred to as the server key pair, while the public key portion and private key portions are referred to as the server public key and server private key, respectively.

In step204, method200can include writing the server public key to a memory device.

In some implementations, step204can be performed in a secure manufacturing environment. As such, step204can include writing or otherwise persisting the server public key portion of the asymmetric key pair to a secure region of the memory device. In some implementations, this secure region can be a write-protected region of non-volatile memory (e.g., NAND Flash). In other implementations, the secure region can be a storage area within a TEE or a similar type of secure processing portion of the memory device. In general, step204includes writing the server public key in such a way that unauthorized users or software cannot access the server public key without holding the server private key, as will be discussed.

In step206, method200can include storing the server private key.

In some implementations, a manufacturer can maintain a secure storage device (e.g., HSM) to store the server private key. In other implementations, the manufacturer can provide the server private key to a KMS for secure storage (e.g., in an HSM). In other implementations, if the KMS generates the asymmetric key pair, the KMS may retain the server private key while providing the server public key to the manufacturer. In some implementations, step206can further include storing a unique identifier (UID) of the memory device along with the server private key. For example, step206can include storing the server private key and UID in an associative storage structure (e.g., hash, key-value store, etc.) to enable retrieval of a server private key in response to a UID. Similarly, method200can include storing the server public key in a similar manner (i.e., associated with a UID).

After step206, a memory device may be released from manufacturing and provided to a downstream user to the memory device. As such, time may pass between step206and step208, as illustrated by the broken arrow. At some point after step206, method200may resume at step208.

In step208, method200generates a debug command.

In some implementations, method200may generate a debug command in response to a request from a user of the memory device. In some implementations, the user may authenticate themselves before step208executes, ensuring that the user is authorized to receive a debug command. In some implementations, method200maintains a mapping of UIDs to customers and can thus validate requests for a debug command based on this mapping. In other implementations, the user can provide a digital certificate or other cryptographically identifying data to validate their authority.

The debug command can include a command indicating whether a debug port should be enabled or disabled. The specific format of such a command is not limiting and may vary based on the instruction set of the memory device. As an example, the command can include an opcode and one or more parameters. These parameters can include a Boolean setting (i.e., enabled/disabled). Further, in some implementations, the parameters can include configuration parameters of the debug port, some examples of which are provided herein. In general, the configuration parameters may represent a set of access permissions for accessing the debug port.

As a first example, the configuration parameters can include a run-time control which allows an external debug tool to start and stop the processor, modify registers, and single-step (execute a single assembly instruction). As a second example, the configuration parameters can include a memory access parameter which allows an external debug tool to read and write memory. The access can be either normal access or on-the-fly access in which case the access is performed while the processor is running. As a third example, the configuration parameters can include breakpoints which allow an external debug tool to halt execution when a specified event (breakpoint) has occurred. The event can be specified as code execution at a specified address or as a data access (read or write) to a specified address with a specified value. Watchpoints are a similar concept, and however, when a watchpoint occurs, a message is sent to the debug tool (as opposed to halting the processor). As a fourth example, the configuration parameters can include an instruction or program trace setting, which allows an external debug to trace program execution and by this having full reconstruction of the program flow. As a fifth example, the configuration parameters can include a data trace setting which allows an external debug tool to track real-time data accesses to memory locations. As a sixth example, the configuration parameters can include an ownership trace feature which allows an external debug tool to identify (real-time) the currently executing process or task of an operating system. As a seventh example, the configuration parameters can include a memory substitution and port replacement parameter which allows internal memory or port accesses to be implemented over the auxiliary debug port. For example, this feature can be used to implement ROM patching, that is, instead of reading on-chip ROM, the instruction will be fetched from the debug tool via the auxiliary debug port.

Each of the parameters above can be represented via a Boolean value, enabling or disabling specific parameters. As a further example, the enable/disable setting can be represented as another parameter, and the entire parameter set can consist of eight bits. In some implementations, the command can include setting a register value to this value. For example, “MOV DEB_REG 0x8C,” where the “0x8C” represents the bitmap “10001100,” setting the various configuration parameters and enable/disable flag discussed above. Further, in some embodiments, a monotonic counter value can be read and inserted into the command to prevent replay attacks.

In step210, method200can include signing the debug command.

In some implementations, method200can retrieve the server private key (either stored locally or via a KMS). In some implementations, method200uses the UID of the memory device (as validated in step208) to identify the proper server key and generates a digital signature using the server private key as the key and the debug command as the data to sign. As discussed, an algorithm such as an RSA or ECDSA algorithm can be used to generate such a signature, and the specific algorithm is not limiting but should be consistent with the asymmetric key pair generated in step202.

In step212, method200can include transmitting the debug command and signature (referred to as the signed command) to the memory device.

In some implementations, method200can transmit the signed command directly to the memory device. In other implementations, method200can transmit the signed command to the memory device via a host device or processor which requested the command. As will be discussed next, the memory device can validate the command and control access to the debug port accordingly.

FIG.3is a flow diagram illustrating a debug port command processing routine. In some implementations, method300can be executed by a memory device.

In step302, method300can include receiving a command to access a debug port, the command including a signature generated using the server private key discussed inFIG.2.

Details of this command and the contents thereof were described inFIG.2and, specifically, step208ofFIG.2and are not repeated at length herein. In brief, the debug command can include an enable/disable signal (e.g., bit) and, in some implementations, additional configuration parameters. As discussed, the debug command may take the form of setting a register value to a sequence of bits, each bit representing a set of access permissions for accessing the debug port. In some implementations, method300receives the debug command directly from a KMS. Alternatively, or in conjunction with the foregoing, method300may receive the debug command from a host processor or host device. In some implementations, step302can be executed by the controller of memory device. In other implementations, step302can be executed by a TEE or similar secure environment of the memory device directly.

In step304, method300can include validating the command by validating the signature using the public key to obtain a validation result. In some implementations, step304can be executed within a TEE or similar environment.

In response to a signed debug command, the TEE can read the server public key stored within the secure region and use the server public key to validate the signature included in the command. In general, standard digital signature validation algorithms can be used to validate the digital signature. Further, in some implementations, step304can include validating the monotonic counter value to ensure that the command was not previously received. In such implementations, method300may maintain a corresponding monotonic counter value to ensure that the same monotonic counter value is not received (i.e., replayed).

In step306, method300determines if the signature validation was successful or not. If not, method300returns an error to the calling device in step308. As discussed, this device may be a host processor or device or a KMS. In general, the form of the error is not limiting so long as it indicates that the debug port was not modified. By contrast, if the signature validation was successful, method300configures the debug port accordingly in step310.

As discussed above, in some implementations, the debug port may be hardware-controlled. In such an implementation, step310can include setting a specific debug register with a value included in the debug command as described previously. In some implementations, a single register can be used and each bit can comprise a binary flag for a given setting. In other implementations, multiple such registers may be used and each register can store a corresponding configuration parameter. In some implementations, these registers can be hardwired to control circuitry controlling access to the debug port. Alternatively, or in conjunction with the foregoing, in some implementations, a software-implemented debug port control mechanism can be used. In such a scenario, the register can be read by a kernel or bootloader to enable, disable, or otherwise modify the access to a debug port via higher-level software.

FIG.4is a flow diagram illustrating a transfer procedure performed by a key management system.

In step402, method400can include receiving a new public key. In some implementations, the new public key can be associated with a user and one or more memory devices (e.g., via UID values).

As discussed inFIG.2, in some implementations, a user device can authenticate with method400to validate it's identity with respect to one or more memory devices. In response, method400can confirm that a given user is associated with the UIDs of one or more memory devices. If such validation fails, method400will end. However, if method400can confirm that the user or device transmitting the new public key is associated with a given memory device, it will continue.

In step404, method400can include generating a digital certificate signed using the server private key.

In some implementations, the server private key in step404corresponds to the current server public key stored by the memory device. As discussed inFIG.2, associations between memory devices (UIDs) and server public and private keys can be persistently stored (e.g., by a KMS). Thus, in step404, method400can identify the current server private key to use for signing based on a UID value (and thus corresponding public key) included along with the new public key transmitted in step402. In response, method400can include generating a digital certificate that includes the new public key. Specifically, in some implementations, method400can generate an X.509 certificate that uses the new public key as the “Subject Public Key.” Method400can then sign the digital certificate using the server private key corresponding to the server public key currently stored by the memory device (and concurrently stored by the KMS). In some implementations, method400can include setting other fields of the digital certificate accordingly (e.g., setting a Subject Name field as the name of the user). In some implementations, step404can also include explicitly setting the validity period of the digital certificate to a short time period. For example, step404can include setting the validity period to one hour from the time of receipt. The specific duration of the validity period is not limiting.

In step406, method400can include returning the digital certificate to the corresponding memory device. As in step212, in some implementations, method400can transmit the digital certificate directly to the memory device. In other implementations, method400can transmit the digital certificate to a host processor or host device for forwarding to the memory device. In response, memory device can execute method500described next.

FIG.5is a flow diagram illustrating a transfer procedure performed by a memory device.

In step502, method500can include receiving the digital certificate from the KMS or from the KMS via the host processor or device. In some implementations, the memory device, via a controller, can support a command that causes a TEE to attempt to replace a key using a digital certificate, as will be discussed.

In step504, method500can include validating the digital certificate using the currently stored server public key in the memory device.

As discussed, this server public key can be the key generated during manufacturing and securely stored inside a TEE or similar secure environment. In response to receiving a digital certificate, method500can include validating the digital signature of the digital certificate using the current server public key. Any well-known digital certificate validation routine can be employed to perform this check and the choice of algorithm is not limiting.

In step506, method500determines if the digital certificate validation was successful or not. If not, method500returns an error to the calling device in step508. As discussed, this device may be a host processor or device or a KMS. In general, the form of the error is not limiting so long as it indicates that the public key was not updated. By contrast, if the digital certificate validation was successful, method500can temporarily replace the server public key as will be discussed next in step510.

In step510, method500can include replacing the server public key with the public key included in the digital certificate.

As discussed inFIG.4, the public key in the digital certificate can be set by any user authorized to manage the memory device (as validated inFIG.4). Any type of public key can be used (e.g., ECDSA, RSA, etc.). Cryptographic keys can be used to establish ownership. As such, when the digital certificate is validate using the server public key it can confirm that the server generated the digital certificate and thus the included data was validated by the server (i.e., KMS). As such, method500can trust the public key in the digital certificate. Thus, in response, method500can include using the public key for future debug command validations in step510. In some implementations, method500can replace the current server public key with the new public key in the digital certificate while retaining a copy of the current server public key for future use, as will be discussed. In other implementations, the current server public key can be discarded, thus effectively transferring complete ownership of the debug port functionality to the holder of the private key corresponding to the new public key.

As part of step510, a memory device may execute method300again. However, in this scenario, the holder of the private key corresponding to the new public key may self-sign the debug command using its own private key. Since the TEE now uses the new public key as the validation key, the holder of the new private key can enable, disable, and configure the debug port without relying on a KMS or other third-party to sign such commands.

In step512, method500can include determining if the certificate is valid. In some implementations, step512(and step514) can be bypassed if the replacement of keys is permanent. However, in other implementations, the replacement of the server public key with the new public key may be temporary. In these implementations, the validity period of the digital certificate can be used as a timer to determine how long to use the new public key as the validation key in method300. Other mechanisms (e.g., a fixed duration timer) may be used. In general, the use of a validity period enables a temporary transfer of control to the owner of the new public key while ensure that such control does not “leak” beyond the required time for using the debug port. As such, the validity period can act as a backstop to ensure that access to the debug port is not unintentionally exposed. While the digital certificate is valid, method500continues to execute step510. However, when the validity period ends, method500proceeds to step514

In step514method500can include reverting the new public key to the server public key.

As discussed, during step508, method500can move the server public key to a temporary location. In step514method500can completely discard the new public key and move the server public key back to a preconfigured location for use in method300. As such, after step514method300will utilize the server (e.g., KMS) public key for validating signatures of debug commands.

FIG.6is a block diagram illustrating a computing system according to some embodiments of the disclosure.

As illustrated inFIG.6, a computing system600includes a host processor620communicatively coupled to a memory device602via a bus604. The memory device602comprises a controller606communicatively coupled to one or more memory banks (e.g., bank608A, bank608B, bank608C, bank608D, bank608N, etc.) forming a memory array via a interface612. As illustrated, the controller606include es a local cache614, firmware616, and an ECC module618.

In the illustrated embodiment, host processor620can comprise any type of computer processor, such as a central processing unit (CPU), graphics processing unit (GPU), or other types of general-purpose or special-purpose computing devices. The host processor620includes one or more output ports that allow for the transmission of address, user, and control data between the host processor620and the memory device602. In the illustrated embodiment, this communication is performed over the bus604. In one embodiment, the bus604comprises an input/output (I/O) bus or a similar type of bus.

The memory device602is responsible for managing one or more memory banks (e.g., bank608A, bank608B, bank608C, bank608D, bank608N, etc.). In one embodiment, the memory banks (e.g., bank608A, bank608B, bank608C, bank608D, bank608N, etc.) comprise NAND Flash dies or other configurations of non-volatile memory. In one embodiment, the memory banks (e.g., bank608A, bank608B, bank608C, bank608D, bank608N, etc.) comprise a memory array.

The memory banks (e.g., bank608A, bank608B, bank608C, bank608D, bank608N, etc.) are managed by the controller606. In some embodiments, the controller606comprises a computing device configured to mediate access to and from banks (e.g., bank608A, bank608B, bank608C, bank608D, bank608N, etc.). In one embodiment, the controller606comprises an ASIC or other circuitry installed on a printed circuit board housing the memory banks (e.g., bank608A, bank608B, bank608C, bank608D, bank608N, etc.). In some embodiments, the controller606may be physically separate from the memory banks (e.g., bank608A, bank608B, bank608C, bank608D, bank608N, etc.). The controller606communicates with the memory banks (e.g., bank608A, bank608B, bank608C, bank608D, bank608N, etc.) over the interface612. In some embodiments, this interface612comprises a physically wired (e.g., traced) interface. In other embodiments, the interface612comprises a standard bus for communicating with memory banks (e.g., bank608A, bank608B, bank608C, bank608D, bank608N, etc.).

The controller606comprises various modules including local cache614, firmware616and ECC module618. In one embodiment, the various modules (e.g., local cache614, firmware616and ECC module618) comprise various physically distinct modules or circuits. In other embodiments, the modules (e.g., local cache614, firmware616and ECC module618) may completely (or partially) be implemented in software or firmware.

As illustrated, firmware616comprises the core of the controller and manages all operations of the controller606. The firmware616may implement some or all of the methods described above. Specifically, the firmware616may implement the methods described in the foregoing figures.

FIG.7is a block diagram of a computing device according to some embodiments of the disclosure.

As illustrated, the device700includes a processor or central processing unit (CPU) such as CPU702in communication with a memory704via a bus714. The device also includes one or more input/output (I/O) or peripheral devices712. Examples of peripheral devices include, but are not limited to, network interfaces, audio interfaces, display devices, keypads, mice, keyboard, touch screens, illuminators, haptic interfaces, global positioning system (GPS) receivers, cameras, or other optical, thermal, or electromagnetic sensors.

In some embodiments, the CPU702may comprise a general-purpose CPU. The CPU702may comprise a single-core or multiple-core CPU. The CPU702may comprise a system-on-a-chip (SoC) or a similar embedded system. In some embodiments, a graphics processing unit (GPU) may be used in place of, or in combination with, a CPU702. Memory704may comprise a memory system including a dynamic random-access memory (DRAM), static random-access memory (SRAM), Flash (e.g., NAND Flash), or combinations thereof. In one embodiment, the bus714may comprise a Peripheral Component Interconnect Express (PCIe) bus. In some embodiments, the bus714may comprise multiple busses instead of a single bus.

Memory704illustrates an example of a non-transitory computer storage media for the storage of information such as computer-readable instructions, data structures, program modules, or other data. Memory704can store a basic input/output system (BIOS) in read-only memory (ROM), such as ROM708for controlling the low-level operation of the device. The memory can also store an operating system in random-access memory (RAM) for controlling the operation of the device.

Applications710may include computer-executable instructions which, when executed by the device, perform any of the methods (or portions of the methods) described previously in the description of the preceding figures. In some embodiments, the software or programs implementing the method embodiments can be read from a hard disk drive (not illustrated) and temporarily stored in RAM706by CPU702. CPU702may then read the software or data from RAM706, process them, and store them in RAM706again.

The device may optionally communicate with a base station (not shown) or directly with another computing device. One or more network interfaces in peripheral devices712are sometimes referred to as a transceiver, transceiving device, or network interface card (NIC).

An audio interface in peripheral devices712produces and receives audio signals such as the sound of a human voice. For example, an audio interface may be coupled to a speaker and microphone (not shown) to enable telecommunication with others or generate an audio acknowledgment for some action. Displays in peripheral devices712may comprise liquid crystal display (LCD), gas plasma, light-emitting diode (LED), or any other type of display device used with a computing device. A display may also include a touch-sensitive screen arranged to receive input from an object such as a stylus or a digit from a human hand.

A keypad in peripheral devices712may comprise any input device arranged to receive input from a user. An illuminator in peripheral devices712may provide a status indication or provide light. The device can also comprise an input/output interface in peripheral devices712for communication with external devices, using communication technologies, such as USB, infrared, Bluetooth®, or the like. A haptic interface in peripheral devices712provides tactile feedback to a user of the client device.

A GPS receiver in peripheral devices712can determine the physical coordinates of the device on the surface of the Earth, which typically outputs a location as latitude and longitude values. A GPS receiver can also employ other geo-positioning mechanisms, including, but not limited to, triangulation, assisted GPS (AGPS), E-OTD, CI, SAI, ETA, BSS, or the like, to further determine the physical location of the device on the surface of the Earth. In one embodiment, however, the device may communicate through other components, providing other information that may be employed to determine the physical location of the device, including, for example, a media access control (MAC) address, Internet Protocol (IP) address, or the like.

The device may include more or fewer components than those shown inFIG.7, depending on the deployment or usage of the device. For example, a server computing device, such as a rack-mounted server, may not include audio interfaces, displays, keypads, illuminators, haptic interfaces, Global Positioning System (GPS) receivers, or cameras/sensors. Some devices may include additional components not shown, such as graphics processing unit (GPU) devices, cryptographic co-processors, artificial intelligence (AI) accelerators, or other peripheral devices.

The subject matter disclosed above may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein; example embodiments are provided merely to be illustrative. Likewise, a reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, or systems. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, or any combination thereof (other than software per se). The preceding detailed description is, therefore, not intended to be taken in a limiting sense.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in an embodiment” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter include combinations of example embodiments in whole or in part.

These computer program instructions can be provided to a processor of a general purpose computer to alter its function to a special purpose; a special purpose computer; ASIC; or other programmable digital data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, implement the functions or acts specified in the block diagrams or operational block or blocks, thereby transforming their functionality in accordance with embodiments herein.