ACCESS PERMISSIONS FOR STORAGE AREAS

Abstract

A control unit (300) comprising the following: a control unit memory (120) with a configuration register (124) for defining an operating mode of the control unit (300) and a lock register (122) for storing a lock indicator, wherein, immediately after authorization information has been set during a system initialization event, the lock indicator in the lock register (122) is set to a value indicating whether at least part of the authorization information can be changed or not, and set up a controller (302) to: to receive a request for access to a first memory area of ​​a memory (308) from a request device (306) separate from the control unit (300); in response to the request to access authorization information, which contains a multitude of entries corresponding to different memory areas (110-1 to 110-n) of the memory (308), each entry of the multitude of entries comprising a multitude of indicators, the indicators comprising: a first indicator that can assume an active value, representing an execution access mode in which instructions are retrieved from the respective memory area for execution, a second indicator that can assume an active value representing a privileged access mode in which access to the respective memory area is permitted if the requester has a privileged level; and a third indicator representing a read or write mode on a memory area; and Based on the occurrence of the system initialization event and according to the metadata of the request and the authorization information, to determine whether access to the content in the first storage area is allowed.

Description

background

[0001] A computer system contains an operating system kernel (OS kernel), which is the part of the operating system that controls various aspects of the computer system. The operating system kernel (or simply "kernel") controls the interactions between hardware components and machine-readable instructions, such as an application program or other program code. The kernel is one of the first programs loaded at system startup, after the system firmware has been loaded, to initialize the computer system. EP 3 210 123 B1 describes a memory protection key architecture with independent user and supervisor domains for controlling memory access. DE 10 195 999 T5 describes a system and method for controlling access to an isolated memory area. US 2018 / 0 173 294 A1 describes a hybrid standby power management system.US 5,987,557 A describes a hardware protection monitoring circuit for monitoring access to target resources and blocking unauthorized transactions. It is an object of the invention to propose a control unit, a system, and a method for access control to memory areas. This object is achieved by a control unit according to claim 1, a system according to claim 15, and a method according to claim 19. Brief description of the drawings

[0002] Some implementations of the present revelation are described with reference to the following figures. Fig. Figure 1 is a block diagram of a computer system, showing some examples. Fig. Figure 2 is a flowchart of a process for electronic control unit (ECU) control, based on some examples. Fig. Figure 3 is a block diagram of a control unit according to some examples. Fig.Figure 4 is a block diagram of a system, based on some examples. Fig. Figure 5 is a flowchart of a process according to some examples.

[0003] In the drawings, identical reference numbers denote similar, but not necessarily identical, elements. The illustrations are not necessarily to scale, and the size of some parts may be exaggerated to better illustrate the example shown. Furthermore, the drawings provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations shown in the drawings. Detailed description

[0004] Certain kernel-related information can be stored in a separate area of ​​memory, which is protected from access by other entities, such as other programs or users. The information stored in this separate memory area can include kernel program code (including machine-readable instructions) and data used by the kernel.

[0005] The kernel itself can be compromised if it is modified by malware or another attacker. A rootkit, for example, can be used to grant a user or other entity access to a sensitive part of a computer system, such as the kernel. A rootkit comprises a collection of programs that enable unauthorized access to a computer system, which is not easily detected. The kernel can also be corrupted by kernel-mode malware.

[0006] Other programs in a computer system can rely on the kernel to protect program code and data. Furthermore, a security mechanism, such as an anti-malware program, relies on the kernel functioning correctly to provide protection against malware attacks. Once the kernel is compromised, other security mechanisms that depend on a properly functioning kernel can also be affected.

[0007] In accordance with some implementations of this disclosure, a protection mechanism is provided to protect information relating to a kernel or other program or entity stored in memory regions. The protection mechanism determines whether a request to access a memory region containing protected information is permitted based on the occurrence of a system initialization event (e.g., completion of kernel initialization, completion of loading a portion of the kernel into memory, completion of a boot phase by the firmware, etc.) and according to the authorization information that identifies access permissions for the corresponding memory regions.

[0008] Fig.Figure 1 is a block diagram of a computer system 100 according to some implementations of the present disclosure. Examples of computer systems are a desktop computer, a notebook computer, a tablet computer, a smartphone, a server computer, a communication node, a storage system, an Internet of Things (IoT) device, a gaming device, a vehicle or vehicle control system, and so on.

[0009] Computer System 100 contains a processor 102, which can execute various programs (machine-readable instructions) within Computer System 100. Examples of such programs that can be executed by Processor 102 include firmware 106 (e.g., boot code for starting Computer System 100), an operating system (OS) 104, an application 108, or other program. The operating system 104 comprises a kernel 105 and other program code. Each program (104, 106, or 108) can be stored on a storage medium and loaded for execution by Processor 102.

[0010] A processor can be a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, or any other hardware processing circuit.

[0011] In some examples, processor 102 is the main processor of computer system 100 for running system programs such as the operating system 104, the firmware 106 and the application 108.

[0012] In other examples, processor 102 can be a different type of processor, such as an administrative processor capable of performing various administrative tasks for computer system 100. An example of such an administrative processor is a Baseboard Management Controller (BMC), which can perform dedicated administrative tasks for computer system 100 independently of the computer system 100's main processor. The BMC can continue to operate even when computer system 100 is powered off. The BMC can remain powered even when computer system 100 is powered off.

[0013] The computer system 100 also includes a system memory 110 for storing data. The system memory 110 can be implemented using one or more storage devices. Examples of storage devices include any one or a combination of the following: a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, a flash memory device, or any other type of storage device.

[0014] System memory 110 is associated with a memory controller 112, which manages access (writing or reading) to data in system memory 110 in response to requests received by the memory controller 112 from a requesting device, such as the processor 102 or another unit (e.g., an input / output device, etc.). In examples where the functionality of the memory controller is divided between a processor side and a memory side, the memory controller 112 can be referred to as a media controller, capable of issuing instructions to system memory 110, with the instructions conforming to the specifications (e.g., timing specifications, signal specifications, etc.) of system memory 110.In such a split-architecture memory controller, a processor-side memory controller in the processor 102 issues requests to the media controller 112, which translates the requests from the processor-side memory controller into instructions that are issued to the system memory 110.

[0015] In other examples, a split-architecture memory controller is not used.

[0016] As used here, a "controller" can refer to a hardware processing circuit, which may include any or a combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, or other hardware processing circuitry. Alternatively, a "controller" can refer to a combination of a hardware processing circuit and machine-readable instructions (software and / or firmware) that can be executed on the hardware processing circuit.

[0017] In accordance with some implementations of the present disclosure, a protective control device 114 is provided between the processor 102 (or another request device capable of requesting memory access) and the system memory 110. In some examples, the protective control device 114 can be implemented as part of the memory controller 112. In other examples, the protective control device 114 can be separate from the memory controller 112 and can be implemented separately from the memory controller 112 using a processing circuit or a combination of a hardware processing circuit and machine-readable instructions.

[0018] The protection control unit 114 is separate from the processor 102.

[0019] System memory 110 comprises memory areas 110-1 through 110-n (where n equals 1), which can be used to store the respective information associated with kernel 105. Memory areas 110-1 through 110-n can also store other information, including information relating to an application, user, or other entity.

[0020] The protection control unit 114 is capable of protecting the information stored in memory areas 110-1 to 110-n. The information protected by the protection control unit 114 is referred to as protected content 111-1 to 111-n, which is stored in the respective memory areas 110-1 to 110-n.

[0021] In some examples, the protected content includes static information that is not modified during the operation of computer system 100 after it has booted. Note that the static information can be set during the boot process of computer system 100, and in some cases, the static information can be set to different information for different boot processes of computer system 100.

[0022] Alternatively, the protected content, which is protected by the protection control unit 114, includes information that can only rarely be changed during the operation of the computer system 100.

[0023] The protection control unit 114 includes a control unit controller 116, which is capable of receiving a request to access the system memory 110 from the processor 102 (or from another requesting device). The control unit controller 116 can determine, based on certain criteria, whether or not access to protected content in the system memory 110 is permitted.

[0024] The specified criteria can include a criterion relating to an authorization table 118 and a criterion relating to the occurrence of a system initialization event. The authorization table 118 can be stored in an ECU memory 120, which is part of the protection ECU 114, or which can be separate from the protection ECU 114.

[0025] The authorization table 118 contains authorization information that identifies the access permissions for the respective memory areas 110-1 to 110-n of system memory 110. More generally, the authorization table 118 can be in the form of any data structure capable of storing authorization information. In other words, the data structure does not have to be in tabular form.

[0026] The access permissions identified by the permission information can be selected from: a read access mode (which specifies whether reading information in a memory area 110-i, i = 1 to n, is allowed or not), a write access mode (which specifies whether writing information to a memory area 110-i is allowed or not), a privileged access mode (which specifies whether information in a memory area 110-i may be accessed by a requester with a privileged level or not), and an instruction access mode (which specifies whether information in a memory area 110-i contains machine-readable instructions that may be retrieved for execution or not).

[0027] Although several examples of access permissions are listed above, it should be noted that in other examples additional or alternative access permissions may be specified by the permission information in the permission table 118.

[0028] If the access permissions specify a privileged access mode for a given memory area 110-i, then the requester (e.g., a program running on the processor 102, an I / O device or a program running from the I / O device, or any other requesting instance) requesting access to the given memory area 110-i is permitted to access the information in the given memory area 110-i if the requester has a privileged level (e.g., a supervisor level, an administrator level, a highly privileged level of the operating system 104, etc.). If the requester has, for example, a user level (a non-privileged level), then it is not allowed to access the given memory area 110-i.

[0029] If, on the other hand, the access permissions specify an unprivileged access mode for the given memory area 110-i, then access to information in the given memory area 110-i is allowed for any requester, including a requester who has a privileged level or a requester who has a user level (which is an example of an unprivileged level).

[0030] In some examples, the authorization table 118 can define access permissions for corresponding physical address ranges. An example of the authorization information that can be included in the authorization table 118 is listed in Table 1 below: Table 1 Starting address End of address R W P X A1 A2 1 0 1 0 Kernel configuration A3 A4 0 0 1 1 Driver Code A5 A6 1 0 1 0 Syscall table A7 A8 1 0 1 0 Kernel RO data A9 A10 0 0 1 1 Kernel code A11 A12 1 1 1 0 Kernel data A13 A14 0 0 0 0 Firmware

[0031] In Table 1, the first column specifies the starting address of each physical address range, and the second column specifies the ending address of each physical address range. For example, the first row of Table 1 indicates that the starting address of a first physical address range (one of the memory ranges 110-1 to 110-n from Fig. 1) A1 is and that the end address of the first physical address range is A2.

[0032] Each combination of a start address and an end address identifies a corresponding memory area 110-i.

[0033] The "R" column in Table 1 specifies the read access mode (e.g., a value of "1" indicates that reading the respective memory area is allowed, while a value of "0" indicates that reading the respective memory area is not allowed). The "W" column specifies the write access mode (e.g., a value of "1" indicates that writing the respective memory area is allowed, while a value of "0" indicates that writing the respective memory area is not allowed).

[0034] The column “P” indicates the privileged access mode (e.g., a value of “1” indicates that access to the respective memory area is only allowed if the requester has a privileged level, and a value of “0” indicates that the requester does not need to have the privileged level to access the respective memory area).

[0035] The column “X” indicates the execution access mode (e.g., a value of “1” indicates that the respective memory area contains instructions to be fetched for execution, and a value of “0” indicates that the information in the memory area does not contain any instructions for execution).

[0036] In the example in Table 1, the physical address range (A1, A2) contains kernel configuration information (which defines a configuration of kernel 105), the physical address range (A3, A4) contains driver code (which contains the program code of one or more drivers that control access to corresponding hardware components in computer system 100), the physical address range (A5, A6) contains a syscall table (which contains information about system calls relating to kernel 105), the physical address range (A7, A8) contains kernel write-protection (RO) data, the physical address range (A9, A10) contains kernel code, the physical address range (A11, A12) contains kernel data (which can be read and written), and the physical address range (A13, A14) contains firmware.

[0037] Although specific examples of information contained in the respective physical address ranges are listed in Table 1, the physical address ranges in other examples may also contain other types of information, regardless of whether they relate to kernel 105 or another entity.

[0038] Table 1 shows that the access permissions indicate that the driver code and kernel code can be retrieved from their respective memory areas for execution if the requester has the required privilege level. However, the access permissions for the driver code and kernel code also indicate that read and write access to the driver code and kernel code is not permitted.

[0039] Table 1 shows the access rights, indicating that the kernel configuration, the syscall table and the kernel RO data can be read if the requester has a privileged level, but that write access and execution access are not allowed.

[0040] Table 1 shows the access permissions, indicating that kernel data in the physical address range (A11, A12) can be read or written if the requester has a privileged level.

[0041] Table 1 shows the access permissions, indicating that read access is not allowed for the firmware, write access is not allowed, and execution access is not allowed.

[0042] In examples according to Fig.1. The control unit memory 120 also stores a lock register 122 and a configuration register 124. The lock register 122 can store a lock indicator (including a bit or a number of bits) that can be set to corresponding values ​​to indicate whether a part (or corresponding parts) of the authorization table 118 can be changed or not. If the lock indicator is set to a lock value, this indicates that the part(s) of the authorization table 118 may not be changed. However, if the lock indicator is set to an unlock value (which differs from the lock value), this indicates that the part(s) of the authorization table 118 may be changed.

[0043] The lock register 122 provides a mechanism (separate from the kernel 105) to prevent the authorization table 118 from being modified. Even if, for example, the kernel 105 is compromised, the control unit controller 116 and the lock register 122, which contains the lock indicator set to the lock value, would prevent any modification of the authorization table 118 in order to protect the integrity of the protected content 111-1 to 111-n.

[0044] The entries in authorization table 118 can be set by kernel 105 after information relating to kernel 105 (or another entity) has been written to memory areas 110-1 to 110-n of system memory 110. Kernel 105 can be trusted during a kernel initialization phase of a boot operation protected by a trust basis (e.g., a safe boot operation, a measured boot operation, etc.).

[0045] Kernel 105 can lock authorization table 118 immediately after it has populated it. Kernel 105 locks authorization table 118 by setting the lock indicator in lock register 122 to the lock value. In this context, kernel 105 locking authorization table 118 "immediately after" populating it means that kernel 105 locks authorization table 118 immediately after it has been populated, without any intervening operation that could be unsafe.

[0046] The protection control unit 114 can rely on system events, such as a power-on event (an event corresponding to the activation of the power supply to the computer system 100) or a power-off event (an event corresponding to the deactivation of the power supply to the computer system 100). In response to a power-on event, the protection control unit 114 can determine that a new boot cycle has been triggered, and the authorization table 118 is unlocked based on the reset of the lock indicator in the lock register 122.

[0047] In other examples, a portion of the authorization table 118 (or the entirety of authorization table 118) can be reset in response to a power-off or power-on event. In further examples, a portion of authorization table 118 (or the entirety of authorization table 118) can be made persistent across power cycles (as in examples where the authorization table (partially) is stored in non-volatile memory). The contents of the persistent authorization table (partially) can be modified using credential-based access (see below).

[0048] Configuration register 124 can define an operating mode of the protection control unit 114. Configuration register 124 can be set to different values ​​for different operating modes. In some examples, firmware 106 can set configuration register 124 to a specific value during a boot process. If configuration register 124 is set to an initial value, this means that after the first write of authorization table 118 (e.g., by firmware 106 and / or kernel 105 during a boot process), further writing of authorization table 118 is not permitted (by setting the lock indicator to the initial value). In other words, authorization table 118 can only be written once in each boot cycle.Upon a subsequent restart of the computer system 100, the contents of the authorization table 118 can be set by the firmware 106 and / or the kernel 105 (possibly to different values), since the firmware 106 and / or the kernel 105 can be trusted during the initial stages of the boot process (e.g., not compromised by malware or any other attack).

[0049] The operating mode in which no write access to the authorization table 118 is allowed after the boot process is intended for the case where the protected content 111-1 to 111-n is static and does not change after initialization in the boot process.

[0050] Configuration register 124 can be set to a second value to indicate that credential-based modification of credential table 118 is permitted, even after credential table 118 was initially written during a boot process. In credential-based access mode, the credential table can be unlocked to allow modification of information in memory areas 110-1 to 110-n. In credential-based access mode, after kernel 105 has set the contents of credential table 118 during the boot process, it sets the lock indicator in lock register 122 to the lock value to prevent further modification of credential table 118.However, if firmware 106 or another instance is presented with a specific credential, firmware 106 or another instance can change the lock indicator to the unlock value to allow kernel 105 (or another instance) to update the credential table 118 to allow a change of information in any of the memory areas 110-1 to 110-n.

[0051] The specified credential for unlocking credential table 118 can be in the form of a password, such as a randomly generated 256-bit value (or any other value). Alternatively, the specified credential can be a signed token. For example, firmware 106 can set the credential before transferring control to kernel 105 during a boot process. Kernel 105, or another instance, can then present the credential to firmware 106 to unlock credential table 118, provided the firmware verifies the presented credential. Modifying credential table 118 can be performed in various scenarios, such as in examples where kernel 105 contains self-modifying code, in examples to perform live patching (live updates) of kernel 105, and so on.

[0052] For credential-based access mode, kernel 105 can go through a trusted intermediary, such as firmware 106, to make changes to locked memory areas (like 110-1 to 110-n). The trusted intermediary can verify that any new information to be written to the locked memory areas 110-1 to 110-n is valid (e.g., not compromised or corrupted by malware), and the trusted intermediary can take action to enable the unlocking of the locked memory areas 110-1 to 110-n by presenting the credential to kernel 105 or the protection control device 114.

[0053] Fig.Figure 2 is a flowchart of an example process that can be performed by the ECU controller 116. The ECU controller 116 receives (at 202) a request from a requesting device to access a memory area in system memory 110. The request can be a read request or a write request and can include metadata that specifies different types of access. For example, the metadata can conform to one of the various communication protocols, such as the Advanced eXensible Interface (AXI) protocol from ARM Holdings, the Open Coherent Accelerator Processor Interface (OpenCAPI) protocol from the OpenCAPI Consortium, etc.

[0054] In some examples, the metadata may include a first indicator (e.g., a bit) which, when set to a first value, indicates privileged access, and when set to a second value different from the first, indicates non-privileged access. The metadata may also include a second indicator (e.g., a bit) which, when set to a first value, indicates command access, but when set to a different second value, indicates data access.

[0055] When the ECU controller 116 receives the request, it can determine from the request (at 204) whether the request is a read or a write request. Furthermore, the ECU controller 116 determines (at 206) from the metadata in the request whether the access is privileged or non-privileged and whether it is command or data access.

[0056] If the requested access is a command access, the ECU controller 116 (at 208) determines whether the command access is permitted based on the authorization table 118. In some examples, if the command access involves protected content in a specific memory area within memory areas 110-1 to 110-n, containing program code (e.g., kernel code or driver code), the ECU controller 116 can access the relevant entry in authorization table 118 to determine whether the requested command access is permitted, for example, based on the privileged access mode specified by the relevant entry in authorization table 118.For example, if the authorization information in the respective entry of authorization table 118 indicates a privileged access mode for executing the program code, then the control unit controller 116 allows the retrieval of the program code from the respective memory area for execution if the metadata in the request indicates privileged-level access (i.e., the requester is operating at the privileged level). However, the control unit controller 116 denies access to the program code from the respective memory area if the metadata in the request indicates unprivileged-level access (i.e., the requester is operating at a non-privileged level).

[0057] The provision at 208 further addresses another scenario in which the instruction access occurs to a memory area that lies outside the memory areas 110-1 to 110-n to be protected.

[0058] In some examples, if the command access is to a memory area that is outside the memory areas 110-1 to 110-n protected by the authorization table 118, the control unit controller 116 can simply forward the request to the memory controller 112 for processing.

[0059] In alternative examples, if the instruction access originates from a memory area outside of memory areas 110-1 to 110-n, which are protected by authorization table 118, the control unit controller 116 can prevent the retrieval of privileged program code from memory areas outside of memory areas 110-1 to 110-n for execution. In these latter examples, the execution of privileged program code from a memory area (from memory areas 110-1 to 110-n) designated for storing privileged program code by authorization table 118 is permitted. However, the execution of privileged program code from a memory area not designated for storing privileged program code by authorization table 118 is prohibited by the control unit controller 116.This can protect against malware or other attackers who might execute privileged program code to perform an unauthorized operation on computer system 100. More generally, in some examples, a request to retrieve program code from a memory area for execution is denied in response to the finding that the authorization information does not identify a privileged access level for that memory area.

[0060] If the requested access is data access (e.g., not a request to access privileged program code, but a request to access the kernel configuration, the syscall table, the kernel RO data, and / or the kernel data in Table 1), the ECU controller 116 (at 210) determines, based on authorization table 118, whether the requested data access is permitted. The determination at 210 can be based on the type of data access requested (e.g., read or write access, privileged access) and a comparison of the requested type of data access with the authorization information in a corresponding entry of authorization table 118.For example, if the authorization information in the respective entry of the authorization table 118 indicates that a write request is not permitted, then the control unit controller 116 can deny access if the request specifies a write access.

[0061] Fig. Figure 3 is a block diagram of a control unit 300, such as the protection control unit 114. The control unit 300 contains a controller 302 for performing various tasks, e.g., through the hardware processing circuitry of the controller 302 or through machine-readable instructions that can be executed on the controller 302.

[0062] The tasks include a memory area access request receiving task 304 to receive from a request device 306, which is separate from the control unit 300, a request to access a first memory area of ​​a memory 308 (e.g., the system memory 110 of Fig. 1) to receive.

[0063] The tasks also include an access authorization determination task 310 to determine, based on the occurrence of a system initialization event and according to authorization information (e.g. in the authorization table 118) that identifies the access authorizations for respective memory areas of memory 308, whether access to the content in the first memory area is allowed.

[0064] The memory areas of memory 308, for which the authorization information identifies the access permissions, contain data and program code, and where the request is a request to access the data or the program code.

[0065] In some examples, a lock indicator, when set to a specific value, prevents changes to the authorization information. The lock indicator is intended to be reset in response to a system restart where control unit 300 is used.

[0066] In some examples, an access permission for the first memory area, identified by the permission information, indicates that the first memory area contains program code. Control 302 allows the execution of the program code in the first memory area in response to the request.

[0067] In some examples, the controller 302 is supposed to deny permission to execute program code from a second memory area in memory 308, where the second memory area differs from the first memory area.

[0068] In some examples, the access permission identified by the permission information for the first memory area indicates command access to the first memory area and that access to the first memory area is at a privileged level.

[0069] Fig. Figure 4 is a block diagram of a System 400 according to some examples. The System 400 comprises a memory 402 and a request device 404 (e.g., the processor 102 from...). Fig. 1), which can access memory location 402.

[0070] The system 400 further comprises a controller 406 separate from the request device 404 (e.g. the control unit controller 116 from Fig. 1) The 406 controller is capable of performing various tasks.

[0071] The tasks include a memory area access receive task 408 to receive a request from the request device 404 to access a first memory area of ​​memory 402.

[0072] The tasks also include an access type determination task (410) to determine the type of access to the request based on the request and the metadata in the request.

[0073] The tasks also include an access authorization determination task 412 to determine, based on the occurrence of a system initialization event and according to authorization information that identifies access permissions for respective memory areas of memory 402, which contain different protected information, whether the type of access to the request for the content in the first memory area is permissible.

[0074] In some examples, the authorization information is to be populated by the kernel or the firmware in response to the writing of the protected information to the respective memory areas of memory 402.

[0075] In some examples, System 400 includes a register containing a lock indicator which, when set to a specified value, prevents the modification of at least some of the authorization information, and where program code (e.g., firmware 106 and kernel 105 of Fig. 1) After the lock indicator has been set to the specified state, it should allow the modification of at least part of the authorization information in response to the receipt of an authorization credential.

[0076] In some examples, System 400 includes a configuration register containing a mode indicator which, when set to a first value, indicates that the authorization information is to be written to a data structure according to a first mode in which the authorization information cannot be modified after initialization in the data structure, and which, when set to a second value, indicates that the authorization information is modifiable in response to receiving an authorization credential.

[0077] Fig. Figure 5 is a flowchart of a process 500, which is initiated by a control unit (e.g., the control unit controller 116). Fig. 1 or the controller 302 from Fig. 3) is carried out according to some examples.

[0078] The 500 process involves populating (at 502) a data structure with authorization information that identifies access permissions for respective memory areas of a memory, in response to the writing of protected information to those memory areas.

[0079] The 500 process involves setting (at 504) a lock indicator after populating the data structure with the authorization information, whereby the lock indicator, when set, prevents any changes to the authorization information.

[0080] Process 500 involves receiving (at 506) a request to access a first memory area from a requesting device separate from the controller.

[0081] The 500 process involves determining (at 508), based on the occurrence of a system initialization event and according to the authorization information, whether access to the content in the first memory area is allowed.

[0082] In some examples, the tasks discussed herein can be performed by machine-readable instructions stored in a non-transitory machine-readable or computer-readable storage medium, the machine-readable instructions, when executed, causing a system to perform the tasks. The storage medium may include any or a combination of the following: a semiconductor storage device, such as dynamic or static random-access memory (DRAM or SRAM), erasable and programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), and flash memory; a magnetic disk, such as a hard disk, floppy disk, and removable disk; another magnetic medium, including tape; an optical medium, such as a compact disc (CD) or a digital video disc (DVD); or some other type of storage device.Note that the instructions discussed above can be provided on a single computer- or machine-readable storage medium, or alternatively, on multiple computer- or machine-readable storage media distributed throughout a large system with potentially multiple nodes. Such computer- or machine-readable storage medium or media are considered part of an article (or manufactured item). An article or manufactured item can refer to any single manufactured component or multiple components. The storage medium or media can be located either in the machine on which the machine-readable instructions are executed or at a remote location from which machine-readable instructions can be downloaded over a network for execution.

Claims

[1] A control unit (300) comprising the following: a control unit memory (120) with a configuration register (124) for defining an operating mode of the control unit (300) and a lock register (122) for storing a lock indicator, wherein, immediately after authorization information has been set during a system initialization event, the lock indicator in the lock register (122) is set to a value indicating whether at least part of the authorization information can be changed or not, and set up a controller (302) to: to receive a request for access to a first memory area of ​​a memory (308) from a request device (306) separate from the control unit (300); in response to the request to access authorization information, which contains a multitude of entries corresponding to different memory areas (110-1 to 110-n) of the memory (308), each entry of the multitude of entries comprising a multitude of indicators, the indicators comprising: a first indicator that can assume an active value, representing an execution access mode in which instructions are retrieved from the respective memory area for execution, a second indicator that can assume an active value representing a privileged access mode in which access to the respective memory area is permitted if the requester has a privileged level; and a third indicator representing a read or write mode on a memory area; and Based on the occurrence of the system initialization event and according to the metadata of the request and the authorization information, to determine whether access to the content in the first storage area is allowed. [2] Control unit (300) according to claim 1, wherein the various memory areas (110-1 to 110-n) of the memory (308), which correspond to the plurality of entries of the authorization information, contain the first memory area which contains program code and a second memory area which contains data. [3] Control unit (300) according to claim 1 or 2, wherein the third indicator represents a read access mode which, when set to an active value, indicates that read access to a memory area is permitted, and wherein the plurality of indicators further comprises a fourth indicator which represents a write access mode which, when set to an active value, indicates that write access to a memory area is permitted. [4] Control unit (300) according to one of the preceding claims wherein the locking indicator, when set to a certain value, prevents the modification of at least part of the authorization information. [5] Control unit (300) according to one of the preceding claims, wherein the lock indicator is to be reset in response to a restart of a system in which the control unit (300) is provided. [6] Control unit (300) according to one of the preceding claims, wherein a first entry of the authorization information for the first memory area indicates that the first memory area contains program code, wherein according to the first entry the first indicator is set to an active value. [7] Control unit (300) according to one of the preceding claims, wherein the controller (302) is to allow the execution of the program code in the first memory area in response to the metadata of the request indicating a command access. [8] Control unit (300) according to one of the preceding claims, wherein the controller (302) is to deny permission to execute the program code from the first memory area in the memory (308) in response to the metadata of the request indicating a data access. [9] Control unit (300) according to one of the preceding claims, wherein in the first entry of the authorization information for the first memory area, the second indicator is set to an active value that indicates the privileged access mode, and wherein the controller (302) is configured to allow execution of the program code in the first memory area when the metadata of the request indicates privileged access. [10] Control unit (300) according to one of the preceding claims, wherein in the first entry of the authorization information, the plurality of indicators are set to prevent read access and write access in the first memory area containing the program code. [11] Control unit (300) according to one of the preceding claims, wherein the controller (302) serves to: Determining an access type for the first storage area based on the request metadata; and Determine whether access to the content in the first storage area is still permitted, based on the specific type of access. [12] Control unit (300) according to one of the preceding claims, wherein different entries of the plurality of entries of the authorization information can assume different combinations of values ​​of the plurality of indicators for respective different types of content in the respective different memory areas (110-1 to 110-n). [13] Control unit (300) according to one of the preceding claims, wherein authorization information includes an authorization table (118), and the plurality of entries include rows of the authorization table (118), and the plurality of indicators are represented by columns of the authorization table (118). [14] Control unit (300) according to one of the preceding claims, wherein the first indicator indicates that information in a memory area does not contain executable instructions when it is set to an inactive value, and wherein the second indicator, when set to an inactive value, indicates a non-privileged access mode in which a non-privileged requester is allowed access to a memory area. [15] A system (400) comprising the following: a control unit memory (120) with a configuration register (124) for defining an operating mode of the control unit (300) and a lock register (122) for storing a lock indicator, wherein, immediately after authorization information has been defined during a system initialization event, the lock indicator in the lock register (122) is set to a value indicating whether at least part of the authorization information can be changed or not; a request device (404); and a controller (406) separate from the request device (404) set up for: Received, from the request device (404), a request to access a first memory area of ​​a memory (402); Determining the type of access for the request based on the request and metadata in the request; in response to the request to access authorization information containing a multitude of entries corresponding to different storage areas (110-1 to 110-n), each entry of the multitude of entries comprising a multitude of indicators, the indicators encompassing: a first indicator that can assume an active value, representing an execution access mode in which instructions are retrieved from the respective memory area for execution, a second indicator that can assume an active value representing a privileged access mode in which access to the respective memory area is permitted if the requester has a privileged level; and a third indicator representing a read or write mode on a memory area; and Determine, based on the occurrence of the system initialization event and according to the metadata in the request and the authorization information, whether the type of access to the content in the first storage area is allowed. [16] System (400) according to claim 15, further comprising an OS kernel (105) or firmware (106) to populate the authorization information in response to the writing of the protected information to the respective different memory areas (110-1 to 110-n) of the memory (402). [17] System (400) according to claim 15 or 16, wherein the lock indicator, when set to a specified value, prevents modification of at least part of the authorization information, and wherein, after the lock indicator has been set to the specified state, program code is to allow modification of the authorization information in response to the receipt of an authorization credential. [18] System (400) according to any one of claims 15 to 17, wherein the configuration register (124) contains a mode indicator which, when set to a first value, indicates that the authorization information is to be written to a data structure in accordance with a first mode in which the authorization information cannot be modified after initialization in the data structure, and which, when set to a second value, indicates that the authorization information is modifiable in response to the receipt of an authorization credential. [19] A procedure (500) performed by a controller (302) in a system (400), comprising: in response to the writing of protected information (111-1 to 111-n) to respective memory areas (110-1 to 110-n) of a memory (308), populating a data structure with authorization information that identifies access permissions for the respective memory areas (110-1 to 110-n); wherein the authorization information comprises a multitude of entries corresponding to memory areas (110-1 to 110-n) of memory (308), wherein each entry of the multitude of entries comprises a multitude of indicators, the indicators comprising: a first indicator that can assume an active value, representing an execution access mode in which instructions are retrieved from the respective memory area for execution, a second indicator that can assume an active value representing a privileged access mode in which access to the respective memory area is permitted if the requester has a privileged level; and a third indicator representing a read or write mode on a memory area; and Setting a lock indicator value immediately after the data structure is populated with the authorization information during a system initialization event, where the lock indicator value indicates, when set, whether a change to at least part of the authorization information should be prevented or not; Receiving a request to access a first memory area of ​​the memory (308) from a request device (306) that is separate from the controller (302); and Determine, based on the occurrence of the system initialization event and according to the request metadata and authorization information, whether access to the content in the first storage area is allowed. [20] Method (500) according to claim 19, wherein each entry of the plurality of entries of the authorization information contains memory addressing information which specifies a memory area (110-1 to 110-n) of the memory (308).

Images