TW202403564A - Artificial intelligence apparatus - Google Patents

Abstract

Aspects of the present disclosure provide an apparatus that can execute an artificial intelligence (AI) model with IO changing. For example, the apparatus can include a first secured processor, a secured application embedded in the first secured processor and associated with an AI model, a secured memory configured to store an AI executable binary associated with the AI model, a second secured processor configured to execute the AI executable binary, a sub-system configured to trigger IO changing and trigger the second secured processor to execute the AI executable binary, IO meta data stored in the secured memory, an IO verifier configured to verify IO changing by determining the IO meta data, and an IO pre-fire module configured to patch the IO changing to the AI executable binary running on the second secured processor when the IO verifier determines that the IO changing matches the IO meta data.

Description

artificial intelligence device

The present invention relates to neural networks (NN), and more specifically, to always-on artificial intelligence (AI) security.

The background description provided herein is for the purpose of generally presenting the context of the disclosure. The presently mentioned work of the inventors (to the extent that the work is described in this Background section) and aspects of the description (which are not otherwise described as prior art at the time of filing) are neither expressly nor implicitly are admitted as prior art to the present invention.

Integrating machine learning (ML) functions into hardware paths is a trend, and flexible and scalable designs are needed to reduce the design complexity of deep neural network (DNN) accelerator implementation.

Aspects of the present invention provide a device that can execute an artificial intelligence (AI) model when input/output (IO) changes. For example, the device may include a first secure processor and a secure application embedded in the first secure processor. Security applications can be associated with artificial intelligence (AI) models. The apparatus may also include secure memory coupled to the first secure processor. The secure memory may be configured to store an AI executable binary associated with the AI model. The apparatus may also include a second secure processor coupled to the secure memory. The second secure processor may be configured to execute the AI executable binary file stored in the secure memory. The apparatus may also include a subsystem coupled between the first security processor and the second security processor. The subsystem may be configured to trigger IO changes and trigger the second secure processor to execute the AI executable binary stored in secure memory. The device may also include IO metadata stored in secure memory. The device may also include an IO validator coupled to the subsystem and the secure memory. The IO validator can be configured to verify IO changes by determining IO metadata. The device may also include an IO pre-release module coupled to the IO verifier. The IO pre-issue module can be configured to patch the IO changes to the AI executable binary file running on the second security processor when the IO validator determines that the IO changes match the IO metadata. In one embodiment, the IO validator may be embedded in the second security processor. In another implementation, the IO pre-issuance module may be embedded in the second security processor.

In one embodiment, the IO metadata may include an IO address range, the IO changes may include the IO address, the IO validator may verify whether the IO address is within the IO address range, and when the IO validator determines that the IO address is within When the IO address is within the range, the IO pre-issue module can patch the IO address to the AI executable binary file running on the second security processor. In another embodiment, the IO metadata may include a plurality of different resolutions, the IO changes may include resolution changes, and the IO validator may verify whether the resolution changes are consistent with the different resolutions specified in the IO metadata. matches any resolution of AI executable binary file.

In one embodiment, the device may further include a secure operating system (OS) embedded in the first secure processor, the secure OS being configured to provide a trusted execution environment (TEE) , in this trusted execution environment, secure applications are protected. In another embodiment, the secure memory and the second secure processor may be protected by the first firewall. In some implementations, a subsystem may be protected by a second firewall that is different from the first firewall. In various implementations, the first firewall may provide a higher level of security than the second firewall.

In one embodiment, the device may further include an image signal processor (ISP) coupled to the secure memory. The ISP can be configured to process images and store the processed images in secure memory. In another embodiment, the device may also include a facial biometric pattern that is secure within the TEE. In some implementations, the second security processor may execute an AI executable binary profile to determine whether any of the processed images match the facial biometric pattern.

In one embodiment, the first security processor may include a security central processing unit (CPU for short). In another implementation, the second secure processor may include a secure deep learning accelerator (DLA for short). In some embodiments, the DLA may include an accelerated processing unit (APU).

Note that this summary does not identify every embodiment and/or incrementally novel aspect of the invention or claimed invention. Rather, this summary provides only a preliminary discussion of various embodiments and corresponding novelties compared to conventional techniques. For additional details and/or possible perspectives of the invention and embodiments, the reader is referred to the Detailed Description of the Invention and the corresponding drawings, as discussed further below.

Ambient intelligence (AmI) (e.g., environmental sensing) is proposed to enhance the way the environment and people interact with each other. Specifically, AmI stated that smart computing will not require explicit input and output devices; instead, various sensors (such as accelerometers, global positioning systems (GPS), microphones, cameras, etc.) can be and processors embedded in everyday electronic devices (e.g., mobile phones) to use artificial intelligence (AI) technology to collect and process contextual information, for example, to interpret environmental status and user needs.

For example, the "Personal Safety" application launched by Google has the following functions, that is, it can sense whether an individual has been involved in a car accident, and if so, it can make an emergency call on behalf of the individual. As another example, AI and machine learning (ML) algorithms (or models) installed in a camera can identify its owner, such as by determining whether the image captured by the camera matches a facial biometric pattern of the owner's face. face.

For crash sensing to be truly effective, mobile phones need to be able to detect crashes at any time. For example, one could determine whether a car accident has occurred by continuously polling accelerometers and microphones and then processing the data thus collected (e.g., by executing artificial intelligence (AI) that is always online). However, the continuous online sensing tasks consume a lot of valuable power resources of mobile phones.

A sensor hub (or context hub) is a low-power subsystem (e.g., processor) that can be designed to process and interpret data collected from sensors and wake up the main application processor (AP) ) take action. For example, after processing and interpreting the collected data and determining that a car accident has occurred, the sensor hub can wake up the AP and the mobile phone can call emergency services.

1 is a functional block diagram of an AmI-enabled device 100 (eg, a mobile phone). Device 100 may include AP 110, a low power subsystem 120 (eg, a sensor hub) coupled to AP 110, a signal processor 130 (eg, a low power image signal processor) coupled to sensor hub 120 (low-power image signal processor, ISP for short), a processor 140 (for example, an AI accelerator (such as a deep learning accelerator (DLA for short)) coupled to the sensor hub 120, such as an accelerated processing unit (accelerated processing unit) processing unit, referred to as APU)), and the memory 150 coupled to the sensor hub 120, the ISP 130 and the APU 140.

The AP 110 can enable environment sensing functions, such as an always-on vision (AOV) client 111 , and load the AI model 122 to the sensor hub 120 to collect data from embedded sensors. A large amount of processing data collected (eg, a camera (not shown)) is offloaded to the sensor hub 120 . In the sensor hub 120 , the camera driver 123 may drive the ISP 130 based on the AOV client 111 to process images captured by the camera (eg, a user's face) and send the processed images to the memory 150 The camera input is 151. A software development kit (SDK for short) 121 (eg, AI inference SDK) can drive the APU 140 to execute the AI model 122 on the processed image. For example, APU 140 may utilize an AI executable binary archive corresponding to AI model 122 to execute AI model 122 on processed images sent from camera input 151 and generate output 152. For example, output 152 may be associated Classification results based on whether the captured customer's face matches the facial biometric pattern of the owner's face.

In device 100, sensor hub 120 may provide secure computing with limited flexibility. For example, the sensor hub 120 can protect fixed functionality and security during the secure boot phase while the mobile phone is running. Environmental sensing continuously senses data, which includes user privacy, such as voice, vision, surroundings, location, etc. If this information and the AI model 122 loaded into the sensor hub 122 are not well protected, they are likely to be attacked, stolen, or tampered with. Furthermore, the processed images on which the APU 140 executes the AI model 122 may not be captured from a camera, but may be sent externally by the attacker.

A firewall is a network security device that monitors all incoming and outgoing traffic and accepts, denies, or drops said traffic based on a defined set of security rules. For example, a firewall can control network access by monitoring incoming and outgoing data packets at any open systems interconnection (OSI) layer up to the application layer and allowing them Pass or stop data packets based on source and destination IP addresses, protocols, ports, and the history of data packets in state tables to protect data packets from attack, theft, or tampering. Firewalls can be hardware-based or software-based.

FIG. 2 is a functional block diagram of an AmI-enabled device 200 (eg, a mobile phone). Device 200 differs from device 100 in that in device 200, sensor hub 120 and memory 150 are well protected (eg, via firewall 290) (shown with a black background). Therefore, the sensed data and AI model 122 are secure, and an attacker cannot send the image to memory 150 . However, the AI model 122 needs to be restored or updated from time to time (eg, with a new AI model 112) to continuously enhance performance or security based on device training or the Internet. AP 110 cannot restore or update the AI model 122 stored in sensor hub 120 because sensor hub 120 is protected by firewall 290 and AP 110 does not have permission to access sensor hub 120.

3 is a functional block diagram of an AmI-enabled device 300 (eg, a mobile phone). The device 300 may include a secure operating system (OS) 360 . Secure OS 360 may provide a trusted execution environment (TEE) 393 (shown with a black background) for Android, in which code and data (e.g., trusted application (TA)) Can be protected in terms of confidentiality and integrity. Secure OS 360 can run on the same processor that Android runs on (e.g., AP 110), but by combining the hardware and software with a rich OS system running within a rich execution environment (REE). The rest is isolated.

The AI model 322 can be loaded in the TEE 393 provided by the secure OS 360, and the AI executable binary archive 381 and the control flow (including the AI session (session) 327, such as the identifier of the AI model 322) of the AI model 322 can be prepared. (identifier, referred to as ID), and AI executor 328), collectively referred to as AI preparation 361. AI executable binary archive 381 can be sent to secure memory 380, and AI session 327 and AI executor 328 can be sent to low power subsystem 320, such as a sensor hub. A processor 340 such as an AI accelerator (such as a DLA, eg, an APU) may execute the AI executable binary 381 by determining the AI session 327 and the AI executor 328 . In one embodiment, memory 380 and APU 340 are also secure (shown with a black background) (eg, via firewall 391) to protect AI executable binary 381 from attack, theft, or tampering. In the example implementation shown in Figure 3, sensor hub 320 is not protected because it only provides control flow for AI model 322 and does not involve any sensed data. In some implementations, sensor hub 320 may also be protected (eg, via a firewall). For example, the firewall may provide a lower level of security than the firewall 391 because the AI session 327 and the AI executor 328 are less important than the AI executable binary 381 .

In one embodiment, data (eg, facial biometric pattern 363) is also secure within TEE 393 and is downloaded and stored in secure memory 380. For example, the APU 340 may utilize the AI executable binary 381 to execute the AI model 322 on the processed image (eg, the user's face) sent from the ISP 130 (shown in FIG. 1 ) and generate a user image corresponding to the captured image. An output, such as a classification result, associated with whether the face matches the owner's face (ie, facial biometric pattern 363).

Due to various implementations of hardware (for example, the secure memory 380 and the AI accelerator 340 of the device 300), input/output (IO) data and information related thereto (for example, the address of the IO data) may be required Modified to run on AI model 322 deployed to AI accelerator 340. For example, in scenarios where multiple image frames are captured to improve performance, a security camera may include a ring buffer (or loop buffer) configured to serialize the captured image frames. Whenever an image frame is consumed in the ring buffer, the pointers pointing to the start and end of the image frame in the ring buffer are updated, and the addresses input to the AI model 322 change. As another example, in a scenario where the AI model 322 is used to recognize patterns and includes a plurality of connected subgraphs (eg, feature extraction and detection subgraphs and recognition subgraphs), if the APU 340 has limited capabilities, then the patterns input to and detected by the feature extraction and detection subgraphs can be identified by the recognition subgraphs using different (eg, high or low) resolutions based on their size.

However, when the IO data and/or information related thereto changes, the AI executable binary file 381 cannot be modified by the AI executor 328 because the AI executable binary file 381 is protected in the secure memory 380 and the AI accelerator 340 . For example, as shown in the device 400 of Figure 4, the IO pre-fire module 420 embedded in the TEE 393 provided by the secure OS 360 cannot patch the IO changes (eg, the address of the IO 410) to the The AI executable binary file 381 is loaded into the AI accelerator 340, and the AI executable binary file 381 cannot be modified by the AI executor 328. As another example, as shown in the device 500 of FIG. 5 , which includes a plurality of isolated virtual machines (VMs), the first VM (VM0) 501 has a higher performance than the Android system 502 and the second VM (VM1) 503 With higher privileges, both the Android system 502 and the second VM (VM1) 503 are connected to the AI accelerator 340, and the IO pre-release module 520 embedded in the VM0 501 cannot change the IO (for example, the address of the IO 510) Patches to the AI executable binary file 381 prepared by VM0 501 and loaded into the AI accelerator 340, and the AI executable binary file 381 cannot be modified by the AI executor 528 of the Android system 502 and the AI executor 538 of VM1 503.

Figure 6 is a functional block diagram of an AmI-enabled device 600 (eg, a mobile phone) in accordance with some embodiments of the invention. Apparatus 600 can execute AI models in the presence of IO changes. Compared with the device 300, the device 600 may also include an IO metadata 640, an IO validator/checker 630, and an IO pre-release module 620. In one embodiment, IO metadata 640 may be provided by the secure OS 360 while preparing the AI executable binary archive 381 of the AI model 322 and the control flow (including the AI session 327 and the AI executor 328), collectively referred to as AI preparation 361 , and send it to the secure memory 380 and embed it in the secure memory 380 . In the example implementation of Figure 6, because secure memory 380 is protected (eg, via firewall 391), IO metadata 640 may also be protected from attack, theft, or tampering. In another embodiment, IO validator/checker 630 and IO pre-release module 620 may be embedded in AI accelerator 340 and may also be protected (eg, via firewall 391). In one implementation, secure OS 360 or VM (eg, VMO 501) may be embedded within TEE 393. In another implementation, subsystem 320 may be a sensor hub or VM (eg, VM1 503). In the example implementation of Figure 6, subsystem 320 is not protected. In some implementations, subsystem 320 may also be protected (eg, via a firewall). For example, a firewall may provide a lower level of security than a firewall 391 because the AI session 327 and the AI executor 328 are less important than the AI executable binary 381 .

In one embodiment, IO metadata 640 may include IO address patch information and/or valid/accessible IO (address) ranges. For example, IO metadata 640 may include pointers (or addresses) to the beginning and end of the security camera's ring buffer. In another embodiment, IO validator/checker 630 may verify/check whether the IO change (e.g., IO address 610) is within the IO address range specified in IO metadata 640, and if IO address 610 is within Within the IO address range, the IO pre-issue module 620 can patch the IO address 610 to the AI executable binary file 381. For example, since subsystem 320 is not well protected in the example embodiment, IO address 610 may be provided by a malicious entity (eg, a hacker). In this scenario, the IO verifier/checker 630 can verify/check the IO address 610 and determine that the IO address 610 is not within the IO address range, so the IO pre-issue module 620 will not be unverified. ) is patched to the AI executable binary file 381 assigned to and run on the AI accelerator 340 . As another example, when the IO verifier/checker 630 verifies/checks the IO address 610 and determines that the IO address 610 is within the IO address range, the IO pre-issue module 620 can patch the IO address 610 to run AI executable binary file 381 on AI accelerator 340. Therefore, the APU 340 can apply the dynamic shape information to the AI executable binary file 381 and perform inference.

Figure 7 is a functional block diagram of an AmI-enabled device 700 (eg, a mobile phone) in accordance with some embodiments of the invention. Apparatus 700 can execute AI models in the presence of IO changes. Compared to the device 300, the device 700 may also include an IO metadata 740, a (shape) IO validator 730, and a (shape) IO pre-issue module 720. In one implementation, IO metadata 740 may be provided, while the AI executable binary archive 381 is prepared, and the IO metadata 740 is sent and embedded into the secure memory 380 . Because secure memory 380 is protected (eg, via firewall 391), IO metadata 740 may also be protected from attack, theft, or tampering. In another embodiment, (shape)IO validator 730 and (shape)I/O pre-release module 720 may be embedded in AI accelerator 340 and may also be protected (eg, via firewall 391).

In one implementation, IO metadata 740 may include a number of different resolutions, such as low resolution and high resolution. In another embodiment, the (shape) IO validator 730 can verify whether the control 710 that triggered the resolution change matches any of the different resolutions specified in the IO metadata 740, and if the resolution change Matches any of the different resolutions specified in IO metadata 740 , then the (shape) IO pre-release module 720 can patch the resolution change into the AI executable binary file 381 . For example, because subsystem 320 is not well protected in the example embodiment, resolution changes may be provided by malicious entities (eg, hackers). In such a scenario, (shape) IO validator 730 can verify the resolution change and determine that the resolution change does not match any of the different resolutions, and therefore (shape) I/O pre-release module 720 Unvalidated resolution changes will not be patched to AI executable binaries 381 distributed to and running on AI accelerator 340 . As another example, when the (shape) IO validator 730 verifies the resolution change and determines that the resolution change matches one of the different resolutions specified in the IO metadata 740, the (shape) I/O preset The development module 720 can patch the resolution change to the AI executable binary file 381 running on the AI accelerator 340. Therefore, the APU 340 can apply the dynamic shape information to the AI executable binary file 381 and perform inference.

Although aspects of the invention have been described in conjunction with specific embodiments of the invention set forth as examples, substitutions, modifications and variations may be made to these examples. Accordingly, the embodiments set forth herein are intended to be illustrative and not limiting. Some changes may be made without departing from the scope of the patent claims set forth below.

110: Main application processor (AP) 111:Always Online Vision (AOV) Client 112:New AI model 120: Sensor Hub 121:Software Development Kit (SDK) 123:Camera driver 130:Image signal processor (ISP) 141: working buffer 150:Memory 151:Camera input 152:Output 320: Low Power Subsystem (Sensor Hub) 328:AI actuator 360:Secure OS 361:AI preparation 363: Facial biometric mode 380:Secure memory 381:Binary file 393: Trusted Execution Environment (TEE) 501: First virtual machine (VM0) 502:Android system 503: Second virtual machine (VM1) 610:IO address 630:IO validator/checker 710:Control items 720: (Shape) I/O pre-release module 730:(shape)IO validator 122,322:AI model 140,340: Accelerated Processing Unit (APU) 290,391: Firewall 410,510:IO 528,538:AI actuator 640,740:IO metadata 327,527,537:AI session 420,520,620: IO pre-release module 100,200,300,400,500,600,700:Device

Various embodiments of the present invention, presented by way of example, will be described in detail with reference to the following drawings, in which like numerals refer to like elements, and in which: Figure 1 is a functional block diagram of the first device that enables ambient intelligence (AmI); Figure 2 is a functional block diagram of a second AmI enabled device; Figure 3 is a functional block diagram of a third AmI enabled device; Figure 4 is a functional block diagram of a fourth AmI enabled device; Figure 5 is a functional block diagram of a fifth AmI-enabled device; Figure 6 is a functional block diagram of a first AmI enabled device in accordance with some embodiments of the invention; and Figure 7 is a functional block diagram of a second AmI enabled device in accordance with some embodiments of the invention.

100:Device

110: Main application processor (AP)

111:Always Online Vision (AOV) Client

112:New AI model

120: Sensor Hub

121:Software Development Kit (SDK)

122:AI model

123:Camera driver

130:Image signal processor (ISP)

140: Accelerated Processing Unit (APU)

141: working buffer

150:Memory

151:Camera input

152:Output

Claims (13)

An artificial intelligence device, the artificial intelligence device includes: first security processor; A security application, the security application is embedded in the first security processor, the security application is associated with an artificial intelligence (artificial intelligence, AI for short) model; a secure memory coupled to the first secure processor, the secure memory configured to store an AI executable binary file associated with the AI model; a second secure processor coupled to the secure memory, the second secure processor configured to execute the AI executable binary file stored in the secure memory ; Subsystem, the subsystem is coupled between the first security processor and the second security processor, the subsystem is configured to trigger input/output (Input/Output, IO for short) changes and trigger the second secure processor to execute the AI executable binary file stored in the secure memory; IO metadata, the IO metadata is stored in the secure memory; an IO validator coupled to the subsystem and the secure memory, the IO validator configured to validate IO changes by determining the IO metadata; and IO pre-issue module, the IO pre-issue module is coupled to the IO verifier, the IO pre-issue module is configured to, when the IO verifier determines that the IO change is consistent with the IO metadata When matched, the IO changes are patched to the AI executable binary file running on the second security processor. The artificial intelligence device of claim 1, wherein the IO metadata includes an IO address range, the IO change includes an IO address, and the IO verifier verifies whether the IO address is within the IO address range. Within, and when the IO verifier determines that the IO address is within the IO address range, the IO pre-issue module patches the IO address to all the devices running on the second security processor. The AI executable binary file described above. The artificial intelligence device of claim 1, wherein the IO metadata includes a plurality of different resolutions, the IO changes include resolution changes, and the IO verifier verifies whether the resolution changes are consistent with the IO metadata. Any one of the different resolutions specified in the information matches, and when the IO verifier determines that the resolution change matches one of the different resolutions, the IO pre-generated model The group patches the resolution change to the AI executable binary running on the second secure processor. The artificial intelligence device of claim 1, wherein the IO verifier is embedded in the second security processor. The artificial intelligence device of claim 1, wherein the IO pre-issuance module is embedded in the second security processor. As in claim 1, the artificial intelligence device further includes a secure operating system (OS) embedded in the first secure processor, and the secure OS is configured to provide a trusted execution environment. (trusted execution environment, TEE for short), in the trusted execution environment, the secure application is protected. The artificial intelligence device of claim 6, wherein the secure memory and the second secure processor are protected by a first firewall. The artificial intelligence device of claim 7, wherein the subsystem is protected by a second firewall different from the first firewall. The artificial intelligence device of claim 8, wherein the first firewall provides a higher security level than the second firewall. As claimed in claim 6, the artificial intelligence device further includes: Image signal processor (ISP for short), the ISP is coupled to the secure memory, the ISP is configured to process images and store the processed images in the secure memory ,as well as a facial biometric pattern that is secure within the TEE, wherein the second security processor executes the AI executable binary file to determine whether any of the processed images matches the facial biometric pattern. The artificial intelligence device of claim 1, wherein the first security processor includes a security central processing unit (CPU for short). The artificial intelligence device of claim 1, wherein the second security processor includes a secure deep learning accelerator (DLA for short). The artificial intelligence device of claim 12, wherein the DLA includes an accelerated processing unit (APU for short).

Images