CN117716367A

CN117716367A - Peripheral access control using bitmasks indicating access settings for peripheral devices

Info

Publication number: CN117716367A
Application number: CN202380013015.9A
Authority: CN
Inventors: R·库马; S·纳卡; J·维塔马尼卡姆
Original assignee: Microchip Technology Inc
Current assignee: Microchip Technology Inc
Priority date: 2022-01-06
Filing date: 2023-01-04
Publication date: 2024-03-15

Abstract

The 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 an access control identifier management instruction, a first task associated with 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 and a second access control identifier for the second peripheral. The transaction host executes the access control identifier management instructions to program the first access control identifier and the second access control identifier based on the first bitmask and then execute the first task. The first access controller and the second access controller control access to the first peripheral and the second peripheral based on respective first access control identifiers and second access control identifiers programmed based on the first bitmask, respectively.

Description

Peripheral access control using bitmasks indicating access settings for peripheral devices

Related patent application

This patent application claims priority from IN provisional patent application 202211000733 filed on 1/6/2022, the entire contents of which are hereby incorporated by reference for all purposes.

Technical Field

The present disclosure relates to electronic devices including peripherals, and more particularly to peripheral access control using a bitmask indicating access settings for the peripheral.

Background

A system-on-chip (also known as a system-on-chip or SoC) is an Integrated Circuit (IC) that integrates an electronic system or computer system on a single chip. Socs typically include 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) and analog input and 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. The SoC may be designed for various functions such as signal processing, wireless communication, or artificial intelligence.

In some socs, firmware running on the processor fully accesses all peripherals on the SoC, regardless of the current operating mode (e.g., privileged mode or user mode) of the processor. This may lead to failure or other undesirable consequences. For example, a faulty or malicious firmware device driver corresponding to one peripheral device may erroneously (or maliciously) access and destroy another peripheral device, e.g., by changing registers provided in the other peripheral device.

There is a need for improved, low cost access control to peripheral devices provided in a SoC or other electronic device, for example, to protect the peripheral devices from malfunction or malicious firmware.

Disclosure of Invention

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

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

In some applications, the access control identifier and access controller may eliminate the need for complex software, allowing for smaller or cheaper processors in, for example, a SoC.

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

In some examples, the transaction host includes a processor or a Direct Memory Access (DMA) engine.

In some examples, the transaction host includes a bridge that receives a request to access the first peripheral device from an external host separate from the electronic device.

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.

In some examples, the electronic device includes firmware executable by the transaction host to program at least one of the first access control identifier and the second access control identifier based on an operating mode of the transaction host.

In some examples, the electronic device includes firmware executable by the transaction host to dynamically program at least one of a first access control identifier for the first peripheral device and a second access control identifier for the second peripheral device between (a) an access permission setting that permits access by the transaction host to the respective peripheral device and (b) an access prevention setting that prevents access by the transaction host to the respective peripheral device.

In some examples, the electronic device includes firmware executable by the transactional host to program the first access control identifier and the second access control identifier, including (a) programming both the first access control identifier and the second access control identifier to access permission settings that allow access by the transactional host to both the first peripheral and the second peripheral for privileged mode operation of the transactional host; and (b) for a first user mode operation of the transaction host, performing an operation associated with the first peripheral device to program the first access control identifier to an access permission setting that permits access to the first peripheral device, and to program the second access control identifier to an access prevention setting that prevents access to the second peripheral device; (c) For a second user mode operation of the transaction host, performing an operation associated with the second peripheral to program the first access control identifier to an access blocking setting that blocks access to the first peripheral and to program the second access control identifier to an access permission setting that permits access to the second peripheral.

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

In some examples, the first access control identifier for the first peripheral and the second access control identifier for the second peripheral respectively indicate (a) restricted access settings that allow access to the respective peripheral only in a privileged mode of the transactional host, or (b) open access settings that allow access to the respective peripheral in both the privileged mode of the transactional host and a user mode of the transactional host.

In some examples, the electronic device includes firmware executable by the transaction host to program at least one of the first access control identifier and the second access control identifier between the restricted access setting and the open access setting.

In some examples, (a) if a first access control identifier for a first peripheral indicates an open access setting and an operating mode signal indicates a privileged mode of a transactional host, then the access controller determines that access to the first peripheral is allowed; (b) If the first access control identifier for the first peripheral indicates an open access setting and the operating mode signal indicates a user mode of the transaction host, the access controller determines that access to the first peripheral is allowed; (c) If the first access control identifier for the first peripheral indicates a restricted access setting and the operating mode signal indicates a privileged mode of the transaction host, the access controller determines that access to the first peripheral is allowed; and (d) if the first access control identifier for the first peripheral indicates a restricted access setting and the operation mode signal indicates a user mode of the transaction host, the access controller determining to block access to the first peripheral.

In some examples, the transaction host may be selectively operable in a privileged mode and a 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.

In some examples, the electronic device includes firmware running on the transaction host, and wherein allowing or preventing access to the first peripheral device includes allowing or preventing access to the first peripheral device by the firmware running on the transaction host.

In some examples, the access control register is provided in a designated peripheral of the plurality of peripherals.

In some examples, the electronic device includes an additional transaction host, wherein the first access control identifier and the second access control identifier are associated with the transaction host, wherein the access control register stores a third access control identifier for the first peripheral device and associated with the additional transaction host, and a fourth access control identifier for the second peripheral device and associated with the additional transaction host. The access controller receiving an additional access request for access to the first peripheral by the additional transaction host; performing an additional access determination to the first peripheral device based on (a) an access request identifier identifying the additional transaction host and (b) a third access control identifier; based on the additional access determination, access to the first peripheral device by the additional transaction host is allowed or blocked.

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

In another aspect, a method is provided, comprising: in an electronic device comprising a transaction host, a first peripheral and a second peripheral, and an access control register, storing in the access control register (a) a first access control identifier for the first peripheral and (b) a second access control identifier for the second peripheral. A first access controller associated with a first peripheral receives a request by a transaction host to access the first peripheral. The first access controller performs an access determination that allows or prevents access to the first peripheral based at least on the first access control identifier for the first peripheral, and allows or prevents access to the first peripheral based on the access determination.

In some examples, the method includes executing, by the transaction host, firmware to program at least one of the first access control identifier and the second access control identifier based on an operating mode of the transaction host.

In some examples, the method includes executing, by the transaction host, firmware to dynamically program at least one of a first access control identifier for the first peripheral device and a second access control identifier for the second peripheral device between (a) an access permission setting that permits access by the transaction host to the respective peripheral device and (b) an access prevention setting that prevents access by the transaction host to the respective peripheral device.

In some examples, the method includes: executing firmware by the transaction host to program the first access control identifier and the 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 permission settings that respectively permit access by the transaction host to 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 permission setting, and setting the second access control identifier to an access prevention setting that prevents access to the second peripheral device; (c) For a second user mode operation of the transactional host for performing operations related to the second peripheral, the first access control identifier is set to a block access setting and the second access control identifier is set to an access permission setting.

In some examples, the method includes performing, by the first access controller, an access determination that allows or prevents access to the first peripheral based at least on (a) a first access control identifier for the first peripheral and (b) an operation mode signal indicating a privileged mode of the transactional host or a user mode of the transactional host.

In some examples, the first access control identifier for the first peripheral and the second access control identifier for the second peripheral indicate (a) restricted access settings that prevent access to the respective peripheral in a user mode of the transactional host, or (b) open access settings that allow access to the respective peripheral in both a privileged mode of the transactional host and a user mode of the transactional host, respectively.

In some examples, the method includes executing, by the transaction host, firmware to dynamically program at least one of the first access control identifier and the second access control identifier between the restricted access setting and the open access setting.

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

In some examples, the method includes allowing programming of the first access control identifier in a privileged mode of the transactional host and preventing programming of the first access control identifier in a user mode of the transactional host.

In another aspect, a method is provided, comprising: in an electronic device comprising a transaction host, a first peripheral and a second peripheral, and an access control register, a first access control identifier for the first peripheral and a second access control identifier for the second peripheral are stored in the access control register. 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, and the transaction host performs privileged mode operations 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 a user mode operation associated with the first peripheral device at a second time.

In some examples, the transaction host sets (a) a first access control identifier that prevents the transaction host from accessing the first peripheral device and (b) a second access control identifier that allows the transaction host to access the second peripheral device, and performs a user mode operation associated with the second peripheral device at a third time.

Another aspect provides an electronic device including a first peripheral, a second peripheral, 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 comprising access control identifier management instructions, (b) computer readable code comprising a first task associated with the first peripheral device, and (c) a first bitmask corresponding to the first task, the first bitmask indicating respective access settings for the first peripheral device and the second peripheral device for executing the first task. The access control register includes a first access control identifier for the first peripheral and a second access control identifier for the second peripheral. The transaction host executes the access control identifier management instructions in the manager firmware to program the first access control identifier and the second access control identifier in the access control register based on a first bitmask corresponding to the first task, and after programming the first access control identifier and the second access control identifier in the access control register based on the first bitmask, to perform the first task related to the first peripheral. The first access controller controls access to the first peripheral 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 based at least on a second access control identifier programmed based on the first bitmask in the access control register.

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

In some examples, the first bitmask and the second bitmask are stored in a bitmask data structure in non-transitory memory.

In some examples, the first bitmask includes one or more first bitmask bits indicating access settings for performing the first task for the first peripheral device and one or more second bitmask bits indicating access settings for performing the first task for the second peripheral device, 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.

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

In some examples, the non-transitory memory includes a non-privileged portion storing computer readable code including a first task and a second task, and a privileged portion storing manager firmware including access control identifier management instructions and a first bitmask corresponding to the first task.

In some examples, the access controller receives an access request from a transaction host for executing a first task for accessing a first peripheral device; performing an access determination to the first peripheral based at least on a first access control identifier, the first access control identifier programmed based on a first bitmask corresponding to the first task; and based on the access determination, allowing or preventing access by the transaction host to the first peripheral.

In some examples, the first access controller performs the access determination for the first peripheral based at least on (a) a first access control identifier programmed by the transaction host based on a first bitmask corresponding to the first task and (b) an operation mode signal indicating a privilege mode of the transaction host or a user mode of the transaction host.

In some examples, the first bitmask corresponding to the first task indicates (a) that the first task is assigned a peripheral access permission to the first peripheral and (b) that the first task is not assigned a peripheral access permission to the second peripheral.

In some examples, the first bitmask corresponding to the first task indicates (a) that the first task is assigned a peripheral access permission to the first peripheral and (b) that the first task is not assigned a peripheral access permission to the second peripheral. The access control identifier management instruction programs the first access control identifier and the second access control identifier in the access control register based on the first bitmask prior to executing the first task, including (a) programming the first access control identifier to an access permission value that allows access to the first peripheral during execution of the first task, and (b) programming the second access control identifier to an access prevention value that prevents access to the second peripheral during execution of the first task. The first access controller allows access to the first peripheral during execution of the first task based on the access permission value of the first access control identifier, and the second access controller blocks access to the second peripheral during execution of the first task based on the access blocking value of the second access control identifier.

In some examples, the transaction host selectively operates in a privileged mode and a user mode; and a first bitmask corresponding to the first task indicates (a) that the first task is assigned a peripheral access permission to the first peripheral and (b) that the first task is not assigned a peripheral access permission to the second peripheral. The access control identifier management instructions program the first access control identifier and the second access control identifier in the access control register based on the first bitmask prior to executing the first task, including (a) programming the first access control identifier to an open access setting for the first peripheral that allows access to the first peripheral in both a privileged mode and a user mode of the transactional host; and (b) programming the second access control identifier to a restricted access value for the second peripheral that allows access to the second peripheral in a privileged mode of the transaction host but does not allow access to the second peripheral in a user mode.

In some examples, the access control register is provided in the third peripheral.

Another aspect provides a method. The method comprises the following steps: in an electronic device comprising a transaction host, a first peripheral, a second peripheral, and an access control register (comprising a first access control identifier for the first peripheral and a second access control identifier for the second peripheral), storing (a) computer readable code comprising a first task associated with the first peripheral, and (b) a first bitmask corresponding to the first task, the first bitmask indicating respective access settings for the first peripheral and the second peripheral for performing the first task. The transaction host executes an access control identifier management instruction prior to executing the first task to program a first access control identifier and a second access control identifier in an access control register based on a first bitmask 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 performs a first task associated with the first peripheral. During execution of the first task: a first access controller associated with the first peripheral controls access to the first peripheral based at least on a first access control identifier in the access control register programmed based on the first bitmask, and a second access controller associated with the second peripheral controls access to the second peripheral based at least on a second access control identifier in the access control register programmed based on the first bitmask.

In some examples, the method includes: storing computer readable code comprising a second task associated with a second peripheral device; and storing a second bitmask corresponding to the second task, the second bitmask indicating respective access settings for the first peripheral and the second peripheral for performing the second task. The transaction host executes an access control identifier management instruction prior to executing the second task to program the first access control identifier and the second access control identifier in the access control register based on a 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 performs a second task related to the second peripheral. During execution of the second task: a first access controller associated with the first peripheral controls access to the first peripheral based at least on a first access control identifier in an access control register programmed based on the second bitmask, and a second access controller associated with the second peripheral controls access to the second peripheral based at least on a second access control identifier in the access control register programmed based on the second bitmask.

In some examples, the first access controller controlling access to the first peripheral based at least on the first access control identifier programmed based on the first bitmask includes the first access controller: receiving an access request from a transaction host for executing a first task for accessing a first peripheral device; performing an access determination to the first peripheral based at least on a first access control identifier, the first access control identifier programmed based on the first bitmask; based on the access determination, access to the first peripheral device by the transaction host is allowed or blocked.

In some examples, the method includes the first access controller performing an access determination to the first peripheral based at least on (a) a first access control identifier programmed based on the first bitmask and (b) an operation mode signal indicating a privilege mode of the transactional host or a user mode of the transactional host.

In some examples, the first bitmask corresponding to the first task indicates (a) that the first task is assigned a peripheral access permission to the first peripheral and (b) that the first task is not assigned a peripheral access permission to the second peripheral. Executing 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 a first bitmask corresponding to the first task includes (a) programming the first access control identifier to an access permission value that allows access to the first peripheral during execution of the first task, and (b) programming the second access control identifier to an access prevention value that prevents access to the second peripheral during execution of the first task. During execution of the first task: a first access controller associated with the first peripheral allows access to the first peripheral based on the access permission value of the first access control identifier and a second access controller associated with the second peripheral prevents access to the second peripheral based on the access prevention value of the second access control identifier.

In some examples, the transaction host selectively operates in a privileged mode and a user mode, and the first bitmask corresponding to the first task indicates (a) that the first task is assigned a peripheral access permission to the first peripheral and (b) that the first task is not assigned a peripheral access permission to the second peripheral. Executing 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 a first bitmask corresponding to the first task includes: (a) Programming the first access control identifier to an open access value for the first peripheral that allows access to the first peripheral in both a privileged mode and a user mode of the transaction host; and (b) programming the second access control identifier to a restricted access value for the second peripheral that allows access to the second peripheral in a privileged mode of the transaction host but does not allow access to the second peripheral in a user mode. During execution of the first task: the first access controller associated with the first peripheral allows access to the first peripheral in both a privileged mode and a user mode of the transactional host based on the open access value of the first access control identifier, and the second access controller associated with the second peripheral prevents access to the second peripheral in the privileged mode of the transactional host but does not prevent access to the second peripheral in the user mode of the transactional host based on the restricted access value of the second access control identifier.

Drawings

Exemplary aspects of the disclosure are described below in conjunction with the following drawings, in which:

FIG. 1 illustrates an example electronic device (e.g., soC) that utilizes an access control identifier to control access to peripheral devices, according to one example;

FIG. 2 illustrates additional aspects of the example electronic device of FIG. 1, according to one example;

FIG. 3 illustrates another example electronic device that utilizes an access control identifier to control access to a peripheral device according to one example;

4A-4D illustrate circuit diagrams of example logic circuits provided in respective access controllers, according to some examples;

FIG. 5 is a flow chart of an example method for controlling access to a peripheral in an electronic device using an access control identifier stored in an access control register;

FIG. 6 is a flow chart of an example method for controlling access to a peripheral device in an electronic device using a first example access control identifier scheme;

FIG. 7 is a flow chart of an example method for controlling access to a peripheral device in an electronic device using a second example access control identifier scheme; and is also provided with

FIG. 8 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 according to one example;

FIG. 9 is a flow chart of an example method for controlling access to peripheral devices using task related bitmasks.

It will be appreciated that the reference numerals of any illustrated element appearing in a plurality of different figures have the same meaning in the plurality of figures, and that any illustrated element mentioned or discussed herein in the context of any particular figure is also applicable to every other figure (if any), where the same illustrated element is shown.

Detailed Description

FIG. 1 illustrates an example electronic device 100 that utilizes access control identifiers, which may be programmable, e.g., the corresponding access control identifiers may be set and/or updated over time, to control access to peripheral devices according to one example. The electronic device 100 includes a transaction host 102, a peripheral 104, an access controller 106, and an access control register 110 storing an access control identifier 112. The components of the electronic device 100 may be communicatively connected to each other by any type or types of communication links 114 (e.g., buses, wires, or other types of links). In some examples, the access controller 106 may be connected between the bus and the respective peripheral 104, or alternatively may be indirectly connected to the bus and operable to make access determinations to selected ones of the peripherals 104a-104n connected to the bus.

In some examples, electronic device 100 is a system-on-chip (SoC) device. In other examples, electronic device 100 may be a multi-chip system that includes transaction host 102 provided on one chip and peripheral 104 provided on a separate chip. Transaction host 102 may include any device capable of initiating execution of tasks associated with respective peripheral devices 104, such as tasks that access registers disposed in respective peripheral devices 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, the transaction host 102 may include a bridge connected to the external host 116 (e.g., including a processor separate from the electronic device 100) to allow the external host 116 to access the at least one peripheral device 104.

Peripheral devices 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 ² C (inter-integrated circuit) 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 radioService (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 co-processor.

The electronic device 100 may include any number of peripheral devices 104. The example electronic device 100 shown in fig. 1 includes peripheral devices 104a-104n, but it should be understood that the electronic device 100 may include any number of one or more peripheral devices.

The respective access controllers 106 may be connected to the respective peripheral devices 104 for controlling (e.g., allowing or preventing) access to the respective peripheral devices 104, such as by a device driver (firmware) executed by the transaction host 102. For example, as discussed below with reference to FIG. 2, transactional host 102 can execute firmware to perform various tasks related to peripheral 104. For example, the transaction host 102 may execute device drivers corresponding to the respective peripheral devices 104a-104n to perform tasks (e.g., device driver tasks) related to the respective peripheral devices 104a-104 n. The access controller 106 may control (e.g., allow or block) access to the respective peripheral 104 for the respective task performed by the transactional host 102.

As shown, the electronic device 100 may include respective access controllers 106a-106n corresponding to the respective peripheral devices 104a-104 n. For example, a first access controller 106a may be connected between the transaction host 102 and the first peripheral 104a to control access to the first peripheral 104a by the transaction host 102, a second access controller 106b may be connected between the transaction host 102 and the second peripheral 104b to control access to the second peripheral 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 104a (e.g., associated with a first device driver corresponding to the first peripheral 104 a) and block access to a second task of the first peripheral 104a (e.g., associated with a second device driver corresponding to the second peripheral 104 b). Similarly, the second access controller 106b may allow access to a second task of the second peripheral 104b (associated with a second device driver corresponding to the second peripheral 104 b) and prevent access to a first task of the second peripheral 104b (associated with a first device driver corresponding to the first peripheral 104 a).

The respective access controllers 106a-106n may include electronic circuitry to control (e.g., allow or block) access to the respective peripheral devices 104a-104n by the transaction host 102 based on the respective access control identifiers 112 stored in the access control registers 110 and, in some alternative examples, additional access control input data. As described below, the additional access control input data may include, for example, (a) an Operation Mode Signal (OMS) 120 indicating an operation mode of the transactional host 102 and/or (b) an access request identifier identifying a respective transactional host 102 requesting access to a respective peripheral 104 (discussed below with reference to fig. 3 in connection with an example including a plurality of transactional hosts 102).

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

As discussed below with reference to fig. 2, the transactional host 102 can program (e.g., set or update) the values of the respective access control identifiers 112a-112n based on peripheral access permissions assigned to the respective tasks prior to executing the respective tasks (e.g., firmware tasks). As discussed below, electronic device 100 may store a respective bitmask for a respective task that indicates peripheral access permissions for the respective task, e.g., where the respective bitmask for the respective task indicates whether the respective task is assigned peripheral access permissions to the respective peripheral 104a-104n (or is not assigned peripheral access permissions to the respective peripheral 104a-104 n). For example, electronic device 100 may store a first bitmask for a first task indicating that the first task is assigned peripheral access permissions to first peripheral 104a but not to second peripheral 104b, and a second bitmask for a second task indicating that the second task is assigned peripheral access permissions to second peripheral 104b but not to first peripheral 104 a. In some examples, peripheral access permissions may be assigned to respective tasks (using respective bitmasks for the respective tasks) by a code developer (e.g., firmware developer), for example, based on selected peripherals that may be needed or utilized by the respective tasks. In some examples, the respective access controllers 106a-106n associated with the respective peripheral devices 104a-104n make access determinations for accessing the respective peripheral devices 104a-104n based on the respective access control identifiers 112a-112n corresponding to the respective peripheral devices 104a-104 n. In other examples, the respective access controllers 106a-106n associated with the respective peripheral devices 104a-104n make access determinations for accessing the respective peripheral devices 104a-104n based on (a) the respective access control identifiers 112a-112n corresponding to the respective peripheral devices 104a-104n and (b) the operating mode signal 120 indicating a current operating mode (e.g., privileged mode or user mode) of the transactional host 102.

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

In general, when a transaction host 102 attempts to access a corresponding peripheral 104 (e.g., a first peripheral 104 a), a first access controller 106a may (a) receive an access request from the transaction host 102 for access to the first peripheral 104 a; (b) Accessing an access control identifier 112 for the first peripheral 104a from the access control register 110; (c) Performing an access determination based on the first access control identifier 112a (and, in some examples, additional access control input data); and (d) in response to the access determination, allowing or preventing access to the first peripheral 104a by the transactional host 102.

In a 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:

(a) An access permission setting (e.g., ac_id value= [0 ]) that permits access (e.g., execution of device drivers or other firmware) to the respective peripheral devices 104a-104n by the transactional host 102, and

(b) An access blocking setting (e.g., ac_id value= [1 ]) that blocks access (e.g., execution of device drivers or other firmware) to the respective peripheral devices 104a-104n by the transactional host 102.

Table 1 access control identifier scheme for the first example 。

Ac_id value	Is access to peripheral devices allowed?
		0 (Access allow)	Is that
1 (Access prevention)	Whether or not

In some examples, the respective access controllers 106a-106n may store or access a look-up table (LUT) containing the data of Table 1, which the respective access controllers 106a-106n may access for making the access determination. In some examples, the respective access controllers 106a-106n may store the respective LUTs in a memory 107 (e.g., a read-only memory (ROM) device) (where the respective instances of the memory 107 may be provided in the respective access controllers 106a-106n, or where the memory 107 may be otherwise accessed by the respective access controllers 106a-106 n). In other examples, the respective access controllers 106a-106n may implement the decisions specified in Table 1 using appropriate instances of the logic circuitry 108. For example, as discussed below with reference to FIG. 4A, the respective access controllers 106a-106n may include logic circuitry 108 that includes a NOT gate (or inverter) for processing the access control identifier input to the respective access controllers 106a-106 n. (in another example, the meaning of the ac_id value may be reversed, e.g., 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.)

In a 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 the computer-readable manager code 206, e.g., embodied in the firmware, as shown in FIG. 2 discussed below) to dynamically program the access control identifiers 112a-112n in accordance with the scheme described above, e.g., in real-time, based on a current operating mode of the transaction host (e.g., privileged mode or user mode), and/or prior to initiating a task associated with a particular peripheral 104a-104n (e.g., using a device driver corresponding to the particular peripheral 104a-104 n). For example:

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

(b) Prior to initiating the user mode task associated with the first peripheral device 104a, the transaction host 102 may program the AC identifier 112a to 0 and the AC identifier 112 b..once again, 112n to 1 (allowing the transaction host 102 to access the first peripheral device 104a and preventing access to the peripheral device 104 b...once again, 104 n); and

(c) Prior to initiating the user mode task associated with the second peripheral device 104b, the transaction host 102 may program the AC identifier 112b to 0 and the AC identifiers 112a,112 c..once again, 112n to 1 (allowing the transaction host 102 to access the second peripheral device 104b and preventing access to the peripheral devices 104a,104 c..once again, 104 n).

In a first example, the respective access controllers 106a-106n associated with the particular peripheral 104a-104n make an access determination for accessing the particular peripheral 104a-104n based on the current value of the respective access control identifier 112a-112n corresponding to the particular peripheral 104a-104n, e.g., without additional requirements of the operating mode signal indicating the current operating mode of the transactional host 102. For example, when the first access controller 106a associated with the first peripheral 104a receives an access request from the transaction host 102 to access the first peripheral 104a, the first access controller 106a accesses the corresponding AC identifier 112a corresponding to the first peripheral 104a and, based on the AC identifier 112a, allows the transaction host 102 to access the first peripheral 104a if the ac_id value = 0 and prevents the transaction host 102 from accessing the first peripheral 104a if the ac_id value = 1.

According to the approach of the first example described above, in one example instance, the transaction host 102 may use a first peripheral driver corresponding to the first peripheral 104a to perform a first user-space task associated with the first peripheral 104a, and thus may program the AC identifier 112a to 0 (e.g., using the access control identifier management instructions 214 shown in fig. 2) prior to performing the first task. If the first access controller 106a receives a request from the first peripheral driver to access the first peripheral 104a, the first access controller 106a may access the AC identifier 112a and allow access to the first peripheral 104a in response to the AC identifier 112a value = 0. In another example instance, the transaction host 102 may use a second peripheral driver corresponding to the second peripheral 104b to perform a second user space task related to the second peripheral 104b, and thus may program the AC identifier 112b to 0 to allow access to the second peripheral 104b and the AC identifier 112a to 1 to block access to the first peripheral 104a. If the first access controller 106a receives a request from the second peripheral drive to access the first peripheral 104a (e.g., an error or malicious request from the second peripheral drive), the first access controller 106a may access the AC identifier 112a and block access to the first peripheral 104a in response to the value of the AC identifier 112a = 1. In yet another example instance, the transaction host 102 may perform privileged tasks (e.g., included in the manager firmware) related to the first peripheral 104a or the second peripheral 104b, and thus may program the AC identifier 112a to 0 or the AC identifier 112b to 0, respectively, prior to performing such privileged tasks to thereby allow access to the first peripheral 104a by the first peripheral driver corresponding to the first peripheral 104a or the second peripheral driver corresponding to the second peripheral 104 b.

In a 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:

(a) An open access setting (e.g., ac_id value = [0 ]) that allows access by the transactional host 102 to the corresponding peripheral a-n (e.g., executing a device driver or other firmware) regardless of the current operating mode (e.g., privileged mode or user mode) of the transactional host 102, as well as the transaction host's data processing system

(b) An access setting (e.g., ac_id value= [1 ]) that allows access to the respective peripheral 104a-104n (e.g., executing a device driver or other firmware) by the transactional host 102 only in the privileged mode of the transactional host 102.

Table 2 access control identifier scheme for the second example。

Ac_id value	Transaction host operation mode	Is access to peripheral devices allowed?
			0 (open visit)	0 (user mode)	Is that
0 (open visit)	1 (privilege mode)	Is that
			1 (restricted access)	0 (user mode)	Whether or not
1 (restricted access)	1 (privilege mode)	Is that

In some examples, the respective access controllers 106a-106n may store or access a LUT containing the data of Table 2, which the respective access controllers 106a-106n may access for making the access determination. In some examples, the respective access controllers 106a-106n may store the respective LUTs in respective instance (e.g., read only memory ROM) devices of the memory 107 (where the memory 107 may be provided in the respective access controllers 106a-106n, or the memory 107 may be otherwise accessible by the respective access controllers 106a-106 n). In other examples, the respective access controllers 106a-106n may implement the decisions specified in Table 2 using respective instances of the appropriate logic circuitry 108. For example, as discussed below with reference to FIG. 4B, the respective access controllers 106a-106n may include logic circuitry 108, which logic circuitry 108 includes an NOT gate and an OR gate (OR gate) for processing the access control identifiers input to the respective access controllers 106a-106 n.

In a second example (i.e., implementing the scheme shown in Table 2), the transaction host 102 can execute corresponding firmware (e.g., the access control identifier management instructions 214 shown in FIG. 2) to dynamically program the access control identifiers 112a-112n according to the scheme described above, e.g., in real-time, based on a current operating mode of the transaction host (e.g., privileged mode or user mode) and/or to initiate tasks associated with a particular peripheral 104a-104n (e.g., using a device driver corresponding to the particular peripheral 104a-104 n). For example:

(a) To initiate a task associated with the first peripheral device 104a (regardless of the operational mode of the transaction host 102), the transaction host 102 may program the AC identifier 112a to 0 and the AC identifiers 112b,112 c..once again, 112n to 1 (allowing the transaction host 102 to access the first peripheral device 104a in both the privileged mode and the user mode of the transaction host 102 while preventing the transaction host 102 from accessing the peripheral devices 104b,104 c..once again, 104n in the user mode of the transaction host 102, as discussed below); and

(b) To initiate a task associated with the second peripheral device 104b (regardless of the operational mode of the transaction host 102), the transaction host 102 may program the AC identifier 112b to 0 and the AC identifiers 112a,112 c..once again, 112n to 1 (allowing the transaction host 102 to access the second peripheral device 104b in both the privileged mode and the user mode of the transaction host 102 while preventing the transaction host 102 from accessing the peripheral devices 104a,104 c..once again, 104n in the user mode of the transaction host 102, as discussed below).

In a second example, the respective access controllers 106a-106n associated with the particular peripheral 104a-104n make an access determination to access the particular peripheral 104a-104n based on (a) the current value of the respective access control identifier 112a-112n corresponding to the particular peripheral 104a-104n and (b) the operating mode signal 120 indicating the operating mode (privileged mode or user mode) of the transactional host 102. For example, when the first access controller 106a associated with the first peripheral 104a receives an access request from the transaction host 102 to access the first peripheral 104a, the first access controller 106a accesses (a) the AC identifier 112a corresponding to the first peripheral 104a and (b) the mode of operation signal 120, and determines whether to allow the transaction host 102 to access the first peripheral 104a based on the scheme defined in table 2. In particular, the first access controller 106a determines that the transaction host 102 is permitted to access the first peripheral 104a unless (a) the ac_id value = 1 (restricted access setting) and (b) the operational mode signal value = 0 (user mode).

According to the scheme of the second example described above, in one example instance, the transaction host 102 may initiate a user mode task associated with the first peripheral 104a, and thus may program the AC identifier 112a to 0 to initiate such a task. If the first access controller 106a receives a request from the first peripheral driver to access the first peripheral 104a, the first access controller 106a may (a) access the AC identifier 112a; (b) accessing the operation mode signal 120; (c) If the operating mode signal 120 indicates a user mode (operating mode signal value=0) or a privileged mode (operating mode signal value=1), then performing an access determination to allow the first peripheral driver access to the first peripheral 104a and otherwise preventing the first peripheral driver access to the first peripheral 104a; and (d) allowing or preventing the first peripheral driver from accessing the first peripheral 104a based on the access determination.

In another example instance, the transaction host 102 may use a second peripheral driver corresponding to the second peripheral 104b to initiate a user-mode task associated with the second peripheral 104b, and thus may program the AC identifier 112b to 0 (i.e., open access to the second peripheral 104 b) and may program the AC identifier 112a to 1 (i.e., restrict access to the first peripheral 104 a). If the first access controller 106a receives a request from the second peripheral driver to access the first peripheral 104a, the first access controller 106a may (a) access the AC identifier 112a; (b) accessing the operation mode signal 120; and (c) performing, by the second peripheral driver, an access determination to permit or block the first peripheral 104a, in particular, determining to permit access if the operating mode signal 120 indicates a privileged mode (operating mode signal value=1), and determining to block access if the operating mode signal 120 indicates a user mode (operating mode signal value=0); and (d) allowing or preventing access to the first peripheral 104a by the second peripheral driven access based on the access determination.

As shown in fig. 1, the respective access controllers 106a-106n may receive as inputs: (a) an access request (ACR) for a respective peripheral 104a-104n, (b) a respective AC identifier 112a-112n, and (optionally) (c) an operation mode signal 120, and processing the received input to make an access determination for the respective peripheral 104a-104 n. For simplicity, the access request (ACR shown in fig. 1-2 and th_id shown in fig. 3) and the optional operation mode signal (120 in fig. 1-2 and 120a-120n in fig. 3) are shown in fig. 1-3 as being sent only to access controller 106a; it should be appreciated that access requests and optional mode of operation signals may similarly be sent to the access controllers 106b-106n for operation associated with the respective access controllers 106b-106 n.

As discussed above, in some examples, the respective access controllers 106a-106n of the example electronic device 100 may include (or access) respective look-up tables (LUTs) stored in the memory 107 (e.g., ROM) that define respective access determinations for each ac_id value (e.g., according to the scheme defined above in table 1) or each combination of ac_id values and operating mode signal values (e.g., according to the scheme defined above in table 2). In other examples, such as shown in fig. 4A and 4B, discussed below, the respective access controllers 106a-106n may include an instance of logic circuitry 108, the logic circuitry 108 including one or more logic gates, such as, for example, a not gate (e.g., implementing the scheme defined by table 1 above) nor gate and an or gate (e.g., implementing the scheme defined by table 2 above).

In some examples, electronic device 100 may include AC identifier programming firmware executable by transactional host 102 to dynamically program one, some, or all of AC identifiers 112a-112n, e.g., to initiate tasks related to respective peripheral devices 104a-104n, e.g., based on an operational mode of the transactional host and/or based on the respective peripheral devices 104a-104n selected for access (referred to herein as the peripheral devices 104a-104n requested for access). Further, in some examples, as discussed below with reference to FIG. 2, access control registers 110 are provided in a dedicated peripheral device (similar to peripherals 104a-104 n) that may also be accessed by a corresponding access controller, e.g., where AC identifier programming firmware may access control registers 110 only in a privileged mode of transactional host 102 and not access control registers 110 in a user mode of transactional host 102 (e.g., to program AC identifiers 112a-112 n).

Fig. 2 illustrates additional features and aspects of the electronic device (e.g., soC) 100 of fig. 1, according to an example. As described above, the electronic device 100 includes the transaction host 102, the peripheral devices 104a-104n, the access controllers 106a-106n, and the access control registers 110 storing the access control identifiers 112a-112 n. The components of the electronic device 100 may be communicatively connected to each other by any type or types of communication links 114 (e.g., buses, wires, or other types of links). As described above, each access controller 106a-106n utilizes each access control identifier 112a-112n (and optionally additional input data) to control access to each peripheral 104a-104n, e.g., based on the operating mode (e.g., privileged mode or user mode) of the transactional host 102 and/or based on the peripheral 104a-104n for which access is requested (i.e., the peripheral 104a-104n for which access is requested). The access controllers 106a-106n may implement any of the various example schemes described above, for example, using the access control identifier schemes shown in table 1 or table 2 described above.

As shown in FIG. 2, an access control register 110 including access control identifiers 112a-112n may be provided in the dedicated peripheral 104ac, and a corresponding access controller 106ac may be provided to control access to the peripheral 104ac, e.g., similar to the access controllers 106a-106n that control access to the peripheral 104a-104n, respectively. For example, access controller 106AC may control access to peripheral 104AC based on operation mode signal 120 from transaction host 102 and (optionally) corresponding AC identifier 112 AC. In some examples, access controller 106ac may control access to peripheral 104ac based on operation mode signal 120 from transactional host 102. In other examples, access controller 106AC may operate similar to access controllers 106a-106n, e.g., based on respective AC identifiers 112AC and/or operation mode signals 120 and using an access control identifier scheme as shown in table 1 or table 2 as described above.

As shown in fig. 2, the electronic device 100 may also include a non-transitory memory 202 that stores 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 ROM, erasable Programmable ROM (PROM), electrically Erasable Programmable ROM (EEPROM), flash memory, or any other suitable type and number of memory devices.

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 embodied in firmware (e.g., device drivers and/or other user space firmware associated with the respective peripheral devices 104a-104 n), for example. User space code (e.g., user space firmware) 208 may include functionality that requires or may utilize access to only selected resources (e.g., selected ones of peripherals 104a-104 n). For example, the user space code 208 may include device drivers or other firmware (including the respective tasks 220a-220 n) that require or may utilize access to the selected peripheral devices 104a-104n, e.g., to access data stored in the respective registers 214a-214n provided in the respective peripheral devices 104a-104 n. Thus, a device driver conventionally operating as manager firmware may operate as user space firmware that can only access selected resources (e.g., selected peripheral devices 104a-104 n) to thereby provide enhanced security as described herein.

Privilege section 202a may store manager code (e.g., manager firmware) 206 and bit mask data structure 230. The bitmask data structure 230 may include bitmasks 232a-232n corresponding to the tasks 230a-230n, respectively, wherein the respective bitmask 232n for the respective task 230n indicates a respective access setting for the respective peripheral 104a-104n, e.g., indicates whether the respective task 230n is assigned a peripheral access permission to the respective peripheral 104a-104 n. For example, referring to FIG. 2, task 1 bitmask 232a corresponding to "task 1" 220a may indicate that "task 1" 220a is assigned a peripheral access permission to first peripheral 104a, but is not assigned a peripheral access permission to second peripheral 104 b. The task 2 bitmask 232b corresponding to "task 2" 220b may indicate that "task 2" 220b is assigned a peripheral access permission to the second peripheral 104b, but is not assigned a peripheral access permission to the first peripheral 104 a.

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

The manager code (e.g., manager firmware) 206 may include a scheduler 212 and access control identifier management instructions 214. Scheduler 212 is executed by transactional host 102 to manage execution of user space code (e.g., user space firmware) 208, including tasks 220a-220n, for example. The access control identifier management instructions 214 may be executed by the transaction host 102 to (a) access bitmasks 232a-232n and (b) program the values of the access control identifiers 112a-112n in the access control registers 110 based on the respective bitmasks 232a-232n corresponding to the respective tasks 220a-220n to be performed. In some examples, for example, certain implementations of the first example access control identifier scheme described above (see Table 1), transactional host 102 can utilize bitmasks 232a-232n for user mode operations (e.g., to perform respective tasks 220a-220n in user mode) but not for privileged mode operations (e.g., to perform respective 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.

For example, prior to executing "task 1" 220a, the transaction host 102 may execute the access control identifier management instructions 214 to program the values of the access control identifiers 112a-112n in the access control registers 110 based on the task 1 bitmask 232a and/or based on the operating mode (e.g., privileged mode or user mode) of the transaction host 102. Example embodiments 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.

Example 1: a first example access control identifier scheme (table 1). Under the first example access control identifier scheme described above (see Table 1), the transaction host 102 may utilize the task 1 bitmask 232a for performing "task 1" 220a in user mode, but not for performing "task 1" 220a in privileged mode. For example, prior to executing "task 1" 220a in user mode, the transaction host 102 may execute the access control identifier management instructions 214 to (a) identify that "task 1" 220a is to be executed in user mode of the transaction host 102, (b) access a first bitmask 232a indicating that "task 1" 220a is assigned peripheral access permissions 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 permission value (ac_id value=0) that allows access to the first peripheral device 104a during user mode execution of "task 1" 220a based on the first bitmask 232a and the current mode of operation (user mode), and (b) program the second access control identifier 112b to an access blocking value (ac_id value=0) that blocks access to the second peripheral device 104b during user mode execution of "task 1" 220a. In contrast, prior to executing "task 1" 220a in privileged mode (under the first example access control identifier scheme shown in table 1 above), transactional host 102 can execute access control identifier management instructions 214 to program both first access control identifier 112a and second access control identifier 112b to access permission values (ac_id value = 0) that allow access to both first peripheral 104a and second peripheral 104b during privileged mode execution of "task 1" 220a. In this case, the task 1 bit mask 232a may be ignored by the transaction host 102 because all peripherals 104a-104n are accessible to privileged mode operations.

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

Example 2: a second example access control identifier scheme (table 2). Under the second example access control identifier scheme described above (see table 2), prior to executing "task 1" 220a (in user mode or privileged mode), the transactional host 102 can execute control bit management instructions 214 to (a) program the first access control identifier 112a to an open access setting (ac_id value=0) for the first peripheral 104a that allows access to the first peripheral 104a in both the privileged mode and the user mode of the transactional host 102, and (b) program the second access control identifier 112b to a restricted access setting (ac_id value=1) for the second peripheral 104b that allows access to the second peripheral 104b in the privileged mode of the transactional host 102 but does not allow access to the second peripheral 104b in the user mode.

FIG. 3 illustrates another example electronic device 300 that utilizes a programmable access control identifier to control access to peripheral devices according to one example. Electronic device 300 may be substantially similar to 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 access control registers 110 within peripheral device 104ac that store access control identifiers 112. The components of the electronic device 100 may be communicatively connected to each other by any type or types of communication links 114 (e.g., buses, wires, or other types of links).

The respective access controllers 106a-106n and 106ac may utilize the respective access control identifiers 112 (and optionally additional input data) to control access to the respective peripheral devices 104a-104n and 104ac, such as based on (a) the peripheral devices 104a-104n for which access is requested, (b) the respective transaction hosts 102a-102n (referred to herein as access request transaction hosts 102a-102 n) requesting access to the peripheral devices 104a-104n for which access is requested, and (b) the operation mode signals 120a-120n (e.g., privilege mode or user mode) of the access request transaction hosts 102a-102 n.

The access control register 110 may store an AC identifier array 113 that includes a respective set of AC identifiers 112 for the respective transaction hosts 102a-102n, where the set of AC identifiers 112 for the respective transaction hosts 102a-102n includes the respective AC identifiers 112 for the respective peripheral devices 104a-104n and (optionally) for the peripheral device 104 AC. Table 3 below shows an example AC identifier array 113 for a plurality of transaction hosts 102a-102n and a plurality of peripheral devices 104a-104n and 104 AC.

Table 3. An example AC identifier array 113 for an example electronic device 300 includes a plurality of transaction hosts 102a-102n A plurality of peripheral devices 104a-104n and 104ac 。

The values of the AC identifiers 112 in the AC identifier array 113 may be used by the respective access controllers 106a-106n and 106AC to determine access to the respective peripheral devices 104a-104n and 104AC by the respective transaction hosts 102a-102 n.

In one example, the value of AC identifier 112 in AC identifier array 113 may indicate an access allowed state (ac_id value=0) or an access blocked state (ac_id value=1), e.g., as discussed above with respect to table 1. In such examples, when a requesting access transaction host 102a-102n attempts to access a peripheral 104a-104n or 104AC that is requested to be accessed, an access controller 106a-106n or 106AC that corresponds to the requested access peripheral 104a-104n or 104AC may (a) receive an access request from the requesting access transaction host 102a-102n that includes a transaction host identifier (th_id), (b) identify a value of an AC identifier 112 that corresponds to the requesting access transaction host 102a-102n (based on the received th_id) and the requested access peripheral 104a-104n or 104AC from an AC identifier array 113 stored in the access control register 110, and (c) perform an access determination based on the identified AC identifier 112 to allow or block access to the requested access peripheral 104a-104n or 104AC (i.e., allow access if ac_id value=0 and block access if ac_id value=1), and (d) determine based on the access determination to allow or block access to the requested peripheral 104a-104 a or 104 AC.

In another example, the value of AC identifier 112 in AC identifier array 113 may indicate an open access state (ac_id value=0) or a restricted access state (ac_id value=1), e.g., as discussed above with respect to table 2. In such examples, when a requesting access transaction host 102a-102n attempts to access a requesting access peripheral 104a-104n or 104ac, an access controller 106a-106n or 106ac corresponding to the requesting access peripheral 104a-104n or 104ac may (a) receive an access request including a TH_id from the requesting access transaction host 102a-102 n; (b) Receiving respective operation mode signals 120a-120n from the requesting access transaction hosts 102a-102n, which indicate an operation mode (privileged mode or user mode) of the requesting access transaction hosts 102a-102 n; (c) Identifying, from the AC identifier array 113 stored in the access control register 110, a value of an AC identifier 112 corresponding to the requesting access transaction host 102a-102n (based on the received th_id) and the peripheral 104a-104n or 104AC for which access is requested; (d) Performing an access determination to allow or block access to the peripheral 104a-104n or 104AC for which access is requested based on the identified value of the AC identifier 112 and the operating mode of the requesting access transaction host 102a-102n (e.g., according to the scheme discussed above with respect to table 2); and (e) based on the access determination, allowing or preventing access to the peripheral 104a-104n or 104ac for which access is requested.

As discussed above, in some examples, the respective access controllers 106a-106n of the example electronic device 100 may include respective instances of the memory 107 storing look-up tables (LUTs) or alternatively may include respective instances of the logic circuitry 108 to implement the access determination schemes defined by table 1 or table 2 above.

With respect to the latter, fig. 4A-4D illustrate circuit diagrams of example logic circuitry 108 provided in respective access controllers 106a-106n (and optionally access controller 106 ac) according to some examples.

First, fig. 4A and 4B illustrate example logic circuitry 108 for an example electronic device (e.g., the example electronic device 100 illustrated in fig. 1 and 2) that includes one transaction host 102.

Fig. 4A shows an example logic circuit 108a according to the first example discussed above, i.e., implementing the access control identifier scheme shown in table 1 above. Logic circuitry 108a includes an not gate (or inverter) 402 that inverts the value of the corresponding access control identifier 112 and outputs a value defining the access determination.

Fig. 4B shows an example logic circuit 108B according to the first example discussed above, i.e., implementing the access control identifier scheme shown in table 2 above. The logic circuit 108b includes: a not gate (or inverter) 402 that inverts the value of the corresponding access control identifier 112; and an or gate 404 that processes the value output by the not gate 402 and the operation mode signal 120 and outputs a value defining the access determination.

Next, fig. 4C and 4D illustrate example logic circuitry 108 for an example electronic device (e.g., the example electronic device 300 shown in fig. 3) including a plurality of transaction hosts 102.

Fig. 4C shows an example logic circuit 108C according to the first example discussed above, i.e., implementing the access control identifier scheme shown in table 1 above with multiple transaction hosts 102. Logic circuitry 108c includes a Multiplexer (MUX) 406 that receives (a) the value of AC identifier 112 for the respective transaction host 102 and (b) an access request identifier (th_id) identifying the respective transaction host 102 requesting access to the respective peripheral 104, and selects the value of the respective AC identifier 112 associated with the respective transaction host 102 in response to the access request identifier (th_id), the selected ac_id value being forwarded to a not gate (or inverter) 402, which not gate (or inverter) 402 inverts the ac_id value and outputs a value defining the access determination.

In other examples, the meaning of the example ac_id values set forth in table 1, table 2, and/or table 3 may be reversed, e.g., where ac_id=0 indicates an access prevention or limit access setting and ac_id=1 indicates an access permission or open access setting. In these examples, the NOT gate (inverter) 402 may be omitted from the logic circuits 108a-108D shown in FIGS. 4A-4D.

Fig. 4D shows an example logic circuit 108D according to the first example discussed above, i.e. implementing the access control identifier scheme shown in table 2 above. Logic circuitry 108d includes a Multiplexer (MUX) 406 that receives (a) the value of AC identifier 112 for the respective transaction host 102 and (b) an access request identifier (th_id) identifying the respective transaction host 102 requesting access to the respective peripheral 104, and in response to the access request identifier (th_id) selects the value of the respective AC identifier 112 associated with the respective transaction host 102, the selected ac_id value is forwarded to an inverter gate 402 that inverts the ac_id value. Logic circuitry 108d further includes an or gate 404 that processes the value output by not gate 402 and the operating mode signal 120 of the corresponding transaction host 102 and outputs a value defining the access determination.

FIG. 5 is a flow chart of an example method 500 for controlling access to a peripheral in an electronic device that includes a transaction host, a first peripheral, a second peripheral, 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 a first peripheral and a second access control identifier for a second peripheral are stored in an access control register. For example, the first access control identifier and the second access control identifier may be programmed by the transaction host before performing the respective task (e.g., the device-driven task), e.g., based on an operating mode of the transaction host and/or based on the respective peripheral (e.g., the first peripheral, the second peripheral, or another peripheral) to be accessed for performing the respective task.

At 504, a first access controller associated with a first peripheral receives a request from a transaction host for access to the first peripheral during execution of a respective task. For example, the transaction host may perform a device driver task corresponding to the first peripheral device. In some examples, the access request from the transaction host optionally includes an operation mode signal indicating a privileged mode or a user mode of the transaction host.

At 506, the first access controller accesses a first access control identifier for the first peripheral 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 by the transaction host based at least on the accessed first access control identifier for the first peripheral, e.g., using a respective LUT stored in memory or using a respective logic circuit, e.g., as shown in any of fig. 4A-4D. For example, the first access controller may perform the access determination according to the access control identifier scheme described above with respect to table 1. In some examples, the first access controller may also use the optionally received operation mode signal (see above at 504) as another input for the access determination. For example, the first access controller may perform the 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 operation mode indicated by the selectable operation mode signal.

At 510, the first access controller allows or prevents access to the first peripheral based on the access determination. For example, to block access to the first peripheral, the first access controller may force a "chip select" signal (also referred to as a "peripheral select" signal) associated with the requested transaction from a value of = 1 (indicating that the first peripheral is directed/selected) to a value of = 0 (indicating that the first peripheral is not directed/selected) so that the first peripheral ignores the transaction. Alternatively, to allow access to the first peripheral, the first access controller may leave the chip select signal value unchanged (value=1), such that the first peripheral processes the transaction, or forces the chip select signal associated with the requested transaction from value=0 to value=1. For example, the system may define a chip select signal value of = 0, indicating that the peripheral device is oriented/selected, and a chip select signal value of = 1, indicating that the peripheral device is not oriented/selected.

FIG. 6 is a flow diagram of an example method 600 for controlling access to a peripheral device in an electronic device that includes a transaction host, a plurality of peripheral devices, and an access control register storing respective access control identifiers (AC identifiers) for the plurality of peripheral devices. In some examples, the electronic device may be the example electronic device 100 or electronic device 300 discussed above, and the method 600 may correspond to the access control identifier scheme discussed above with respect to table 1.

At 602, a transaction host programs AC identifiers for a plurality of peripheral devices, e.g., based on a planned operation of the transaction host. In this example, for privileged mode operation, the transaction host sets the AC identifier for the respective peripheral to an access permission setting (ac_id value=0) that allows access to the respective peripheral by the transaction host. In some examples, the transaction host may execute access control identifier management instructions provided in the manager firmware to access and program the AC identifier. In some examples, when setting the AC identifier for privileged mode operation, the transactional host may ignore the bitmask because all peripherals are accessible during privileged mode operation.

At 604, the transaction host operates in a privileged mode, such as by executing associated manager code (e.g., manager firmware). At 606, when the transaction host operates in the privileged mode, a respective access controller corresponding to a respective peripheral of the plurality of peripherals allows access to the respective peripheral based on an access permission setting (ac_id value=0) for the respective AC identifier of the respective peripheral, for example using a respective LUT stored in memory or using a respective logic circuit (e.g., as shown in fig. 4A (single transaction host case) or fig. 4C (multiple transaction host case)).

At 608, when the transaction host operates in a 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, prior to executing a respective task related to peripheral N, the transaction host accesses a respective bitmask associated with the respective task, the respective bitmask indicating access settings for a plurality of peripherals (including peripheral N) that execute the respective task, and programs AC identifiers for the plurality of peripherals based on the respective bitmask. In this example, the transaction host (a) programs the AC identifier for peripheral N to an access permission setting (ac_id value=0) that permits access to peripheral N during user mode execution of the respective task, and (b) programs the AC identifiers for other peripheral devices of the plurality of peripheral devices to an access blocking setting (ac_id value=1) that blocks access to each respective peripheral device during user mode execution of the respective task.

At 612, the transactional host transitions from privileged mode to user mode and performs the corresponding task related to peripheral N. At 614, to perform the respective task related to peripheral N, the access controller corresponding to peripheral N allows access to peripheral N (e.g., access to registers in peripheral N) based on the access permission setting (ac_id value=0) for the AC identifier of peripheral N (as programmed based on the respective bitmask associated with the respective task), e.g., using the respective LUT stored in memory or using the respective logic circuitry (e.g., as shown in fig. 4A (single transaction host case) or fig. 4C (multiple transaction host cases)). If the transaction host attempts to access any of the other peripheral devices, then the access controller corresponding to the respective other peripheral device blocks access to the other peripheral device based on the access blocking setting (ac_id value=1) for the respective AC identifier of the other peripheral device, for example using the respective LUT or logic circuit (e.g., as shown in fig. 4A or 4C).

At 616, the transaction host completes the corresponding task associated with peripheral N. At 618, the transaction host may identify a next transaction host activity to execute in user mode. For example, as indicated at 620, if the manager firmware executed by the transactional host identifies a next peripheral related task (related to the same peripheral or another peripheral) to be executed in user mode, the method may return to 610, where the transactional host programs the AC identifier accordingly for executing the next task (e.g., based on a respective bitmask associated with the next task). As another example, as indicated at 622, if the manager firmware executed by the transactional host identifies a manager or privileged operation to be performed, the method may return to 602, where the transactional host (optionally) programs AC identifiers for the plurality of peripheral devices to an access permission setting (ac_id value=0) (e.g., ignores the corresponding bit mask) to allow the transactional host to access the corresponding peripheral devices during the manager or privileged operation, as discussed above. In some examples or situations, programming the AC identifier for the manager or privileged operation may be superfluous (because all registers may be accessed by a transactional host running the manager code), and thus AC identifier programming at 602 may be omitted or optional.

FIG. 7 is a flow chart of an example method 700 for controlling access to a peripheral device in an electronic device that includes a transaction host, a plurality of peripheral devices, and an access control register storing respective access control identifiers (AC identifiers) for the plurality of peripheral devices. In some examples, the electronic device may be the example electronic device 100 or the example electronic device 300 discussed above, and the method 700 may correspond to the access control identifier scheme discussed above with respect to table 2.

At 702, a transaction host programs AC identifiers for a plurality of peripheral devices, e.g., based on a planned operation of the transaction host. In this example, for privileged mode operation, the transaction host sets the AC identifier for the corresponding peripheral to the access restriction setting (ac_id value=1). In some examples, the transaction host may execute access control identifier management instructions provided in the manager firmware to access and program the AC identifier.

At 704, the transactional host operates in a privileged mode, such as by executing associated manager firmware. At 706, respective access controllers corresponding to respective ones of the plurality of peripheral devices allow access to the respective peripheral devices when the transaction host operates in a privileged mode (where the AC identifier is programmed to 1), for example using respective LUTs stored in memory or using respective logic circuitry, for example as shown in fig. 4B (single transaction host scenario) or fig. 4D (multiple transaction host scenario). Each request by the transaction host to access the respective peripheral may include an operation mode signal indicating the privilege mode of the transaction host (e.g., operation mode signal value = 1 according to the control bit scheme shown in table 2). For a respective request to access a respective peripheral by a transactional host, a respective access controller corresponding to the respective peripheral may determine whether to permit or block access to the respective peripheral based on (a) a respective AC identifier for the respective peripheral and (optionally in a multiple transactional host scenario) the respective transactional host and (b) an operational mode signal (e.g., operational mode signal value = 1) indicating a privileged mode according to a control bit scheme as shown in table 2 above. More specifically, the respective access controller allows access to the respective peripheral based on the privilege mode (e.g., operating mode signal value = 1) of the respective transaction host.

At 708, when the transaction host operates in the privileged mode, 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 the user mode. At 710, prior to executing a respective task related to peripheral N in user mode, a transaction host accesses a respective bitmask associated with the respective task, the respective bitmask indicating access settings for a plurality of peripherals (including peripheral N) that execute the respective task, and programs AC identifiers for the plurality of peripherals based on the respective 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 N to an open permission setting (ac_id value=0) and (b) programs the AC identifiers for other peripheral devices of the plurality of peripheral devices associated with the transaction host to a restricted access setting (ac_id value=1).

At 712, the transactional host transitions from the privileged mode to the user mode and performs the corresponding task related to peripheral N. At 714, access to peripheral N (e.g., access to registers in peripheral N) is permitted, e.g., using a respective LUT stored in memory or using a respective logic circuit (e.g., as shown in fig. 4B (single transaction host case) or fig. 4D (multiple transaction host cases)) in order to perform a respective task related to peripheral N. If the transaction host attempts to access any of the other peripheral devices, then the respective access controller corresponding to the other peripheral device blocks access to the other peripheral device based on (a) the restricted access setting (ac_id value=1) and (B) the user mode of the transaction host (operation mode signal value=0), e.g., using the respective LUT or logic circuit as shown in fig. 4B or 4D, according to table 2.

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

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

At 802, a first access control identifier for a first peripheral and a second access control identifier for a second peripheral are stored in an access control register. The transaction host may dynamically program the first access control identifier and the second access control identifier over time 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. In some examples, the transaction host may execute access control identifier management instructions provided in the supervisory firmware to dynamically program the first access control identifier and the second access control identifier before executing the corresponding task (e.g., device driven task).

For example, at 804, for privileged mode operation, the transactional host sets a first access control identifier and a second access control identifier to allow access to the first peripheral and the second peripheral, respectively. In some examples or situations, programming the AC identifier for privileged mode operation may be superfluous (because all registers may be accessed by a transactional host running manager code), and thus 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 an access bit scheme as discussed above with respect to any of table 1, table 2, or table 3 above. At 806, the transactional host performs privileged mode operation at a first time, so at 806, the operating mode signal indicates privileged mode.

At 808, for a user mode operation (user mode task) associated with the first peripheral device, the transaction host accesses a respective bitmask associated with the user mode task, the respective bitmask indicating access settings for at least the first peripheral device and the second peripheral device, and programs AC identifiers for at least the first peripheral device and the second peripheral device based on the respective 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 an access bit scheme as discussed above with respect to any of table 1, table 2, or table 3 above. At 810, the transaction host performs a user mode task associated with the first peripheral device at a second time, and thus at 810, the operation mode signal indicates a user mode.

The transaction host may 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.

FIG. 9 is a flowchart of an example method 900 for controlling access to peripherals using a task related bitmask in an electronic device that includes a transaction host, a first peripheral, a second peripheral, and an access control register that includes a first access control identifier for the first peripheral and a second access control identifier for the second peripheral. At 902, computer-readable code comprising a first task associated with a first peripheral device and a first bitmask corresponding to the first task is stored, wherein the first bitmask indicates respective access settings for the first peripheral device and the second peripheral device for performing the first task. At 904, the transaction host executes an access control identifier management instruction prior to executing the first task to program the first access control identifier and the second access control identifier in the access control register based on (a) a first bitmask corresponding to the first task and, in some implementations, (b) an operating mode of the transaction host. At 906, after updating the first access control identifier and the second access control identifier in the access control register, the transaction host performs a first task associated with the first peripheral device. At 908, during execution of the first task, a first access controller associated with the first peripheral controls access to the first peripheral based at least on a first access control identifier programmed based on the first bitmask in the access control register. At 910, also during execution of the first task, a second access controller associated with the second peripheral controls access to the second peripheral based at least on a second access control identifier programmed based on the first bitmask in the access control register.

Claims

1. An electronic device, comprising:

a first peripheral device;

a second peripheral device;

a non-transitory memory for storing:

a manager firmware comprising access control identifier management instructions;

computer readable code comprising a first task associated with the first peripheral device;

a first bitmask corresponding to the first task, the first bitmask indicating respective access settings for the first and second peripheral devices for executing the first task;

an access control register comprising a first access control identifier for the first peripheral and a second access control identifier for the second peripheral;

a transaction host, the transaction host to:

executing the access control identifier management instructions in the manager firmware to program a first access control identifier and a second access control identifier in the access control register based on a first bitmask corresponding to the first task; and

after updating a first access control identifier and a second access control identifier in the access control register based on the first bitmask, performing a first task related to the first peripheral;

A first access controller to control access to the first peripheral based at least on a first access control identifier in the access control register programmed based on the first bitmask; and

a second access controller that controls access to the second peripheral based at least on a second access control identifier in the access control register programmed based on the first bitmask.

2. The electronic device of claim 1, wherein the electronic device is a system on chip (SoC) device.

3. The electronic device of any of claims 1-2, wherein the transaction host comprises a processor or a Direct Memory Access (DMA) engine.

4. The electronic device of any of claims 1-3, wherein the first bitmask and the second bitmask are stored in a bitmask data structure in the non-transitory memory.

5. The electronic device of any of claims 1-4, wherein:

the first bitmask includes one or more first bitmask bits indicating access settings for performing the first task for the first peripheral and one or more second bitmask bits indicating access settings for performing the first task for the second peripheral; and is also provided with

The first access control identifier comprises one or more first access control bits and the second access control identifier comprises one or more second first access control bits.

6. The electronic device of any of claims 1-5, wherein:

the computer readable code includes a second task associated with the second peripheral device;

the non-transitory memory storing a second bitmask corresponding to the second task, the second bitmask indicating respective access settings for the first peripheral and the second peripheral for performing the second task; and is also provided with

The transaction host is used for:

executing the access control identifier management instructions in the manager firmware to program a first access control identifier and a second access control identifier in the access control register based on a second bitmask corresponding to the second task; and

after updating the first access control identifier and the second access control identifier in the access control register based on the second bitmask, performing a second task related to the second peripheral.

7. The electronic device of any of claims 1-6, wherein the non-transitory memory comprises:

a non-privileged portion storing computer readable code comprising the first task and the second task; and

a privileged portion storing manager firmware including the access control identifier management instruction and the first bitmask corresponding to the first task.

8. The electronic device of any of claims 1-7, wherein the first access controller is to:

receiving an access request from the transaction host for executing the first task for accessing the first peripheral device;

performing an access determination to the first peripheral based at least on a first access control identifier, the first access control identifier programmed based on a first bitmask corresponding to the first task; and

based on the access determination, access to the first peripheral device by the transaction host is allowed or blocked.

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

10. The electronic device of any of claims 1-9, wherein the first bitmask corresponding to the first task indicates (a) that the first task is assigned peripheral access permissions to the first peripheral and (b) that the first task is not assigned peripheral access permissions to the second peripheral.

11. The electronic device of claim 10, wherein:

the first bitmask corresponding to the first task indicates (a) that the first task is assigned peripheral access permissions to the first peripheral and (b) that the first task is not assigned peripheral access permissions to the second peripheral;

the access control identifier management instructions are to program the first access control identifier and the second access control identifier in the access control register based on the first bitmask prior to execution of the first task, including (a) updating the first access control identifier to an access permission value that allows access to the first peripheral during execution of the first task, and (b) updating the second access control identifier to an access prevention value that prevents access to the second peripheral during execution of the first task;

The first access controller allowing access to the first peripheral during execution of the first task based on an access permission value of the first access control identifier; and is also provided with

The second access controller blocks access to the second peripheral during execution of the first task based on an access blocking value of the second access control identifier.

12. The electronic device of any of claims 1-11, wherein:

the transaction host selectively operating in a privileged mode and a user mode;

the first bitmask corresponding to the first task indicates (a) that the first task is assigned peripheral access permissions to the first peripheral and (b) that the first task is not assigned peripheral access permissions to the second peripheral; and is also provided with

The access control identifier management instructions are to program the first access control identifier and the second access control identifier in the access control register based on the first bitmask prior to execution of the first task, including (a) updating the first access control identifier to an open access setting for the first peripheral, the open access setting allowing access to the first peripheral in both a privileged mode and a user mode of the transactional host; and (b) updating the second access control identifier to a restricted access value for the second peripheral, the restricted access value allowing access to the second peripheral in a privileged mode of the transactional host but not allowing access to the second peripheral in a user mode of the transactional host.

13. The electronic device of any of claims 1-12, wherein the access control register is disposed in a third peripheral.

14. A method, the method comprising:

in an electronic device comprising a transaction host, a first peripheral, a second peripheral, and an access control register, the access control register comprising a first access control identifier for the first peripheral and a second access control identifier for the second peripheral, storing (a) computer readable code comprising a first task associated with the first peripheral, and (b) a first bitmask corresponding to the first task, the first bitmask indicating respective access settings for performing the first task for the first peripheral and the second peripheral;

the transaction host executing, prior to executing the first task, 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 a first bitmask corresponding to the first task;

after updating the first access control identifier and the second access control identifier in the access control register based on the first bitmask, the transaction host performs a first task related to the first peripheral;

During execution of the first task:

a first access controller associated with the first peripheral controls access to the first peripheral based at least on the first access control identifier in the access control register programmed based on the first bitmask; and is also provided with

A second access controller associated with the second peripheral controls access to the second peripheral based at least on the second access control identifier in the access control register programmed based on the first bitmask.

15. The method according to claim 14, the method comprising:

storing computer readable code comprising a second task associated with the second peripheral device;

storing a second bitmask corresponding to the second task, the second bitmask indicating respective access settings for the first peripheral and the second peripheral for performing the second task;

the transaction host executing the access control identifier management instruction to program a first access control identifier and a second access control identifier in the access control register based on a second bitmask corresponding to the second task prior to executing the second task;

After updating the first access control identifier and the second access control identifier in the access control register based on the second bitmask, the transaction host performs a second task related to the second peripheral;

during execution of the second task:

a first access controller associated with the first peripheral controlling access to the first peripheral based at least on the first access control identifier in the access control register programmed based on the second bitmask; and is also provided with

A second access controller associated with the second peripheral controls access to the second peripheral based at least on the second access control identifier in the access control register programmed based on the second bitmask.

16. The method of any of claims 14-15, wherein the first access controller controlling access to the first peripheral based at least on the first access control identifier programmed based on the first bitmask comprises:

the first access controller receiving an access request from the transaction host to the first peripheral device for performing the first task;

The first access controller performs an access determination for the first peripheral based at least on the first access control identifier programmed based on the first bitmask; and is also provided with

The first access controller allows or prevents access to the first peripheral by the transaction host based on the access determination.

17. The method of claim 16, the method comprising the first access controller performing an access determination for the first peripheral based at least on (a) the first access control identifier programmed based on the first bitmask and (b) an operation mode signal indicating a privilege mode of the transactional host or a user mode of the transactional host.

18. The method of any one of claims 14 to 17, wherein:

executing 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 first bitmask corresponding to the first task, including (a) updating the first access control identifier to an access permission value that allows access to the first peripheral during execution of the first task, and (b) updating the second access control identifier to an access prevention value that prevents access to the second peripheral during execution of the first task; and view of

During execution of the first task:

a first access controller associated with the first peripheral device allowing access to the first peripheral device based on an access permission value of the first access control identifier; and

a second access controller associated with the second peripheral blocks access to the second peripheral based on an access blocking value of the second access control identifier.

19. The method of any one of claims 14 to 18, wherein:

executing 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 a first bitmask corresponding to the first task includes: (a) Updating the first access control identifier to an open access value for the first peripheral, the open access value allowing access to the first peripheral in both a privileged mode and a user mode of the transactional host; and (b) updating the second access control identifier to a restricted access value for the second peripheral, the access restricted value allowing access to the second peripheral in a privileged mode of the transactional host but not allowing access to the second peripheral in a user mode; and is also provided with

During execution of the first task:

the first access controller associated with the first peripheral allowing access to the first peripheral in both a privileged mode and a user mode of the transactional host based on an open access value of the first access control identifier; and is also provided with

The second access controller associated with the second peripheral prevents access to the second peripheral in a privileged mode of the transactional host but does not prevent access to the second peripheral in a user mode of the transactional host based on a restricted access value of the second access control identifier.