Peripheral device access control using a bit mask indicating access settings for a peripheral device

Abstract

An electronic device includes a transaction host, first and second peripheral devices, a memory, an access control register, and first and second access controllers. The memory stores access control identifier management instructions, a first task related to the first peripheral device, and a first bitmask indicating respective access settings for the first peripheral device and the second peripheral device for performing the first task. The access control register includes a first access control identifier for the first peripheral device and a second access control identifier for the second peripheral device. The transaction host executes the access control identifier management instructions to program the first and second access control identifiers based on the first bitmask, and subsequently executes the first task. The first and second access controllers control access to the first and second peripheral devices based on the respective first and second access control identifiers programmed based on the first bitmask.

Description

[0001] Related patent applications

[0002] This patent application claims priority to IN Provisional Patent Application No. 202211000733, filed on January 6, 2022, the entire contents of which are incorporated herein by reference for all purposes. Technical Field

[0003] This disclosure relates to electronic devices including peripheral devices, and more specifically to peripheral device access control using a bitmask indicating access settings for the peripheral devices. Background Technology

[0004] A system-on-chip (SoC) is an integrated circuit (IC) that integrates an electronic or computer system onto a single chip. An SoC typically includes at least one processor (e.g., a central processing unit (CPU), microcontroller, or microprocessor (MPU)) and various peripherals (e.g., input / output ports, internal memory) as well as analog input / output blocks (e.g., a radio modem, a graphics processing unit (GPU), and / or one or more coprocessors), all on a single substrate or microchip. SoCs can be designed for a variety of functions, such as signal processing, wireless communication, or artificial intelligence.

[0005] In some SoCs, firmware running on the processor has full access to all peripherals on the SoC, regardless of the processor's current operating mode (e.g., privileged mode or user mode). This can lead to malfunctions or other undesirable consequences. For example, a faulty or malicious firmware device driver corresponding to one peripheral might erroneously (or maliciously) access and corrupt another peripheral, for example, by altering registers provided in the other peripheral.

[0006] There is a need for improved, low-cost access control for peripherals provided in SoCs or other electronic devices, for example, to protect peripherals from faulty or malicious firmware. Summary of the Invention

[0007] Systems and methods are provided for controlling access to peripheral devices in an electronic device (e.g., a SoC or other electronic device), for example, to protect the peripheral devices from erroneous or malicious access. Some examples provide programmable (e.g., updatable) access control identifiers corresponding to the respective peripheral device and the respective access controller, for controlling access to the respective peripheral device at least based on the access control identifier. The access control identifier may include one or more bits, referred to herein as access control bits. The access control identifier can be used to protect the peripheral device during the execution of a user-space task (e.g., device driver operation associated with the selected peripheral device). For example, in order to perform a corresponding task (e.g., device driver operation) associated with the selected peripheral device, a transaction host (e.g., a processor) may execute manager firmware or other manager code to program (e.g., set or update) the corresponding access control identifier in the access control register to (a) allow the corresponding task to access the selected peripheral device, and (b) prevent the corresponding task from accessing other peripheral devices, such as preventing the corresponding task from erroneously or maliciously accessing registers in any other peripheral device. In some examples, the access controller can enable the transaction host (e.g., a processor) to program (e.g., set or update) the appropriate access control identifier to allow the manager code to access all peripheral devices during privileged mode operation (e.g., execution of the relevant manager firmware).

[0008] In some examples, a corresponding bitmask is stored for a corresponding task (e.g., device driver operation), where the bitmask for the corresponding task indicates the corresponding access settings for the corresponding peripheral device for performing the corresponding task. Before executing the corresponding task, the transaction host can access the bitmask associated with the corresponding task and program (e.g., set or update) the corresponding access control identifier in the access control register. The programmed corresponding access control identifier can be accessed and used by the access controller associated with the corresponding peripheral device to control access to the corresponding peripheral device during the execution of the corresponding task.

[0009] In some applications, access control identifiers and access controllers can eliminate the need for complex software, thereby allowing for smaller or cheaper processors, such as those in a SoC.

[0010] One aspect provides an electronic device comprising: a transaction host, a first peripheral device, a second peripheral device, a first access controller connected to the first peripheral device, a second access controller connected to the second peripheral device, and an access control register storing a first access control identifier for the first peripheral device and a second access control identifier for the second peripheral device. The first access controller receives an access request from the transaction host to the first peripheral device, performs an access determination for the first peripheral device based at least on the first access control identifier for the first peripheral device, and allows or blocks the transaction host's access to the first peripheral device based on the access determination.

[0011] In some examples, the transaction host includes a processor or a direct memory access (DMA) engine.

[0012] In some examples, the transaction host includes a bridge that receives requests for access to a first peripheral device from an external host that is separate from the electronic device.

[0013] In some examples, the first access control identifier includes one or more first access control bits, and the second access control identifier includes one or more second access control bits.

[0014] In some examples, the electronic device includes firmware that can be executed by the transaction host to program at least one of a first access control identifier and a second access control identifier based on the transaction host's operating mode.

[0015] In some examples, the electronic device includes firmware that can be executed by the transaction host to dynamically program at least one of a first access control identifier for a first peripheral device and a second access control identifier for a second peripheral device between (a) an access permission setting that allows the transaction host to access the corresponding peripheral device and (b) an access blocking setting that prevents the transaction host from accessing the corresponding peripheral device.

[0016] In some examples, the electronic device includes firmware executable by a transaction host to program a first access control identifier and a second access control identifier, including (a) for privileged mode operation of the transaction host, programming both the first and second access control identifiers to an access permission setting that allows the transaction host to access both the first and second peripheral devices; and (b) for a first user mode operation of the transaction host, performing operations related to the first peripheral device to program the first access control identifier to an access permission setting that allows access to the first peripheral device and to program the second access control identifier to an access blocking setting that blocks access to the second peripheral device; and (c) for a second user mode operation of the transaction host, performing operations related to the second peripheral device to program the first access control identifier to an access blocking setting that blocks access to the first peripheral device and to program the second access control identifier to an access permission setting that allows access to the second peripheral device.

[0017] In some examples, the access controller performs access determination for the first peripheral device based at least on (a) a peripheral device-specific access control identifier for the first peripheral device and (b) an operating mode signal indicating the privileged mode or user mode of the transaction host.

[0018] In some examples, the first access control identifier for the first peripheral device and the second access control identifier for the second peripheral device respectively indicate (a) that restricted access settings for the respective peripheral device are allowed only in the privileged mode of the transaction master, or (b) that open access settings for the respective peripheral device are allowed in both the privileged mode and the user mode of the transaction master.

[0019] In some examples, the electronic device includes firmware that can be executed by the transaction host to program at least one of a first access control identifier and a second access control identifier between restricted access settings and open access settings.

[0020] In some examples, (a) if the first access control identifier for the first peripheral device indicates an open access setting and the operating mode signal indicates a privileged mode of the transaction host, the access controller determines to allow access to the first peripheral device; (b) if the first access control identifier for the first peripheral device indicates an open access setting and the operating mode signal indicates a user mode of the transaction host, the access controller determines to allow access to the first peripheral device; (c) if the first access control identifier for the first peripheral device indicates a restricted access setting and the operating mode signal indicates a privileged mode of the transaction host, the access controller determines to allow access to the first peripheral device; and (d) if the first access control identifier for the first peripheral device indicates a restricted access setting and the operating mode signal indicates a user mode of the transaction host, the access controller determines to block access to the first peripheral device.

[0021] In some examples, the transaction host can operate selectively in privileged mode and user mode, and at least one of the first access control identifier and the second access control identifier is programmable only in the privileged mode of the transaction host.

[0022] In some examples, the electronic device includes firmware running on the transaction host, and allowing or blocking access to the first peripheral device includes allowing or blocking access to the first peripheral device by the firmware running on the transaction host.

[0023] In some examples, the access control register is provided in a specified peripheral device among multiple peripheral devices.

[0024] In some examples, the electronic device includes an additional transaction host, wherein a first access control identifier and a second access control identifier are associated with the transaction host, and wherein an access control register stores a third access control identifier for a first peripheral device and associated with the additional transaction host, and a fourth access control identifier for a second peripheral device and associated with the additional transaction host. The access controller receives an additional access request from the additional transaction host to access the first peripheral device; performs an additional access determination for the first peripheral device based on (a) an access request identifier identifying the additional transaction host and (b) the third access control identifier; and, based on the additional access determination, allows or blocks access to the first peripheral device by the additional transaction host.

[0025] In some examples, the electronic device is a system-on-a-chip (SoC) device.

[0026] On the other hand, a method is provided, comprising: in an electronic device including a transaction host, a first peripheral device, a second peripheral device, and an access control register, storing (a) a first access control identifier for the first peripheral device and (b) a second access control identifier for the second peripheral device in the access control register. A first access controller associated with the first peripheral device receives a request from the transaction host to access the first peripheral device. The first access controller performs an access determination to allow or block access to the first peripheral device based at least on the first access control identifier for the first peripheral device, and allows or blocks access to the first peripheral device based on the access determination.

[0027] In some examples, the method includes the execution of firmware by the transaction host to program at least one of a first access control identifier and a second access control identifier based on the transaction host's operating mode.

[0028] In some examples, the method includes the transaction host executing firmware to dynamically program at least one of a first access control identifier for a first peripheral device and a second access control identifier for a second peripheral device between (a) an access permission setting that allows the transaction host to access the corresponding peripheral device and (b) an access blocking setting that prevents the transaction host from accessing the corresponding peripheral device.

[0029] In some examples, the method includes: executing firmware by a transaction host to program a first access control identifier and a second access control identifier, including (a) for privileged mode operation of the transaction host, setting both the first access control identifier and the second access control identifier to access-allow settings that respectively allow the transaction host to access both the first peripheral device and the second peripheral device; and (b) for a first user mode operation of the transaction host for performing operations related to the first peripheral device, setting the first access control identifier to an access-allow setting and setting the second access control identifier to an access-block setting that prevents access to the second peripheral device; and (c) for a second user mode operation of the transaction host for performing operations related to the second peripheral device, setting the first access control identifier to an access-block setting and setting the second access control identifier to an access-allow setting.

[0030] In some examples, the method includes an access determination performed by a first access controller to allow or block access to the first peripheral device, based at least on (a) a first access control identifier for the first peripheral device and (b) an operation mode signal indicating the privileged mode or user mode of the transaction host.

[0031] In some examples, the first access control identifier for the first peripheral device and the second access control identifier for the second peripheral device respectively indicate (a) preventing access to the restricted access settings of the corresponding peripheral device in the user mode of the transaction master, or (b) allowing access to the open access settings of the corresponding peripheral device in both the privileged mode and the user mode of the transaction master.

[0032] In some examples, the method includes having the transaction host execute firmware to dynamically program at least one of a first access control identifier and a second access control identifier between restricted access settings and open access settings.

[0033] In some examples, performing an access determination to allow or block access to a first peripheral device includes: (a) allowing access to the first peripheral device if the peripheral device-specific access control identifier for the first peripheral device indicates an open access setting and the operating mode signal indicates a privileged mode of the transaction host; (b) allowing access to the first peripheral device if the first access control identifier for the first peripheral device indicates an open access setting and the operating mode signal indicates a user mode of the transaction host; (c) allowing access to the first peripheral device if the first access control identifier for the first peripheral device indicates a restricted access setting and the operating mode signal indicates a privileged mode of the transaction host; and (d) blocking access to the first peripheral device if the first access control identifier for the first peripheral device indicates a restricted access setting and the operating mode signal indicates a user mode of the transaction host.

[0034] In some examples, the method includes allowing programming of the first access control identifier in privileged mode of the transaction host, and preventing programming of the first access control identifier in user mode of the transaction host.

[0035] On the other hand, a method is provided, comprising: in an electronic device including a transaction host, a first peripheral device, a second peripheral device, and an access control register, storing in the access control register a first access control identifier for the first peripheral device and a second access control identifier for the second peripheral device. The transaction host sets the first access control identifier and the second access control identifier to allow access to the first peripheral device and the second peripheral device, respectively, and the transaction host performs privileged mode operation at a first time. Subsequently, the transaction host sets (a) a first access control identifier that allows the transaction host to access the first peripheral device and (b) a second access control identifier that prevents the transaction host from accessing the second peripheral device, and performs user mode operation associated with the first peripheral device at a second time.

[0036] In some examples, the transaction master sets (a) a first access control identifier that prevents the transaction master from accessing the first peripheral device and (b) a second access control identifier that allows the transaction master to access the second peripheral device, and performs a user-mode operation related to the second peripheral device at a third time.

[0037] On the other hand, an electronic device is provided, including a first peripheral device, a second peripheral device, a non-transitory memory, an access control register, a transaction host, a first access controller, and a second access controller. The non-transitory memory stores: (a) manager firmware including access control identifier management instructions, (b) computer-readable code including a first task associated with the first peripheral device, and (c) a first bit mask corresponding to the first task, the first bit mask indicating corresponding access settings for the first and second peripheral devices for executing the first task. The access control register includes a first access control identifier for the first peripheral device and a second access control identifier for the second peripheral device. The transaction host executes the access control identifier management instructions in the manager firmware to program the first and second access control identifiers in the access control register based on the first bit mask corresponding to the first task, and after programming the first and second access control identifiers in the access control register based on the first bit mask, executes the first task associated with the first peripheral device. The first access controller controls access to the first peripheral device based at least on the first access control identifier programmed based on the first bit mask in the access control register, and the second access controller controls access to the second peripheral device based at least on the second access control identifier programmed based on the first bit mask in the access control register.

[0038] In some examples, the electronic device is a system-on-a-chip (SoC) device.

[0039] In some examples, the transaction host includes a processor or a direct memory access (DMA) engine.

[0040] In some examples, the first and second bit masks are stored in a bit mask data structure in non-temporary memory.

[0041] In some examples, the first bit mask includes one or more first bit mask bits indicating access settings for a first peripheral device to perform the first task, and one or more second bit mask bits indicating access settings for a second peripheral device to perform the first task, and the first access control identifier includes one or more first access control bits, and the second access control identifier includes one or more first access control bits.

[0042] In some examples, the computer-readable code includes a second task associated with a second peripheral device; a non-transitory memory storing a second bitmask corresponding to the second task, the second bitmask indicating corresponding access settings for the execution of the second task for the first and second peripheral devices; and access control identifier management instructions in the transaction host execution manager firmware to program a first access control identifier and a second access control identifier in the access control register based on the second bitmask corresponding to the second task, and (b) after programming the first access control identifier and the second access control identifier in the access control register based on the second bitmask, executing the first task associated with the second peripheral device.

[0043] In some examples, the non-transitory memory includes a non-privileged portion storing computer-readable code containing a first task and a second task, and a privileged portion storing manager firmware containing access control identifier management instructions and a first bit mask corresponding to the first task.

[0044] In some examples, the access controller receives from the transaction host an access request for accessing a first peripheral device in order to perform a first task; performs an access determination for the first peripheral device based at least on a first access control identifier, which is programmed based on a first bit mask corresponding to the first task; and based on the access determination, allows or blocks the transaction host from accessing the first peripheral device.

[0045] In some examples, the first access controller performs access determination for the first peripheral device based at least on (a) a first access control identifier programmed by the transaction host based on a first bit mask corresponding to the first task and (b) an operating mode signal indicating the privileged mode or user mode of the transaction host.

[0046] In some examples, the first bit mask corresponding to the first task indicates (a) that the first task is granted peripheral device access permission to the first peripheral device, and (b) that the first task is not granted peripheral device access permission to the second peripheral device.

[0047] In some examples, the first bit mask corresponding to the first task indicates (a) that the first task is granted peripheral device access permission to the first peripheral device, and (b) that the first task is not granted peripheral device access permission to the second peripheral device. Access control identifier management instructions program a first access control identifier and a second access control identifier in the access control register based on the first bit mask before executing the first task, including (a) programming the first access control identifier to an access-allowed value that allows access to the first peripheral device during the execution of the first task, and (b) programming the second access control identifier to an access-blocked value that prevents access to the second peripheral device during the execution of the first task. A first access controller allows access to the first peripheral device during the execution of the first task based on the access-allowed value of the first access control identifier, and a second access controller prevents access to the second peripheral device during the execution of the first task based on the access-blocked value of the second access control identifier.

[0048] In some examples, the transaction host selectively operates in privileged mode and user mode; and the first bit mask corresponding to the first task indicates (a) that the first task is granted peripheral device access permission to the first peripheral device, and (b) that the first task is not granted peripheral device access permission to the second peripheral device. Access control identifier management instructions program a first access control identifier and a second access control identifier in the access control register based on the first bit mask before executing the first task, including (a) programming the first access control identifier to an open access setting for the first peripheral device, which allows access to the first peripheral device in both privileged mode and user mode of the transaction host; and (b) programming the second access control identifier to a restricted access value for the second peripheral device, which allows access to the second peripheral device in privileged mode of the transaction host but not in user mode.

[0049] In some examples, the access control register is provided in a third peripheral device.

[0050] Another aspect provides a method. The method includes: storing, in an electronic device including a transaction host, a first peripheral device, a second peripheral device, and an access control register (including a first access control identifier for the first peripheral device and a second access control identifier for the second peripheral device), (a) computer-readable code including a first task associated with the first peripheral device, and (b) a first bit mask corresponding to the first task, the first bit mask indicating corresponding access settings for the first and second peripheral devices for performing the first task. Before performing the first task, the transaction host executes access control identifier management instructions to program the first and second access control identifiers in the access control register based on the first bit mask corresponding to the first task. After programming the first and second access control identifiers in the access control register based on the first bit mask, the transaction host performs the first task associated with the first peripheral device. During the execution of the first task: a first access controller associated with the first peripheral device controls access to the first peripheral device at least based on the first access control identifier programmed based on the first bit mask in the access control register, and a second access controller associated with the second peripheral device controls access to the second peripheral device at least based on the second access control identifier programmed based on the first bit mask in the access control register.

[0051] In some examples, the method includes: storing computer-readable code including a second task associated with a second peripheral device; and storing a second bitmask corresponding to the second task, the second bitmask indicating corresponding access settings for the first and second peripheral devices for executing the second task. Before executing the second task, the transaction host executes access control identifier management instructions to program a first access control identifier and a second access control identifier in an access control register based on the second bitmask corresponding to the second task. After programming the first and second access control identifiers in the access control register based on the second bitmask, the transaction host executes the second task associated with the second peripheral device. During the execution of the second task: a first access controller associated with the first peripheral device controls access to the first peripheral device at least based on the first access control identifier in the access control register programmed based on the second bitmask, and a second access controller associated with the second peripheral device controls access to the second peripheral device at least based on the second access control identifier in the access control register programmed based on the second bitmask.

[0052] In some examples, the first access controller controls access to the first peripheral device based at least on a first access control identifier programmed based on a first bit mask. This includes the first access controller: receiving an access request from the transaction host for performing a first task to access the first peripheral device; performing an access determination for the first peripheral device based at least on the first access control identifier programmed based on a first bit mask; and allowing or blocking the transaction host's access to the first peripheral device based on the access determination.

[0053] In some examples, the method includes a first access controller performing access determination to a first peripheral device based at least on (a) a first access control identifier programmed based on a first bit mask and (b) an operating mode signal indicating the privileged mode or user mode of the transaction host.

[0054] In some examples, the first bit mask corresponding to the first task indicates (a) that the first task is granted peripheral device access permission to the first peripheral device, and (b) that the first task is not granted peripheral device access permission to the second peripheral device. Access control identifier management instructions are executed to program a first access control identifier and a second access control identifier in the access control register based on the first bit mask corresponding to the first task, including (a) programming the first access control identifier to an access-allowed value that allows access to the first peripheral device during the execution of the first task, and (b) programming the second access control identifier to an access-blocked value that prevents access to the second peripheral device during the execution of the first task. During the execution of the first task: a first access controller associated with the first peripheral device allows access to the first peripheral device based on the access-allowed value of the first access control identifier, and a second access controller associated with the second peripheral device prevents access to the second peripheral device based on the access-blocked value of the second access control identifier.

[0055] In some examples, the transaction host selectively operates in privileged mode and user mode, and the first bit mask corresponding to the first task indicates (a) that the first task is granted peripheral device access permission to the first peripheral device, and (b) that the first task is not granted peripheral device access permission to the second peripheral device. Executing access control identifier management instructions to program the first and second access control identifiers in the access control register based on the first bit mask corresponding to the first task includes: (a) programming the first access control identifier to an open access value for the first peripheral device, which allows access to the first peripheral device in both privileged mode and user mode of the transaction host; and (b) programming the second access control identifier to a restricted access value for the second peripheral device, which allows access to the second peripheral device in privileged mode of the transaction host but not in user mode. During the execution of the first task: the first access controller associated with the first peripheral device allows access to the first peripheral device in both privileged mode and user mode of the transaction host based on the open access value of the first access control identifier, and the second access controller associated with the second peripheral device prevents access to the second peripheral device in privileged mode of the transaction host based on the restricted access value of the second access control identifier, but does not prevent access to the second peripheral device in user mode of the transaction host. Attached Figure Description

[0056] Exemplary aspects of this disclosure are described below with reference to the accompanying drawings, in which:

[0057] Figure 1 An example electronic device (e.g., SoC) is shown, which uses an access control identifier to control access to peripheral devices according to an example.

[0058] Figure 2 An example is shown. Figure 1 Additional aspects of example electronic devices;

[0059] Figure 3 Another example electronic device is shown, based on an example, which uses access control identifiers to control access to peripheral devices;

[0060] Figures 4A to 4D Circuit diagrams of example logic circuits provided in the corresponding access controllers are shown, based on some examples;

[0061] Figure 5 This is a flowchart of an example method for controlling access to peripheral devices in an electronic device using access control identifiers stored in an access control register;

[0062] Figure 6This is a flowchart of an example method for controlling access to peripheral devices in an electronic device using a first example access control identifier scheme;

[0063] Figure 7 This is a flowchart of an example method for controlling access to peripheral devices in an electronic device using a second example access control identifier scheme; and

[0064] Figure 8 This is a flowchart of an example method for controlling access to peripheral devices in an electronic device for both privileged mode operation and user mode operation, based on an example.

[0065] Figure 9 This is a flowchart of an example method for controlling access to peripheral devices using task-related bitmasks.

[0066] It should be understood that reference numerals for any illustrated element appearing in multiple different figures have the same meaning in all figures, and any illustrated element mentioned or discussed herein in the context of any particular figure also applies to every other figure (if any) in which the same illustrated element is shown. Detailed Implementation

[0067] Figure 1 An example electronic device 100 is shown, according to one example, using access control identifiers to control access to peripheral devices. These access control identifiers may be programmable; for example, a corresponding access control identifier may be set and / or updated over time. Electronic device 100 includes a transaction host 102, peripheral devices 104, an access controller 106, and an access control register 110 storing access control identifiers 112. Components of electronic device 100 may be communicatively connected to each other via any type or multiple types of communication links 114 (e.g., bus, wire, or other types of links). In some examples, the access controller 106 may be connected between the bus and the corresponding peripheral device 104, or alternatively, it may be indirectly connected to the bus and operable to determine access to selected communications with peripheral devices 104a-104n connected to the bus.

[0068] In some examples, electronic device 100 is a system-on-a-chip (SoC) device. In other examples, electronic device 100 may be a multi-chip system, including a transaction host 102 provided on one chip and peripheral devices 104 provided on separate chips. Transaction host 102 may include any device capable of initiating the execution of tasks associated with the corresponding peripheral device 104, such as tasks accessing registers set in the corresponding peripheral device 104. For example, transaction host 102 may include a processor, such as a microprocessor, microcontroller, central processing unit (CPU), processor core, direct memory access (DMA) engine, or any other type of computer processor. As another example, transaction host 102 may include a bridge connected to an external host 116 (e.g., including a processor separate from electronic device 100) to allow external host 116 to access at least one peripheral device 104.

[0069] Peripheral device 104 (e.g., including input / output devices and / or other peripheral devices) may include any device that provides input, output, or data storage functionality for electronic device 100, such as one or more PCI Express interfaces, Ethernet interfaces, USB interfaces, I / O interfaces, etc. 2 Interfaces include: C (Inter-Integrated Circuits) interface, Direct Memory Access (DMA) controller, interrupt controller, analog-to-digital converter (ADC), Wi-Fi interface, Bluetooth interface, Global System for Mobile Communications (GSM) interface, General Packet Radio Service (GPRS) interface, Global Positioning System (GPS) interface, 3G interface, 4G interface, 5G interface, Universal Asynchronous Receiver / Transmitter (UART), Controller Area Network Flexible Data Rate (CAN-FD) interface, General Purpose Input / Output (GPIO) interface, display device interface, modem, graphics processing unit (GPU) or coprocessor.

[0070] Electronic device 100 may include any number of peripheral devices 104. Figure 1 The example electronic device 100 shown includes peripheral devices 104a-104n, but it should be understood that electronic device 100 may include any number of one or more peripheral devices.

[0071] The corresponding access controller 106 can be connected to the corresponding peripheral device 104 to control (e.g., allow or block) access to the corresponding peripheral device 104, for example, through a device driver (firmware) executed by the transaction host 102. For example, see the following reference... Figure 2As discussed, the transaction host 102 can execute firmware to perform various tasks related to the peripheral device 104. For example, the transaction host 102 can execute device drivers corresponding to the respective peripheral devices 104a-104n to perform tasks related to the respective peripheral devices 104a-104n (e.g., device driver tasks). The access controller 106 can control (e.g., allow or block) access to the respective peripheral device 104 for the respective tasks performed by the transaction host 102.

[0072] As shown in the figure, the electronic device 100 may include corresponding access controllers 106a-106n corresponding to the respective peripheral devices 104a-104n. For example, a first access controller 106a may be connected between the transaction host 102 and the first peripheral device 104a to control access to the first peripheral device 104a by the transaction host 102, a second access controller 106b may be connected between the transaction host 102 and the second peripheral device 104b to control access to the second peripheral device 104b by the transaction host 102, and so on. For example, the first access controller 106a may allow access to a first task of the first peripheral device 104a (e.g., associated with a first device driver corresponding to the first peripheral device 104a) and block access to a second task of the first peripheral device 104a (e.g., associated with a second device driver corresponding to the second peripheral device 104b). Similarly, the second access controller 106b can allow access to a second task of the second peripheral device 104b (associated with a second device driver corresponding to the second peripheral device 104b) and block access to a first task of the second peripheral device 104b (associated with a first device driver corresponding to the first peripheral device 104a).

[0073] The corresponding access controllers 106a-106n may include electronic circuitry to control (e.g., allow or block) access by the transaction host 102 to the corresponding peripheral devices 104a-104n based on the corresponding access control identifier 112 stored in the access control register 110 and additional access control input data in some alternative examples. As described below, the additional access control input data may include, for example, (a) an operation mode signal (OMS) 120 indicating the operation mode of the transaction host 102 and / or (b) an access request identifier of the corresponding transaction host 102 requesting access to the corresponding peripheral device 104 (hereinafter referred to in relation to an example including multiple transaction hosts 102). Figure 3 Let's discuss.

[0074] In some examples, the access control identifiers (also referred to herein as "AC identifiers") 112 stored in the access control register 110 include corresponding access control identifiers 112a-112n corresponding to the respective peripheral devices 104a-104n, including a first access control identifier 112a corresponding to the first peripheral device 104a, a second access control identifier 112b corresponding to the second peripheral device 104b, and so on. The corresponding access control identifiers 112a-112n for the respective peripheral devices 104a-104n may include one bit, multiple bits, or other data indicating access settings for the respective peripheral devices 104a-104n. For example, the first access control identifier 112a may include one or more bits indicating access settings for the first peripheral device 104a, and the second access control identifier 112a may include one or more bits indicating access settings for the second peripheral device 104b. The access control register 110 may include a single register or multiple registers of any suitable size, for example, including one or more 8-bit registers, 32-bit registers, or 64-bit registers.

[0075] For reference below Figure 2As discussed, the transaction host 102 can program (e.g., set or update) the values ​​of the corresponding access control identifiers 112a-112n based on the peripheral device access permissions assigned to the corresponding task before executing the corresponding task (e.g., a firmware task). As discussed below, the electronic device 100 can store a corresponding bitmask for the corresponding task, indicating the peripheral device access permissions for the corresponding task, for example, wherein the corresponding bitmask for the corresponding task indicates whether the corresponding task is assigned peripheral device access permissions to the corresponding peripheral devices 104a to 104n (or is not assigned peripheral device access permissions to the corresponding peripheral devices 104a to 104n). For example, electronic device 100 may store a first bitmask for a first task, indicating that the first task is granted peripheral device access permission to the first peripheral device 104a but not to the second peripheral device 104b, and a second bitmask for a second task, indicating that the second task is granted peripheral device access permission to the second peripheral device 104b but not to the first peripheral device 104a. In some examples, peripheral device access permissions may be granted by a code developer (e.g., a firmware developer) based, for example, on selected peripheral devices that the corresponding task may need or utilize (using a corresponding bitmask for the corresponding task). In some examples, corresponding access controllers 106a-106n associated with corresponding peripheral devices 104a-104n make access determinations for accessing the corresponding peripheral devices 104a-104n based on corresponding access control identifiers 112a-112n corresponding to the corresponding peripheral devices 104a-104n. In other examples, the corresponding access controllers 106a-106n associated with the corresponding peripheral devices 104a-104n make access determinations for accessing the corresponding peripheral devices 104a-104n based on (a) the corresponding access control identifiers 112a-112n corresponding to the corresponding peripheral devices 104a-104n and (b) the operation mode signal 120 indicating the current operation mode (e.g., privileged mode or user mode) of the transaction host 102.

[0076] In other examples, multiple processing hosts 102 are provided, and corresponding access controllers 106a-106n associated with the corresponding peripheral devices 102a-104n make access determinations for access to the corresponding peripheral devices 104a-104n by the requesting transaction host 102 (or multiple transaction hosts 102) based on (b) a transaction host identifier that identifies the requesting transaction host 102 and (b) corresponding access control identifiers 112a-112n for the peripheral devices 104a-104n and corresponding to the requesting transaction host 102. (For example, where the access control register 110 stores the set of corresponding access control identifiers 112a-112n for the peripheral devices 104a-104n for the corresponding transaction host 102.) In other examples, multiple processing hosts 102 are provided, and corresponding access controllers 106a-106n associated with corresponding peripheral devices 102a-104n make access determinations for access to the corresponding peripheral devices 104a-104n by the requesting transaction host 102 (or multiple transaction hosts 102) based on (b) a transaction host identifier that identifies the requesting transaction host 102 and (b) corresponding access control identifiers 112a-112n corresponding to the peripheral devices 104a-104n and corresponding to the requesting transaction host 102, and (c) an operation mode signal 120 indicating the current operation mode (e.g., privileged mode or user mode) of the requesting transaction host 102 (e.g., where the access control register 110 stores the corresponding set of access control identifiers 112a-112n for the peripheral devices 104a-104n for the corresponding transaction host 102.

[0077] Typically, when transaction host 102 attempts to access a corresponding peripheral device 104 (e.g., first peripheral device 104a), first access controller 106a may (a) receive an access request for accessing first peripheral device 104a from transaction host 102; (b) access access control identifier 112 for first peripheral device 104a from access control register 110; (c) perform an access determination based on first access control identifier 112a (and, in some examples, additional access control input data); and (d) in response to the access determination, allow or block access to first peripheral device 104a by transaction host 102.

[0078] In the first example, as shown in Table 1 below, the corresponding access control identifiers 112a-112n are programmable between the following access control identifier (AC_ID) values:

[0079] (a) Access permission settings (e.g., AC_ID value = [0]) that allow transaction host 102 to access the corresponding peripheral devices 104a-104n (e.g., to execute device drivers or other firmware), and

[0080] (b) Access blocking settings (e.g., AC_ID value = [1]) that prevent transaction host 102 from accessing the corresponding peripheral devices 104a-104n (e.g., executing device drivers or other firmware).

[0081] Table 1. Access Control Identifier Scheme for the First Example .

[0082] 0 (Access Allowed) yes 1 (Access blocked) no

[0083] In some examples, the corresponding access controllers 106a-106n may store or access a lookup table (LUT) containing the data of Table 1, which the corresponding access controllers 106a-106n may access for making an access determination. In some examples, the corresponding access controllers 106a-106n may store the corresponding LUT in memory 107 (e.g., a read-only memory (ROM) device) (where a corresponding instance of memory 107 may be provided in the corresponding access controllers 106a-106n, or where memory 107 may be otherwise accessed by the corresponding access controllers 106a-106n). In other examples, the corresponding access controllers 106a-106n may use a suitable instance of logic circuitry 108 to implement the decisions specified in Table 1. For example, as referenced below... Figure 4A The respective access controllers 106a-106n discussed may include logic circuitry 108, which includes NOT gates (or inverters) for processing access control identifiers input to the respective access controllers 106a-106n. (In another example, the meaning of the AC_ID value may be reversed, for example, where AC_ID = 0 indicates an access blocking setting and AC_ID = 1 indicates an access allowing setting, and the NOT gate may be omitted.)

[0084] In the first example (i.e., implementing the scheme shown in Table 1), the transaction host 102 can execute the corresponding firmware (e.g., the access control identifier management instructions 214 provided in computer-readable manager code 206, embodied in the firmware, as discussed below). Figure 2 (As shown) Access control identifiers 112a-112n are dynamically programmed according to the above scheme, for example, in real time, based on the current operating mode of the transaction master (e.g., privileged mode or user mode) and / or before initiating a task related to a specific peripheral device 104a-104n (e.g., using the device driver corresponding to the specific peripheral device 104a-104n). For example:

[0085] (a) Before initiating a privileged mode task associated with any peripheral devices 104a-104n, transaction host 102 may program AC identifiers 112a-112n to 0 (allowing transaction host 102 to access peripheral devices 104a-104n).

[0086] (b) Before initiating a user-mode task related to the first peripheral device 104a, the transaction host 102 may program AC identifier 112a to 0 and AC identifiers 112b...112n to 1 (allowing the transaction host 102 to access the first peripheral device 104a and preventing access to peripheral devices 104b...104n); and

[0087] (c) Before initiating a user-mode task related to the second peripheral device 104b, the transaction host 102 may program the AC identifier 112b to 0 and the AC identifiers 112a, 112c...112n to 1 (allowing the transaction host 102 to access the second peripheral device 104b and preventing access to peripheral devices 104a, 104c...104n).

[0088] In the first example, the corresponding access controllers 106a-106n associated with specific peripheral devices 104a-104n make access determinations for accessing specific peripheral devices 104a-104n based on the current values ​​of the corresponding access control identifiers 112a-112n corresponding to the specific peripheral devices 104a-104n, for example, without the additional need for an operation mode signal indicating the current operation mode of the transaction host 102. For example, when the first access controller 106a associated with the first peripheral device 104a receives an access request for accessing the first peripheral device 104a from the transaction host 102, the first access controller 106a accesses the corresponding AC identifier 112a corresponding to the first peripheral device 104a, and based on the AC identifier 112a, if the AC_ID value = 0, then the transaction host 102 is allowed to access the first peripheral device 104a, and if the AC_ID value = 1, then the transaction host 102 is prevented from accessing the first peripheral device 104a.

[0089] According to the scheme of the first example above, in one example instance, the transaction host 102 can use the first peripheral device driver corresponding to the first peripheral device 104a to execute a first user space task associated with the first peripheral device 104a, and therefore can program the AC identifier 112a to 0 before executing the first task (e.g., using...). Figure 2(See Access Control Identifier Management Instruction 214 shown). If the first access controller 106a receives a request to access the first peripheral device 104a from the first peripheral device driver, the first access controller 106a can access the AC identifier 112a, and in response to the AC identifier 112a value = 0, access to the first peripheral device 104a is permitted. In another example instance, the transaction host 102 can use the second peripheral device driver corresponding to the second peripheral device 104b to perform a second userspace task associated with the second peripheral device 104b, and therefore can program the AC identifier 112b to 0 to allow access to the second peripheral device 104b, and program the AC identifier 112a to 1 to prevent access to the first peripheral device 104a. If the first access controller 106a receives a request to access the first peripheral device 104a from the second peripheral device driver (e.g., an erroneous or malicious request from the second peripheral device driver), the first access controller 106a may access the AC identifier 112a and, in response to the value of AC identifier 112a = 1, prevent access to the first peripheral device 104a. In yet another example instance, the transaction host 102 may perform privileged tasks related to the first peripheral device 104a or the second peripheral device 104b (e.g., included in the manager firmware), and thus may program AC identifier 112a to 0 or AC identifier 112b to 0 respectively before performing such privileged tasks, thereby allowing access to the first peripheral device 104a by the first peripheral device driver corresponding to the first peripheral device 104a or the second peripheral device driver corresponding to the second peripheral device 104b.

[0090] In the second example, as shown in Table 2 below, each access control identifier 112a-112n is programmable between the following access control identifier (AC_ID) values:

[0091] (a) An open access setting (e.g., AC_ID value = [0]) that allows transaction host 102 to access the corresponding peripheral devices 104a-104n (e.g., to execute device drivers or other firmware), regardless of the current operating mode of transaction host 102 (e.g., privileged mode or user mode), and

[0092] (b) Restricted access settings (e.g., AC_ID value = [1]) that allow the transaction host 102 to access the corresponding peripheral devices 104a-104n (e.g., to execute device drivers or other firmware) only in the privileged mode of the transaction host 102.

[0093] Table 2. Access Control Identifier Scheme for the Second Example .

[0094] 0 (Open Access) 0 (User Mode) yes 0 (Open Access) 1 (Privileged Mode) yes 1 (Restricted Access) 0 (User Mode) no 1 (Restricted Access) 1 (Privileged Mode) yes

[0095] In some examples, the corresponding access controllers 106a-106n can store or access the LUT containing the data in Table 2, and the corresponding access controllers 106a-106n can access the lookup table to make an access determination. In some examples, the corresponding access controllers 106a-106n can store the corresponding LUT in the corresponding instance of memory 107 (e.g., read-only memory ROM) device (where memory 107 may be provided in the corresponding access controllers 106a-106n, or memory 107 may be accessed by the corresponding access controllers 106a-106n in other ways). In other examples, the corresponding access controllers 106a-106n can use the corresponding instance of suitable logic circuitry 108 to implement the decisions specified in Table 2. For example, as referenced below... Figure 4B The respective access controllers 106a-106n discussed may include logic circuitry 108, which includes NOT and OR gates for processing access control identifiers input to the respective access controllers 106a-106n.

[0096] In the second example (i.e., implementing the scheme shown in Table 2), the transaction host 102 can execute the corresponding firmware (e.g., Figure 2 The access control identifier management instruction 214 shown is used to dynamically program access control identifiers 112a-112n according to the above scheme, such as in real time, based on the current operating mode of the transaction host (e.g., privileged mode or user mode) and / or by initiating tasks related to specific peripheral devices 104a-104n (e.g., using the device driver corresponding to the specific peripheral device 104a-104n). For example:

[0097] (a) In order to initiate a task related to the first peripheral device 104a (regardless of the operating mode of the transaction host 102), the transaction host 102 may program AC identifier 112a to 0 and AC identifiers 112b, 112c...112n to 1 (as discussed below, allowing the transaction host 102 to access the first peripheral device 104a in both privileged mode and user mode, while preventing the transaction host 102 from accessing peripheral devices 104b, 104c...104n in user mode); and

[0098] (b) In order to initiate a task related to the second peripheral device 104b (regardless of the operating mode of the transaction host 102), the transaction host 102 may program the AC identifier 112b to 0 and the AC identifiers 112a, 112c...112n to 1 (as discussed below, allowing the transaction host 102 to access the second peripheral device 104b in both the privileged mode and user mode of the transaction host 102, while preventing the transaction host 102 from accessing the peripheral device 104a, 104c...104n in the user mode of the transaction host 102).

[0099] In the second example, the corresponding access controllers 106a-106n associated with specific peripheral devices 104a-104n make an access determination for accessing specific peripheral devices 104a-104n based on (a) the current value of the corresponding access control identifiers 112a-112n corresponding to the specific peripheral devices 104a-104n and (b) the operation mode signal 120 indicating the operation mode (privileged mode or user mode) of the transaction host 102. For example, when the first access controller 106a associated with the first peripheral device 104a receives an access request for accessing the first peripheral device 104a from the transaction host 102, the first access controller 106a accesses (a) the AC identifier 112a corresponding to the first peripheral device 104a and (b) the operation mode signal 120, and determines whether to allow the transaction host 102 to access the first peripheral device 104a based on the scheme defined in Table 2. Specifically, the first access controller 106a determines that the transaction host 102 is allowed to access the first peripheral device 104a unless (a) the AC_ID value = 1 (restricted access setting) and (b) the operation mode signal value = 0 (user mode).

[0100] According to the scheme of the second example above, in one example instance, the transaction host 102 can initiate a user-mode task associated with the first peripheral device 104a, and therefore can program the AC identifier 112a to 0 to initiate such a task. If the first access controller 106a receives a request to access the first peripheral device 104a from the first peripheral device driver, the first access controller 106a can (a) access the AC identifier 112a; (b) access the operation mode signal 120; (c) if the operation mode signal 120 indicates user mode (operation mode signal value = 0) or privileged mode (operation mode signal value = 1), then perform an access determination to allow the first peripheral device driver to access the first peripheral device 104a, and otherwise prevent the first peripheral device driver from accessing the first peripheral device 104a; and (d) based on the access determination, allow or prevent the first peripheral device driver from accessing the first peripheral device 104a.

[0101] In another example instance, the transaction host 102 can use the second peripheral device driver corresponding to the second peripheral device 104b to initiate a user-mode task associated with the second peripheral device 104b, and thus can program the AC identifier 112b to 0 (i.e., open access to the second peripheral device 104b) and can program the AC identifier 112a to 1 (i.e., restrict access to the first peripheral device 104a). If the first access controller 106a receives a request from the second peripheral device driver for access to the first peripheral device 104a, the first access controller 106a may (a) access the AC identifier 112a; (b) access the operation mode signal 120; and (c) the second peripheral device driver performs an access determination to allow or block the first peripheral device 104a, specifically, if the operation mode signal 120 indicates privileged mode (operation mode signal value = 1), then access is allowed, and if the operation mode signal 120 indicates user mode (operation mode signal value = 0), then access is blocked; and (d) based on the access determination, allow or block access to the first peripheral device 104a by the second peripheral device driver.

[0102] like Figure 1 As shown, the corresponding access controllers 106a-106n can receive the following as inputs: (a) an access request (ACR) for the corresponding peripheral device 104a-104n, (b) the corresponding AC identifier 112a-112n, and (optionally) (c) an operation mode signal 120, and process the received inputs to make an access determination for the corresponding peripheral device 104a-104n. For simplicity, the access request ( Figure 1-2 The ACR and shown in the figure Figure 3 The TH_id shown in the figure) and the optional operation mode signal ( Figure 1-2 120 and Figure 3 (120a-120n) in Figure 1-3 The signal is shown as being sent only to access controller 106a; it should be understood that access requests and optional operating mode signals can be similarly sent to access controllers 106b-106n for operations associated with the respective access controllers 106b-106n.

[0103] As discussed above, in some examples, the corresponding access controllers 106a-106n of example electronic device 100 may include (or access) corresponding lookup tables (LUTs) stored in memory 107 (e.g., ROM), which define corresponding access determinations for each AC_ID value (e.g., according to the scheme defined in Table 1 above) or define corresponding access determinations for each combination of AC_ID values ​​and operating mode signal values ​​(e.g., according to the scheme defined in Table 2 above). In other examples, such as those discussed below... Figure 4A and Figure 4B As shown, the corresponding access controllers 106a-106n may include instances of logic circuitry 108, which contains one or more logic gates, such as NOT gates (e.g., implementing the scheme defined in Table 1 above), OR gates, and OR gates (e.g., implementing the scheme defined in Table 2 above).

[0104] In some examples, electronic device 100 may include AC identifier programming firmware executable by transaction host 102 to dynamically program one, some, or all of the AC identifiers 112a-112n, for example, based on the transaction host's operating mode and / or based on the corresponding peripheral devices 104a-104n selected for access (referred to herein as the requested peripheral devices 104a-104n), for example, to initiate a task associated with the corresponding peripheral device 104a-104n. Furthermore, in some examples, as referenced below… Figure 2 The access control register 110 discussed is provided in a dedicated peripheral device (similar to peripheral devices 104a-104n), which can also be accessed and controlled by a corresponding access controller. For example, the AC identifier programming firmware can access the access control register 110 only in the privileged mode of the transaction host 102 and not in the user mode of the transaction host 102 (e.g., to program AC identifiers 112a-112n).

[0105] Figure 2 An example is shown. Figure 1Additional features and aspects of the electronic device (e.g., SoC) 100. As described above, the electronic device 100 includes a transaction host 102, peripheral devices 104a-104n, access controllers 106a-106n, and an access control register 110 storing access control identifiers 112a-112n. Components of the electronic device 100 can be communicatively connected to each other via any type or multiple types of communication links 114 (e.g., bus, wire, or other types of links). As described above, each access controller 106a-106n uses each access control identifier 112a-112n (and optional additional input data) to control access to each peripheral device 104a-104n, for example, based on the operating mode of the transaction host 102 (e.g., privileged mode or user mode) and / or based on the peripheral device 104a-104n to which access is requested (i.e., the peripheral device 104a-104n for which access is requested). Access controllers 106a-106n can, for example, use the access control identifier schemes shown in Table 1 or Table 2 above to implement any of the various example schemes described above.

[0106] like Figure 2 As shown, an access control register 110 including access control identifiers 112a-112n can be provided in the dedicated peripheral device 104ac, and a corresponding access controller 106ac can be provided to control access to the peripheral device 104ac, for example, similar to access controllers 106a-106n that control access to peripheral devices 104a-104n respectively. For example, access controller 106ac can control access to peripheral device 104ac based on the operation mode signal 120 from the transaction host 102 and (optionally) the corresponding AC identifier 112ac. In some examples, access controller 106ac can control access to peripheral device 104ac based on the operation mode signal 120 from the transaction host 102. In other examples, access controller 106ac can operate similarly to access controllers 106a-106n, for example, based on the corresponding AC identifier 112ac and / or operation mode signal 120 and using the access control identifier scheme shown in Table 1 or Table 2 above.

[0107] like Figure 2 As shown, the electronic device 100 may also include a non-transitory memory 202 for storing various firmware and other data. The non-transitory memory 202 (also referred to as memory 202) may include one or more read-only memories (ROMs), such as flash ROMs, erasable programmable ROMs (PROMs), electrically erasable programmable ROMs (EEPROMs), flash memory, or any other suitable type and number of memory devices.

[0108] As shown, memory 202 may include a privileged portion 202a and a non-privileged portion (or user portion) 202b. The non-privileged portion 202b may store computer-readable user-space code 208, for example, embodied in firmware (e.g., device drivers and / or other user-space firmware associated with the respective peripherals 104a-104n). The user-space code (e.g., user-space firmware) 208 may include functionality that requires or can utilize access only to selected resources (e.g., those selected from peripherals 104a-104n). For example, user-space code 208 may include device drivers or other firmware (including corresponding tasks 220a-220n) that require or can utilize access to selected peripherals 104a-104n, for example, to access data stored in corresponding registers 214a-214n provided by the respective peripherals 104a-104n. Therefore, a device driver that normally operates as manager firmware can operate as user-space firmware that can only access selected resources (e.g., selected peripheral devices 104a-104n) to thereby provide enhanced security as described herein.

[0109] Privileged portion 202a may store manager code (e.g., manager firmware) 206 and bitmask data structure 230. Bitmask data structure 230 may include bitmasks 232a-232n corresponding to tasks 230a-230n respectively, wherein the corresponding bitmask 232n for the corresponding task 230n indicates the corresponding access settings for the corresponding peripheral devices 104a-104n, for example, indicating whether the corresponding task 230n is granted peripheral device access permission to the corresponding peripheral devices 104a-104n. For example, refer to... Figure 2 The task 1 bitmask 232a corresponding to "Task 1" 220a can indicate that "Task 1" 220a is granted peripheral device access permission to the first peripheral device 104a, but not to the second peripheral device 104b. The task 2 bitmask 232b corresponding to "Task 2" 220b can indicate that "Task 2" 220b is granted peripheral device access permission to the second peripheral device 104b, but not to the first peripheral device 104a.

[0110] In some examples, the corresponding bitmasks 232a-232n for the corresponding tasks 220a-220n may include one or more bits (also referred to herein as "bitmask bits") or other data indicating whether the corresponding task 220a-220n is granted peripheral device access permission to the corresponding one of peripheral devices 104a-104n. For example, the task 1 bitmask 232a corresponding to "task 1" 220a may include one or more first mask bits or other data indicating that "task 1" 220a is granted peripheral device access permission to the first peripheral device 104a, and one or more second bitmasks or other data indicating that "task 1" 220a is not granted peripheral device access permission to the second peripheral device 104b.

[0111] Manager code (e.g., manager firmware) 206 may include scheduler 212 and access control identifier management instructions 214. Scheduler 212 is executed by transaction host 102 to manage the execution of user space code (e.g., user space firmware) 208, including tasks 220a-220n. Access control identifier management instructions 214 may be executed by transaction host 102 to (a) access bitmasks 232a-232n and (b) program the values ​​of access control identifiers 112a-112n in access control register 110 based on the corresponding bitmasks 232a-232n corresponding to the corresponding tasks 220a-220n to be executed. In some examples, such as certain implementations of the first example access control identifier scheme described above (see Table 1), the transaction host 102 may utilize bitmasks 232a-232n for user-mode operations (e.g., executing corresponding tasks 220a-220n in user mode) but not for privileged-mode operations (e.g., executing corresponding tasks 220a-220n in privileged mode). (In other implementations of the first example access control identifier scheme (shown in Table 1), the transaction host 102 may utilize bitmasks 232a-232n for both user-mode and privileged-mode operations).

[0112] For example, before executing "Task 1" 220a, the transaction host 102 may execute access control identifier management instructions 214 to program the values ​​of access control identifiers 112a-112n in the access control register 110 based on the Task 1 bitmask 232a and / or based on the operating mode of the transaction host 102 (e.g., privileged mode or user mode). Example implementations under the first example access control identifier scheme described above (see Table 1) and the second example access control identifier scheme described above (see Table 2) are provided.

[0113] Example 1: First example access control identifier scheme (Table 1). Under the first example access control identifier scheme described above (see Table 1), transaction host 102 can use the task 1 bitmask 232a to execute "Task 1" 220a in user mode, but not in privileged mode. For example, before executing "Task 1" 220a in user mode, transaction host 102 may execute access control identifier management instruction 214 to (a) identify that "Task 1" 220a will be executed in user mode of transaction host 102, (b) access the first mask 232a, which indicates that "Task 1" 220a is granted peripheral access permission to the first peripheral device 104a but not to the second peripheral device 104b, and (c) program the first access control identifier 112a to an access-allowed value (AC_ID value = 0) based on the first mask 232a and the current operating mode (user mode), which allows access to the first peripheral device 104a during user mode execution of "Task 1" 220a, and (b) program the second access control identifier 112b to an access-blocked value (AC_ID value = 0), which prevents access to the second peripheral device 104b during user mode execution of "Task 1" 220a. In contrast, before executing "Task 1" 220a in privileged mode (under the first example access control identifier scheme shown in Table 1 above), transaction host 102 can execute access control identifier management instruction 214 to program both the first access control identifier 112a and the second access control identifier 112b as access-allowed values ​​(AC_ID value = 0), which allow access to both the first peripheral device 104a and the second peripheral device 104b during the privileged mode execution of "Task 1" 220a. In this case, transaction host 102 can ignore the Task 1 bitmask 232a because all peripheral devices 104a-104n are accessible for privileged mode operation.

[0114] As described above, in other examples utilizing the first example access control identifier scheme (shown in Table 1), transaction host 102 can utilize bitmasks 232a-232n for both user mode and privileged mode operations.

[0115] Example 2: Second Example Access Control Identifier Scheme (Table 2). Under the above second example access control identifier scheme (see Table 2), before executing "Task 1" 220a (in user mode or privileged mode), transaction host 102 may execute control bit management instruction 214 to (a) program the first access control identifier 112a to an open access setting for the first peripheral device 104a that allows access in both privileged mode and user mode of transaction host 102 (AC_ID value = 0), and (b) program the second access control identifier 112b to a restricted access setting for the second peripheral device 104b that allows access in privileged mode of transaction host 102 but does not allow access in user mode (AC_ID value = 1).

[0116] Figure 3 Another example electronic device 300 is shown, which uses programmable access control identifiers to control access to peripheral devices according to an example. Electronic device 300 may be generally similar to the example electronic device 100 discussed above, but includes multiple transaction hosts 102a-102n in addition to peripheral devices 104a-104n and 104ac, access controllers 106a-106n and 106ac, and an access control register 110 within peripheral device 104ac storing access control identifiers 112. Components of electronic device 100 can be communicatively connected to each other via any type or multiple types of communication links 114 (e.g., bus, wire, or other types of links).

[0117] The corresponding access controllers 106a-106n and 106ac can use the corresponding access control identifier 112 (and optional additional input data) to control access to the corresponding peripheral devices 104a-104n and 104ac, for example based on (a) the peripheral device 104a-104n that is requested to be accessed, (b) the corresponding transaction host 102a-102n (referred to herein as access requesting transaction host 102a-102n) that requests access to the peripheral device 104a-104n that is requested to be accessed, and (b) the operating mode signal 120a-120n of the access requesting transaction host 102a-102n (e.g., privileged mode or user mode).

[0118] Access control register 110 may store an AC identifier array 113, which includes a corresponding set 112 of AC identifiers for the respective transaction hosts 102a-102n, wherein the set 112 of AC identifiers for the respective transaction hosts 102a-102n includes corresponding AC identifiers 112 for the respective peripheral devices 104a-104n and (optionally) for the peripheral device 104ac. Table 3 below shows an example AC identifier array 113 for multiple transaction hosts 102a-102n and multiple peripheral devices 104a-104n and 104ac.

[0119] Table 3. Example AC identifier array 113 for example electronic device 300 includes multiple transaction hosts 102a-102n And multiple peripheral devices 104a-104n and 104ac .

[0120]

[0121] The value of AC identifier 112 in AC identifier array 113 can be used by the corresponding access controllers 106a-106n and 106ac to determine access to the corresponding peripheral devices 104a-104n and 104ac by the corresponding transaction hosts 102a-102n.

[0122] In one example, the value of AC identifier 112 in AC identifier array 113 can indicate an access-allowed state (AC_ID value = 0) or an access-blocked state (AC_ID value = 1), for example, as discussed above with respect to Table 1. In such an example, when requesting access transaction hosts 102a-102n attempt to access the requested peripheral device 104a-104n or 104ac, the access controllers 106a-106n or 106ac corresponding to the requested peripheral device 104a-104n or 104ac can (a) receive an access request including a transaction host identifier (TH_id) from requesting access transaction hosts 102a-102n, and (b) identify the requesting access transaction host 102a-102n from the AC identifier array 113 stored in access control register 110. The values ​​of 02n (based on the received TH_id) and the corresponding AC identifier 112 of the peripheral device 104a-104n or 104ac to be accessed, and (c) performing an access determination based on the identified AC identifier 112 to allow or block access to the peripheral device 104a-104n or 104ac to be accessed (i.e., allowing access if the AC_ID value = 0 and blocking access if the AC_ID value = 1), and (d) allowing or blocking access to the peripheral device 104a-104n or 104ac to be accessed based on the access determination.

[0123] In another example, the value of AC identifier 112 in AC identifier array 113 can indicate an open access state (AC_ID value = 0) or a restricted access state (AC_ID value = 1), for example, as discussed above with respect to Table 2. In such an example, when the requested access transaction hosts 102a-102n attempt to access the requested access peripheral devices 104a-104n or 104ac, the access controllers 106a-106n or 106ac corresponding to the requested access peripheral devices 104a-104n or 104ac can (a) receive an access request including TH_id from the requesting access transaction hosts 102a-102n; (b) receive a corresponding operation mode signal 120a-120n from the requesting access transaction hosts 102a-102n, which indicates the operation mode (privileged mode or user mode) of the requesting access transaction hosts 102a-102n; (c) receive a request from the access control register 1 The AC identifier array 113 in 10 identifies the value of AC identifier 112 corresponding to the requesting access transaction hosts 102a-102n (based on the received TH_id) and the requested peripheral devices 104a-104n or 104ac; (d) based on the identified AC identifier 112 value and the operating mode of the requesting access transaction hosts 102a-102n (e.g., according to the scheme discussed above with respect to Table 2) to allow or block access to the requested peripheral devices 104a-104n or 104ac; and (e) based on the access determination, allow or block access to the requested peripheral devices 104a-104n or 104ac.

[0124] As discussed above, in some examples, the corresponding access controllers 106a-106n of the example electronic device 100 may include corresponding instances of memory 107 storing lookup tables (LUTs), or alternatively may include corresponding instances of logic circuitry 108 to implement the access determination scheme defined by Table 1 or Table 2 above.

[0125] Regarding the latter Figures 4A-4D A circuit diagram is shown of example logic circuitry 108 provided in the respective access controllers 106a-106n (and optionally access controller 106ac) according to some examples.

[0126] first, Figure 4A and 4B An example electronic device is shown, comprising a transaction host 102 (e.g., Figure 1 and Figure 2 Example logic circuit 108 of example electronic device 100 shown in the figure.

[0127] Figure 4AAn example logic circuit 108a is shown according to the first example discussed above, that is, implementing the access control identifier scheme shown in Table 1 above. Logic circuit 108a includes a NOT gate (or inverter) 402, which inverts the value of the corresponding access control identifier 112 and outputs a value that defines the access determination.

[0128] Figure 4B An example logic circuit 108b is shown according to the first example discussed above, that is, implementing the access control identifier scheme shown in Table 2 above. The logic circuit 108b includes: a NOT gate (or inverter) 402, which inverts the value of the corresponding access control identifier 112; and an OR gate 404, which processes the value output by the NOT gate 402 and the operation mode signal 120, and outputs a value that defines the access determination.

[0129] Next, Figure 4C and 4D An example electronic device is shown that includes multiple transaction hosts 102 (e.g., Figure 3 Example logic circuit 108 of example electronic device 300 shown in the figure.

[0130] Figure 4C Example logic circuit 108c is shown according to the first example discussed above, that is, implementing the access control identifier scheme shown in Table 1 above with multiple transaction hosts 102. Logic circuit 108c includes a multiplexer (MUX) 406 that receives (a) the value of AC identifier 112 for the corresponding transaction host 102 and (b) an access request identifier (TH_id) of the corresponding transaction host 102 that requests access to the corresponding peripheral device 104, and selects the value of the corresponding AC identifier 112 associated with the corresponding transaction host 102 according to the access request identifier (TH_id). The selected AC_ID value is forwarded to a NOT gate (or inverter) 402, which inverts the AC_ID value and outputs a value that determines the access.

[0131] In other examples, the meaning of the example AC_ID values ​​stated in Tables 1, 2, and / or 3 may be reversed; for example, AC_ID = 0 indicates access prevention or restriction settings, and AC_ID = 1 indicates access allow or open access settings. In these examples, the NOT gate (inverter) 402 can be... Figures 4A-4D The logic circuits 108a-108d shown are omitted.

[0132] Figure 4DExample logic circuit 108d is shown according to the first example discussed above, that is, implementing the access control identifier scheme shown in Table 2 above. Logic circuit 108d includes a multiplexer (MUX) 406 that receives (a) the value of AC identifier 112 for the corresponding transaction host 102 and (b) an access request identifier (TH_id) of the corresponding transaction host 102 that requests access to the corresponding peripheral device 104, and selects the value of the corresponding AC identifier 112 associated with the corresponding transaction host 102 in response to the access request identifier (TH_id), the selected AC_ID value being forwarded to a NOT gate 402 that inverts the AC_ID value. Logic circuit 108d further includes an OR gate 404 that processes the value output by the NOT gate 402 and the operation mode signal 120 of the corresponding transaction host 102, and outputs a value that defines the access determination.

[0133] Figure 5 This is a flowchart of an example method 500 for controlling access to peripheral devices in an electronic device including a transaction host, a first peripheral device, a second peripheral device, and an access control register. In some examples, the electronic device may be the example electronic device 100 or electronic device 300 discussed above. At 502, a first access control identifier for the first peripheral device and a second access control identifier for the second peripheral device are stored in the access control register. For example, the first and second access control identifiers may be programmed by the transaction host before performing a corresponding task (e.g., a device-driven task), for example, based on the transaction host's operating mode and / or based on the corresponding peripheral device (e.g., the first peripheral device, the second peripheral device, or another peripheral device) to be accessed for performing the corresponding task.

[0134] At point 504, during the execution of the corresponding task, the first access controller associated with the first peripheral device receives a request from the transaction host for access to the first peripheral device. For example, the transaction host may execute a device driver task corresponding to the first peripheral device. In some examples, the access request from the transaction host may optionally include an operating mode signal indicating the transaction host's privileged mode or user mode.

[0135] At 506, the first access controller accesses a first access control identifier for the first peripheral device from the access control register. At 508, the first access controller performs an access determination to alternately allow or block access to the first peripheral device by the transaction host, based at least on the accessed first access control identifier for the first peripheral device, for example, using a corresponding LUT stored in memory or using corresponding logic circuitry, such as... Figures 4A-4DAs shown in any of the above. For example, the first access controller can perform access determination according to the access control identifier scheme described above with respect to Table 1. In some examples, the first access controller can also use an optionally received operating mode signal (see above at 504) as another input for access determination. For example, the first access controller can perform access determination according to the access control identifier scheme described above with respect to Table 2, based on the first access control identifier and the operating mode indicated by the optional operating mode signal.

[0136] At point 510, the first access controller allows or blocks access to the first peripheral device based on this access determination. For example, to block access to the first peripheral device, the first access controller may force the "chip select" signal (also known as the "peripheral device select" signal) associated with the requested transaction from a value of 1 (indicating that the first peripheral device is directed / selected) to a value of 0 (indicating that the first peripheral device is not directed / selected), causing the first peripheral device to ignore the transaction. Alternatively, to allow access to the first peripheral device, the first access controller may keep the chip select signal value unchanged (value = 1), causing the first peripheral device to process the transaction, or force the chip select signal associated with the requested transaction from a value of 0 to a value of 1. (In an alternative example, other chip select signal values ​​may be defined to indicate whether a corresponding peripheral device is directed / selected. For example, the system may define a chip select signal value of 0 to indicate that the peripheral device is directed / selected, and a chip select signal value of 1 to indicate that the peripheral device is not directed / selected.)

[0137] Figure 6 This is a flowchart of an example method 600 for controlling access to peripheral devices in an electronic device, which includes a transaction host, multiple peripheral devices, and an access control register storing corresponding access control identifiers (AC identifiers) for the multiple peripheral devices. In some examples, the electronic device may be the example electronic device 100 or electronic device 300 discussed above, and method 600 may correspond to the access control identifier scheme discussed above with respect to Table 1.

[0138] At 602, the transaction master programs the AC identifiers for multiple peripheral devices, for example, based on the transaction master's scheduled operations. In this example, for privileged mode operation, the transaction master sets the AC identifier for the corresponding peripheral device to an access-allowed setting (AC_ID value = 0), which allows access to the corresponding peripheral device by the transaction master. In some examples, the transaction master can execute access control identifier management instructions provided in the manager firmware to access and program the AC identifiers. In some examples, when setting the AC identifier for privileged mode operation, the transaction master can ignore the bitmask because all peripheral devices are accessible during privileged mode operation.

[0139] At 604, the transaction host operates in privileged mode, for example, by executing relevant manager code (e.g., manager firmware). At 606, when the transaction host operates in privileged mode, the corresponding access controller for the corresponding peripheral device among multiple peripheral devices, based on the access permission setting (AC_ID value = 0) for the corresponding AC identifier of the corresponding peripheral device, uses, for example, the corresponding LUT stored in memory or the corresponding logic circuit (e.g., such as...). Figure 4A (Single transaction host scenario) or Figure 4C (As shown in the case of multiple transaction hosts) to allow access to the corresponding peripheral devices.

[0140] At 608, when the transaction host operates in privileged mode (where the AC identifier is programmed to 0), the manager firmware executed by the transaction host identifies the corresponding task associated with the selected peripheral device ("peripheral device N") to be executed in user mode. At 610, before executing the corresponding task associated with peripheral device N, the transaction host accesses the corresponding bitmask associated with the corresponding task, which indicates the access settings for multiple peripheral devices (including peripheral device N) for executing the corresponding task, and programs the AC identifiers for the multiple peripheral devices based on the corresponding bitmask. In this example, the transaction host (a) programs the AC identifier for peripheral device N to an access-allowed setting (AC_ID value = 0), which allows access to peripheral device N during user-mode execution of the corresponding task, and (b) programs the AC identifiers for the other peripheral devices among the multiple peripheral devices to an access-blocking setting (AC_ID value = 1), which blocks access to each corresponding peripheral device during user-mode execution of the corresponding task.

[0141] At 612, the transaction host transitions from privileged mode to user mode and executes the corresponding task associated with peripheral device N. At 614, in order to execute the corresponding task associated with peripheral device N, the access controller corresponding to peripheral device N, based on the access permission setting (AC_ID value = 0) of the AC identifier for peripheral device N (e.g., programmed based on the corresponding bitmask associated with the corresponding task), for example, uses the corresponding LUT stored in memory or uses the corresponding logic circuitry (e.g., ...). Figure 4A (Single transaction host scenario) or Figure 4C (As shown in the multiple transaction master scenario) to allow access to peripheral device N (e.g., access to registers in peripheral device N). If a transaction master attempts to access any of the other peripheral devices, the access controller corresponding to the respective other peripheral device is configured based on the access blocking setting (AC_ID value = 1) of the corresponding AC identifier for the other peripheral device, for example, using the corresponding LUT or logic circuit (e.g., as shown in the multiple transaction master scenario). Figure 4A or Figure 4C(As shown in the image) to prevent access to other peripheral devices.

[0142] At 616, the transaction host completes the corresponding task associated with peripheral device N. At 618, the transaction host can identify the next transaction host activity for execution in user mode. For example, as indicated at 620, if the manager firmware executed by the transaction host identifies the next peripheral device-related task (associated with the same peripheral device or another peripheral device) to be executed in user mode, the method can return to 610, where the transaction host accordingly programs the AC identifier for executing the next task (e.g., based on the corresponding bitmask associated with the next task). As another example, as indicated at 622, if the manager firmware executed by the transaction host identifies a manager or privileged operation to be performed, then the method can return to 602, where the transaction host (optionally) programs the AC identifier for multiple peripheral devices to an access permission setting (AC_ID value = 0) (e.g., ignoring the corresponding bitmask) to allow the transaction host to access the corresponding peripheral device during a manager or privileged operation, as discussed above. In some examples or situations, the AC identifier programmed for manager or privileged operations may be redundant (because the transaction host running the manager code has access to all registers), and therefore the AC identifier programming at 602 may be omitted or optional.

[0143] Figure 7 This is a flowchart of an example method 700 for controlling access to peripheral devices in an electronic device, which includes a transaction host, multiple peripheral devices, and an access control register storing corresponding access control identifiers (AC identifiers) for the multiple peripheral devices. In some examples, the electronic device may be the example electronic device 100 or the example electronic device 300 discussed above, and method 700 may correspond to the access control identifier scheme discussed above with respect to Table 2.

[0144] At 702, the transaction host programs AC identifiers for multiple peripheral devices, for example, based on the transaction host's scheduled operations. In this example, for privileged mode operations, the transaction host sets the AC identifier for the corresponding peripheral device to an access restriction setting (AC_ID value = 1). In some examples, the transaction host can execute access control identifier management instructions provided in the manager firmware to access and program AC identifiers.

[0145] At 704, the transaction host operates in privileged mode, for example, by executing the relevant manager firmware. At 706, when the transaction host operates in privileged mode (where the AC identifier is programmed to 1), the corresponding access controller corresponding to the corresponding peripheral device among multiple peripheral devices allows access to the corresponding peripheral device, for example, using the corresponding LUT stored in memory or using the corresponding logic circuitry, such as... Figure 4B (Single transaction host scenario) or Figure 4D As shown in the (multiple transaction master scenario), each request from a transaction master to access a corresponding peripheral device may include an operation mode signal indicating the privileged mode of the transaction master (e.g., operation mode signal value = 1 according to the control bit scheme shown in Table 2). For a corresponding request from a transaction master to access a corresponding peripheral device, the corresponding access controller corresponding to the corresponding peripheral device may determine whether to allow or block access to the corresponding peripheral device based on (a) the corresponding AC identifier for the corresponding peripheral device and (optionally in the multiple transaction master scenario) the corresponding transaction master, and (b) the operation mode signal indicating the privileged mode (e.g., operation mode signal value = 1), according to the control bit scheme shown in Table 2 above. More specifically, the corresponding access controller allows access to the corresponding peripheral device based on the privileged mode of the corresponding transaction master (e.g., operation mode signal value = 1).

[0146] At 708, when the transaction host operates in privileged mode, the manager firmware executed by the transaction host identifies the corresponding task to be executed in user mode associated with the selected peripheral device (“Peripheral Device N”). At 710, before executing the corresponding task associated with peripheral device N in user mode, the transaction host accesses the corresponding bitmask associated with the corresponding task, which indicates the access settings for multiple peripheral devices (including peripheral device N) for executing the corresponding task, and programs the AC identifiers for the multiple peripheral devices based on the corresponding bitmask. In this example, according to the control bit scheme shown in Table 2 above, the transaction host (a) programs the AC identifier for peripheral device N to an open allowed setting (AC_ID value = 0), and (b) programs the AC identifiers for the other peripheral devices among the multiple peripheral devices associated with the transaction host to a restricted access setting (AC_ID value = 1).

[0147] At 712, the transaction master transitions from privileged mode to user mode and executes the corresponding task related to peripheral device N. At 714, in order to execute the corresponding task related to peripheral device N, for example, the corresponding LUT stored in memory or the corresponding logic circuit (e.g., ...) is used. Figure 4B (Single transaction host scenario) or Figure 4D (As shown in the case of multiple transaction hosts) to allow access to peripheral device N (e.g., access to registers in peripheral device N). If a transaction host attempts to access any of the other peripheral devices, then according to Table 2, for example using... Figure 4B or Figure 4DThe corresponding LUT or logic circuit shown prevents access to other peripheral devices based on (a) restricted access settings (AC_ID value = 1) and (b) the transaction master's user mode (operation mode signal value = 0).

[0148] At 716, the transaction host completes the corresponding task related to peripheral device N in user mode. At 718, the transaction host can identify the next transaction host activity to be executed. For example, as indicated at 720, if the manager firmware executed by the transaction host identifies the next peripheral device-related task to be executed in user mode (related to the same peripheral device or another peripheral device), the method can return to 710, where the transaction host accordingly programs the AC identifier for executing the next task (e.g., based on the corresponding bitmask associated with the next task). As another example, as indicated at 722, if the manager firmware executed by the transaction host identifies a manager or privileged operation to be executed in privileged mode, then the method can return to 702, where the transaction host programs the AC identifier for multiple peripheral devices to a restricted access setting (AC_ID value = 0), as discussed above.

[0149] Figure 8 This is a flowchart of an example method 800 for controlling access to peripheral devices in an electronic device, including a transaction host, a first peripheral device, a second peripheral device, and an access control register storing the corresponding access control identifiers (AC identifiers). In some examples, the electronic device may be the example electronic device 100 or electronic device 300 discussed above, and method 800 may correspond to the access control identifier scheme discussed above with respect to, for example, any of Tables 1, 2, or 3 described above.

[0150] At 802, a first access control identifier for the first peripheral device and a second access control identifier for the second peripheral device are stored in the access control register. The transaction master can dynamically program the first and second access control identifiers over time to perform different types of operations, such as privileged mode operations and user mode operations, including operations related to the first and second peripheral devices. In some examples, the transaction master can execute access control identifier management instructions provided in the supervisory firmware to dynamically program the first and second access control identifiers before performing the corresponding task (e.g., a device driver task).

[0151] For example, at 804, for privileged mode operation, the transaction host sets a first access control identifier and a second access control identifier to allow access to the first peripheral device and the second peripheral device, respectively. In some examples or situations, the AC identifier programmed for privileged mode operation may be redundant (because the transaction host running the manager code can access all registers), and therefore the AC identifier programming at 804 may be omitted or optional. In some examples, the transaction host sets the first access identifier and the second access control identifier according to the access bit scheme discussed above with respect to any of Tables 1, 2, or 3 above. At 806, the transaction host performs privileged mode operation at the first moment, therefore at 806, the operation mode signal indicates privileged mode.

[0152] At 808, for a user-mode operation (user-mode task) associated with the first peripheral device, the transaction host accesses the corresponding bitmask associated with the user-mode task, which indicates access settings for at least the first and second peripheral devices, and programs the AC identifiers for at least the first and second peripheral devices based on the corresponding bitmask. In this example, the transaction host (a) sets a first access control identifier that allows the transaction host to access the first peripheral device in user mode and (b) sets a second access control identifier that prevents the transaction host from accessing the second peripheral device in user mode. In some examples, the transaction host sets the first access identifier and the second access control identifier according to the access bit scheme discussed above with respect to any of Tables 1, 2, or 3 above. At 810, the transaction host executes the user-mode task associated with the first peripheral device at a second time, therefore at 810, the operation mode signal indicates user mode.

[0153] The transaction host can continue to dynamically program the first access control identifier and the second access control identifier over time in this manner to perform different types of operations, such as privileged mode operations and user mode operations, including operations related to the first peripheral device and the second peripheral device.

[0154] Figure 9This is a flowchart of an example method 900 for controlling access to peripheral devices using task-related bitmasks in an electronic device including a transaction host, a first peripheral device, a second peripheral device, and an access control register, the access control register including a first access control identifier for the first peripheral device and a second access control identifier for the second peripheral device. At 902, computer-readable code is stored including a first task associated with the first peripheral device and a first bit mask corresponding to the first task, wherein the first bit mask indicates corresponding access settings for the first and second peripheral devices for executing the first task. At 904, the transaction host executes access control identifier management instructions before executing the first task to program the first and second access control identifiers in the access control register based on (a) the first bit mask corresponding to the first task and (b) the transaction host's operating mode in some embodiments. At 906, after updating the first and second access control identifiers in the access control register, the transaction host executes the first task associated with the first peripheral device. At 908, during the execution of the first task, the first access controller associated with the first peripheral device controls access to the first peripheral device based at least on a first access control identifier programmed with a first bit mask in the access control register. At 910, also during the execution of the first task, the second access controller associated with the second peripheral device controls access to the second peripheral device based at least on a second access control identifier programmed with a first bit mask in the access control register.

Claims

1. An electronic device, comprising: First peripheral equipment; Second peripheral equipment; Non-transitory memory, the non-transitory memory being used to store: Manager firmware, the manager firmware including access control identifier management instructions; Computer-readable code, the computer-readable code including a first task associated with the first peripheral device and a second task associated with the second peripheral device; The first bit mask corresponding to the first task indicates the corresponding access settings for the first peripheral device and the second peripheral device for performing the first task; A second bitmask corresponding to the second task, the second bitmask indicating the corresponding access settings for the first peripheral device and the second peripheral device for performing the second task; An access control register, the access control register including a first access control identifier for the first peripheral device and a second access control identifier for the second peripheral device; Transaction host, the transaction host is used for: The access control identifier management instructions in the manager firmware are executed to program the first access control identifier and the second access control identifier in the access control register based on the first bit mask corresponding to the first task and the second bit mask corresponding to the second task. as well as After programming the first access control identifier and the second access control identifier in the access control register based on the first bitmask and the second bitmask, a first task related to the first peripheral device and a second task related to the second peripheral device are executed. A first access controller controls access to the first peripheral device based at least on a first access control identifier programmed based on the first bitmask in the access control register. and The second access controller controls access to the second peripheral device based at least on a second access control identifier programmed based on the first bitmask in the access control register.

2. The electronic device according to claim 1, wherein, The electronic device is a system-on-a-chip (SoC) device.

3. The electronic device according to any one of claims 1 to 2, wherein, The transaction host includes a processor or a direct memory access (DMA) engine.

4. The electronic device according to claim 1, wherein, The first bitmask and the second bitmask are stored in a bitmask data structure in the non-transitory memory.

5. The electronic device according to claim 1, wherein: The first bitmask includes one or more first bitmask bits indicating access settings for the first peripheral device for performing the first task and one or more second bitmask bits indicating access settings for the second peripheral device for performing the first task; and The first access control identifier includes one or more first access control bits, and the second access control identifier includes one or more second access control bits.

6. The electronic device according to claim 1, wherein, The non-transitory memory includes: The non-privileged portion stores computer-readable code including the first task and the second task; and The privileged portion stores manager firmware including the access control identifier management instructions and the first bitmask corresponding to the first task.

7. The electronic device according to claim 1, wherein, The first access controller is used for: Receive an access request from the transaction host for accessing the first peripheral device in order to perform the first task; Access determination to the first peripheral device is performed at least based on a first access control identifier, which is programmed based on a first bit mask corresponding to the first task; as well as Based on the access determination, the transaction host may be allowed or blocked from accessing the first peripheral device.

8. The electronic device according to claim 7, wherein, The first access controller performs access determination for the first peripheral device based at least on (a) a first access control identifier programmed by the transaction host based on the first bitmask corresponding to the first task and (b) an operating mode signal indicating the privileged mode or user mode of the transaction host.

9. The electronic device according to claim 1, wherein, The first bitmask corresponding to the first task indicates (a) that the first task is granted a peripheral device access license to the first peripheral device and (b) that the first task is not granted a peripheral device access license to the second peripheral device.

10. The electronic device according to claim 9, wherein: The access control identifier management instructions are used to program the first access control identifier and the second access control identifier in the access control register based on the first bitmask before the execution of the first task, including (a) updating the first access control identifier to an access allow value that allows access to the first peripheral device during the execution of the first task, and (b) updating the second access control identifier to an access block value that prevents access to the second peripheral device during the execution of the first task. The first access controller, based on the access permission value of the first access control identifier, allows access to the first peripheral device during the execution of the first task; and The second access controller blocks access to the second peripheral device during the execution of the first task based on the access blocking value of the second access control identifier.

11. The electronic device according to claim 1, wherein: The transaction host selectively operates in privileged mode and user mode; The first bitmask corresponding to the first task indicates (a) that the first task is granted a peripheral device access license to the first peripheral device and (b) that the first task is not granted a peripheral device access license to the second peripheral device; and The access control identifier management instructions are used to program the first access control identifier and the second access control identifier in the access control register based on the first bitmask before the execution of the first task, including (a) updating the first access control identifier to an open access setting for the first peripheral device, the open access setting allowing access to the first peripheral device in both privileged mode and user mode of the transaction host. (b) updating the second access control identifier to a restricted access value for the second peripheral device, the restricted access value allowing access to the second peripheral device in the privileged mode of the transaction host but not in the user mode of the transaction host.

12. The electronic device according to claim 1, wherein, The access control register is located in a third peripheral device.

13. A method for controlling access to a peripheral device, the method comprising: In an electronic device including a transaction host, a first peripheral device, a second peripheral device, and an access control register, the access control register includes a first access control identifier for the first peripheral device and a second access control identifier for the second peripheral device, stores (a) computer-readable code including a first task associated with the first peripheral device and a second task associated with the second peripheral device, (b) a first bit mask corresponding to the first task, the first bit mask indicating corresponding access settings for the first peripheral device and the second peripheral device for performing the first task, and (c) a second bit mask corresponding to the second task, the second bit mask indicating corresponding access settings for the first peripheral device and the second peripheral device for performing the second task; Before executing the first task, the transaction host executes an access control identifier management instruction to program the first access control identifier and the second access control identifier in the access control register based on the first bit mask corresponding to the first task. After programming the first access control identifier and the second access control identifier in the access control register based on the first bitmask, the transaction host executes a first task related to the first peripheral device; During the execution of the first task: A first access controller associated with the first peripheral device controls access to the first peripheral device based at least on the first access control identifier programmed with the first bitmask in the access control register; and The second access controller associated with the second peripheral device controls access to the second peripheral device based at least on the second access control identifier programmed based on the first bitmask in the access control register; Before executing the second task, the transaction host executes the access control identifier management instruction to program the first access control identifier and the second access control identifier in the access control register based on the second bitmask corresponding to the second task. After programming the first access control identifier and the second access control identifier in the access control register based on the second bitmask, the transaction host executes a second task related to the second peripheral device; During the execution of the second task: A first access controller associated with the first peripheral device controls access to the first peripheral device based at least on the first access control identifier programmed with the second bitmask in the access control register; and The second access controller associated with the second peripheral device controls access to the second peripheral device based at least on the second access control identifier programmed based on the second bitmask in the access control register.

14. The method according to claim 13, wherein, The first access controller controls access to the first peripheral device based at least on the first access control identifier programmed based on the first bitmask, including: The first access controller receives an access request from the transaction host for the first peripheral device to perform the first task; The first access controller performs access determination for the first peripheral device based at least on the first access control identifier programmed based on the first bitmask; and The first access controller allows or blocks the transaction host from accessing the first peripheral device based on the access determination.

15. The method of claim 14, wherein the method comprises the first access controller performing access determination for the first peripheral device based at least on (a) a first access control identifier programmed based on the first bitmask and (b) an operating mode signal indicating the privileged mode or user mode of the transaction host.

16. The method according to any one of claims 13 to 15, wherein: The first bitmask corresponding to the first task indicates (a) that the first task is granted a peripheral device access license to the first peripheral device and (b) that the first task is not granted a peripheral device access license to the second peripheral device; Executing the access control identifier management instructions to program the first access control identifier and the second access control identifier in the access control register based on the first bitmask corresponding to the first task includes (a) updating the first access control identifier to an access permission value that allows access to the first peripheral device during the execution of the first task, and (b) updating the second access control identifier to an access blocking value that blocks access to the second peripheral device during the execution of the first task; and During the execution of the first task: A first access controller associated with the first peripheral device allows access to the first peripheral device based on the access permission value of the first access control identifier; and The second access controller associated with the second peripheral device blocks access to the second peripheral device based on the access block value of the second access control identifier.

17. The method according to any one of claims 13, wherein: The transaction host selectively operates in privileged mode and user mode; The first bitmask corresponding to the first task indicates (a) that the first task is granted a peripheral device access license to the first peripheral device and (b) that the first task is not granted a peripheral device access license to the second peripheral device; Executing the access control identifier management instructions to program the first access control identifier and the second access control identifier in the access control register based on the first bit mask corresponding to the first task includes: (a) updating the first access control identifier to an open access value for the first peripheral device, the open access value allowing access to the first peripheral device in both privileged mode and user mode of the transaction host; and (b) updating the second access control identifier to a restricted access value for the second peripheral device, the restricted access value allowing access to the second peripheral device in privileged mode of the transaction host but not in user mode; and During the execution of the first task: The first access controller associated with the first peripheral device, based on the open access value of the first access control identifier, allows access to the first peripheral device in both privileged mode and user mode of the transaction host; and The second access controller associated with the second peripheral device prevents access to the second peripheral device in the privileged mode of the transaction host, but does not prevent access to the second peripheral device in the user mode of the transaction host, based on the restricted access value of the second access control identifier.

Images