(19)
(11)EP 2 867 776 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
29.04.2020 Bulletin 2020/18

(21)Application number: 13733436.3

(22)Date of filing:  26.06.2013
(51)International Patent Classification (IPC): 
G06F 12/02(2006.01)
(86)International application number:
PCT/GB2013/051694
(87)International publication number:
WO 2014/001803 (03.01.2014 Gazette  2014/01)

(54)

MEMORY PROTECTION

SPEICHERSCHUTZ

PROTECTION DE MÉMOIRE


(84)Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

(30)Priority: 27.06.2012 GB 201211422

(43)Date of publication of application:
06.05.2015 Bulletin 2015/19

(60)Divisional application:
20163176.9

(73)Proprietor: Nordic Semiconductor ASA
7004 Trondheim (NO)

(72)Inventors:
  • BERNTSEN, Frank
    7089 Heimdal (NO)
  • MARVIK, Ola
    7004 Trondheim (NO)
  • OLSEN, Lasse
    7042 Trondheim (NO)
  • STAPLETON, Joel David
    7004 Trondheim (NO)

(74)Representative: Dehns 
St. Bride's House 10 Salisbury Square
London EC4Y 8JD
London EC4Y 8JD (GB)


(56)References cited: : 
US-A- 5 564 030
US-A1- 2009 210 644
US-A- 6 088 262
US-A1- 2010 106 926
  
      
    Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


    Description


    [0001] This invention relates to memory protection in an integrated-circuit device.

    [0002] A microcontroller or system-on-chip device typically stores executable code in memory. It might have stored in its memory certain code (e.g. an operating system or firmware module) which is written by the chip manufacturer and other code (e.g. a software application) which is written by a customer or user. These will often be stored in non-volatile memory, such as EEPROM or flash.

    [0003] It can be desirable to prevent the user code or an external debugging interface from being able to read or overwrite the code written by the chip manufacturer, while not restricting memory access for the chip manufacturer's code. This may be because the chip manufacturer's code contains trade secrets which it does not want any other party to be able to access. It may also help prevent the inadvertent corruption of the chip manufacturer's code by bugs in the user's code.

    [0004] US 8,051,263 (Atmel Corp) describes a memory protection unit that selectively grants or denies requests for memory access according to a set of configurable memory protection attributes for a particular region of memory. Access to the region may depend on whether an execution unit is operating in a privileged or non-privileged mode of operation.

    [0005] Such a mechanism could be used to protect a region of memory containing sensitive code from being read by user code, if the user code were executed in a non-privileged mode.

    [0006] However, it may be possible for a malicious attacker to cause the processor to read the sensitive code from memory while in a privileged mode of operation, and then to output the contents to the attacker. Moreover, not all processors support privileged and non-privileged modes of execution.

    [0007] US 6,088,262 (Seiko Epson Corporation) discloses a microcomputer in which program data, stored in a memory cell array of a non-volatile memory block, can be protected from being read from outside the microcomputer by setting read protection for the memory cell array. In normal operation, read-out of data by the CPU is permitted.

    [0008] US 2009/0210644 (Batifoulier et al.) describes a microcontroller system having the features of the pre-characterising portion of claim 1.

    [0009] The present invention takes a different approach.

    [0010] From a first aspect, the invention provides an integrated-circuit device as claimed in claim 1.

    [0011] From a second aspect, the invention provides a method of controlling memory access on an integrated-circuit device as claimed in claim 13.

    [0012] Thus it will be seen by those skilled in the art that, in accordance with the invention, the location of code being executed by the processor when it requests read access to a protected region of memory is used to determine whether to allow the request. Requests originating from code stored outside the protected region can be denied (if the read protection flag is appropriately set), while requests from code stored within the protected region itself are allowed. For many processor architectures, such as those from ARM (RTM), it is important that code is able to issue data read requests to a region in which the code itself is stored, so that the processor can access constants embedded in the code.

    [0013] The protection is enforced by the memory protection logic, which is preferably arranged to function independently of the processor. The memory protection logic preferably comprises hardware logic that is separate from the processor. It can thus be less susceptible to circumvention by malicious software code than protection which relies on privilege modes within the processor.

    [0014] The chip manufacturer can conveniently store its code within the protected region and set the read protection flag in order to prevent a customer's code from reading the chip manufacturer's code, while preserving unrestricted memory access for its own code. Other sensitive information, such as configuration data, may also be stored in the protected region.

    [0015] Furthermore, the protection flag cannot be rewritten without first erasing any data stored in the protected region of the non-volatile memory. Sensitive executable code stored in the protected region thus cannot be read simply by resetting the read protection flag for the non-volatile memory.

    [0016] The memory protection logic is preferably configured to allow read requests for addresses in the protected region if the read protection flag for the protected region is not set. This may be useful during initial development stages of the device and its software. Similarly, the memory protection logic is preferably configured to allow write requests for addresses in the protected region if a write protection flag is not set.

    [0017] The memory protection logic is preferably configured to deny read requests for addresses in the protected region if the read protection flag for the protected region is set, unless the processor issued the read requests while executing code stored in the protected region (in which case, they are allowed). Such preferred embodiments have only one aforesaid access condition. However, other embodiments may nevertheless provide for multiple access conditions, any of which can effectively override the read protection flag; for example, a device might conceivably allow reading of the protected region if the processor issued the read request while executing a manufacturer's boot-loader program stored in ROM.

    [0018] The memory protection logic can further be configured similarly to determine the state of a write protection flag for the protected region and to deny write requests for addresses in the protected region if the write protection flag for the protected region is set, unless the processor issued the write requests while executing code stored in the protected region. The read protection flag may act as the write protection flag also, or these may be two separate flags.

    [0019] In one set of preferred embodiments, this memory is non-volatile memory, such as flash. The processor may fetch code directly from the non-volatile memory for execution, or, in some embodiments, at least some of the code may be cached (e.g. in volatile memory). If the device comprises such a cache, it will be appreciated that references herein to executing code stored in the protected region encompass executing a cached copy of such code.

    [0020] In other embodiments, the memory may be volatile memory, such as a portion of RAM reserved for executable code, and the protected region is a region of volatile memory. Executable code may be copied to such memory when the device powers on (e.g. from ROM or flash). Alternatively, sections of code or individual instructions may be copied to a protected region of volatile memory as needed, when the device is in use.

    [0021] The processor and memory may be connected by one or more buses. The memory protection logic may also be connected to at least one of these buses. The memory protection logic is preferably configured to monitor all accesses to the memory (e.g. all read, write and instruction-fetch operations).

    [0022] The memory protection logic is configured to determine whether the processor issued the read request while executing code stored in the protected region of memory by determining whether the address of an instruction-fetch operation immediately preceding the memory access request was within the protected region. The memory protection logic may be configured to set a register on every instruction-fetch operation in accordance with whether the address of the fetched instruction is in the protected region or not. The register may comprise a binary flag which is set in accordance with whether the address of the instruction fetch is in the protected region or not.

    [0023] The memory protection logic may be configured to use transaction-type information on a memory bus to identify an instruction-fetch operation (e.g. to distinguish it from a read request). Alternatively, it may be configured to identify an instruction-fetch operation by determining the state of a processor pin, or by determining the identity of bus conveying the fetch instruction (e.g. in devices having separate data-fetch and instruction-fetch buses). When using a Cortex-MO processor from ARM (RTM), the memory protection logic can use the HPROT[0] (Data/Opcode) signal from the Cortex-MO to distinguish between an opcode fetch and data access.

    [0024] The protected region may comprise a plurality of discrete areas or address ranges. However, it is preferably defined by a single, continuous address range, which can simplify the implementation logic. In some preferred embodiments, the protected region is variable and is defined by one or more addresses stored on the device, e.g. stored as configuration data in non-volatile memory.

    [0025] The protected region may extend between a predetermined constant address and a variable point within the memory address range. The constant address may conveniently be a base or end address for the memory, or even for the whole memory address space for the device; e.g. zero (0x0000 0000). Thus the region can be specified compactly by a single value stored on the device, being the address defining the variable end of the protected region within the memory.

    [0026] The memory protection unit can then be configured to determine whether the read request is for an address in the protected region of the memory by determining whether or not the address is between the predetermined constant address and the variable memory address. This operation can be implemented using relatively few logic gates.

    [0027] In embodiments in which the aforementioned protected memory region is in non-volatile memory, the device may also comprise volatile memory, such as RAM. The memory protection logic may additionally be configured to deny read requests for addresses in a protected region of the volatile memory if a read protection flag for the protected region of the volatile memory is set, unless the processor issued the read requests while executing code stored in the protected region of the non-volatile memory. In this way, a region of protected RAM may be used by code stored in the protected region of the non-volatile memory (e.g. for heap storage) while being protected from read access by code stored outside the protected region. This can protect sensitive information that code written by the chip manufacturer may store in RAM.

    [0028] Similarly, the memory protection logic may be configured to deny write requests for addresses in a protected region of the volatile memory if a write protection flag for the protected region of the volatile memory is set, unless the processor issued the write requests while executing code stored in the protected region of the non-volatile memory. In this way, customer code stored in non-volatile memory outside the protected region can be prevented from inadvertently or maliciously changing or overwriting volatile data belonging to code in the protected region of the non-volatile memory.

    [0029] The non-volatile memory protection flags may act as the volatile memory protection flags also, or the volatile memory flags may comprise one or more separate flags.

    [0030] In any of the foregoing embodiments, the device may comprise an interface (e.g. one or more pins) for allowing memory access by an external debugger or software loader. In preferred embodiments of the present invention, the memory protection logic is arranged to deny read requests received via such an interface for addresses in some or all protected regions of volatile or non-volatile memory if a debugging protection flag for the region is set. Protection may similarly be provided for write access to a protected region of volatile or non-volatile memory and/or for instruction fetches from a protected region.. The memory protection logic may be configured to identify memory access requests as originating from a debugging interface by determining when a debugger is acting as a bus master for a memory bus in the device. When the processor is a Cortex-MO from ARM (RTM), the processor may use the HMASTER signal from the Cortex-MO to distinguish between processor core and debugger transactions.

    [0031] The memory protection logic may further be configured to determine the state of a read protection flag for a user region of memory for executable code. This user region may comprise part or all of the memory adjacent to, but excluding, the protected code region in the address space. The memory protection logic may by configured to deny read and/or write requests for addresses in the user region received from a debugging interface if the read protection flag for the user region is set. In this way, a customer or other user can protect his user application code from unauthorised access by a third-party; e.g. for reasons of confidentiality.

    [0032] In some embodiments, the device comprises integrated radio communication logic, such as a radio transmitter and/or receiver (i.e. a radio-on-a-chip). A firmware module comprising code implementing a radio protocol stack may be stored in the protected region of code memory. A software application which interfaces with the firmware module may be stored outside the protected region.

    [0033] Embodiments of the invention may be particularly suited to devices that do not have a traditional operating system, but which allow a user to develop native code for direct execution on the processor. This is because such devices cannot rely on an operating system to control memory access and to protect any confidential software libraries or modules which the device manufacturer may have installed in the device.

    [0034] In any embodiments of the invention, the read and/or write protection flags are preferably stored in non-volatile memory. In use, the flags may of course be cached in a register or in RAM. A protection flag may just be one element in a larger set of configuration settings. It may be encoded in any suitable manner. In some embodiments each such protection flag is stored as a binary flag or bit field.

    [0035] Additional protection flags may be stored in the protection-configuration region of non-volatile memory.

    [0036] Preferably the non-volatile memory control logic operates independently of the processor. It preferably comprises distinct logic gates, separate from the processor. In this way, a malicious or careless programmer cannot execute code on the processor that bypasses the non-volatile memory control logic. The memory protection logic is similarly independent of the processor in preferred embodiments.

    [0037] US 6952778 describes a microcontroller that provides read and/or write protection for memory blocks in an embedded memory according to a set of rules. These rules assign respective security levels to the memory blocks and are stored in a supervisory non-volatile memory. Once it has initially been programmed in accordance with an end user's requirements, the security level for a block can only be increased unless the supervisor non-volatile memory is erased and the microcontroller re-initialized. This results in the user-defined default security levels being restored.

    [0038] However such an approach relies on the successful restoration of the default security levels in order for the memory blocks to be adequately protected. If an attacker were able to interfere with the process of re-initializing the microcontroller, the contents of the memory might be left unprotected and readable by the attacker.

    [0039] Preferred embodiments of the present invention, by contrast, use dedicated non-volatile memory control logic and memory protection logic to ensure that the protection configuration data can only be reset if any sensitive information has first been erased from the device.

    [0040] The non-volatile memory control logic may be configured so that the only mechanism provided by the non-volatile memory control logic for erasing the protection-configuration region is an instruction that erases both the protectable region and the protection-configuration region. This may be an instruction to erase all the non-volatile memory in the device.

    [0041] If the protection-configuration region and the protectable region comprise different pages or erasable blocks of memory, the non-volatile memory control logic is preferably configured to erase all pages or blocks forming the protectable region before erasing any page or block forming part of the protection-configuration region. In this way, if the erase operation is interrupted before completing, the protection configuration data will still be present if the protectable region has not yet been fully erased, thereby continuing to provide protection.

    [0042] The memory protection logic may be configured such that, when the protection-configuration region is in an erased state, access to the protectable region is in the highest of an ordered set of restriction levels. This can provide additional security by restricting access to the protectable region by default, e.g. in case a user omits to set new configuration data after an erase.

    [0043] By allowing writing to the protection-configuration region when it is in an erased state, the protection configuration information can be set during manufacturing or commissioning, and during any subsequent reprogramming of the device.

    [0044] The non-volatile memory control logic is preferably arranged to receive an instruction to write to a portion of the protection-configuration region and, in response, to check that the portion is in an erased state before allowing the write. It may do this by reading the portion and determining that it is in a natural erased state for the type of non-volatile memory. For example, flash memory contains a binary "1" in every bit after a page has been erased. The memory control logic may therefore check that every bit of the portion is a "1" before allowing the write operation. Other memory types may of course read "0" or have some other natural erased state.

    [0045] Alternatively, regions of the non-volatile memory may contain erased state flags that are reset when the region is erased but are set by the non-volatile memory control logic when a first write operation is performed into that region. In this case, the non-volatile memory control logic may check one or more erased state flags before allowing a write operation to a portion of the protection-configuration region.

    [0046] The memory-protection configuration region may store one or more values that define the protectable region of non-volatile memory and/or that define a protected region of volatile memory as previously described. In this way, an attacker cannot change the definition of the protected region(s) without first destroying its contents.

    [0047] Optional or preferred features of one aspect or embodiment described herein may, wherever appropriate, be applied to any other aspect or embodiment.

    [0048] Certain preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

    Figure 1 is a schematic drawing of a microcontroller embodying the invention;

    Figure 2 is a schematic drawing showing major software components within the microcontroller architecture; and

    Figure 3 is a schematic memory map for the microcontroller.



    [0049] Figure 1 shows an integrated-circuit microcontroller 1 or radio-on-a-chip which comprises clock logic 3, which may include a resistor-capacitor oscillator and/or may receive an input from an off-chip crystal oscillator (not shown), power management circuitry 5, a processor 7 (e.g. an ARM (RTM) Cortex-MO), a memory protection unit 9, RAM 11, a flash memory controller 20, flash memory 13, radio communication logic 17, one or more peripherals 15, and input/output circuitry 19.

    [0050] These components are interconnected using suitable lines and/or buses (not shown). The microcontroller 1 may use a Harvard architecture or a von Neumann architecture. The memory protection unit 9 is arranged to intercept all memory access instructions from the processor 7 to the RAM 11 and to the flash memory controller 20.

    [0051] The microcontroller 1 also has a debugging interface 18 which may be used for loading data into the flash memory 13 and for debugging the processor 7. It does not have direct access to the RAM 11 and flash 13, but instead has to access these memories via the memory protection unit 9 and flash memory controller 20.

    [0052] In use, the microcontroller 1 can be connected to a number of external components such as a power supply, radio antenna, crystal oscillator, sensors, output devices, etc.

    [0053] Figure 2 shows software components that may be installed on the microcontroller 1. Interfacing with the microcontroller 1 hardware is an optional hardware abstraction layer 21, such as the ARM (RTM) Cortex Microcontroller Software Interface Standard. Above this sits a firmware module 23 and a separate software application 27.

    [0054] The firmware module 23 is a binary application comprising a number of embedded software blocks. A radio protocol block 31 implements one or more wireless protocol stacks. A radio event manager 33 provides access scheduling for the radio communication logic 17 and event multiplexing. A library 35 provides shared hardware resource management and functions such as random number generation, configuring interrupts and priority, power management (e.g. for enabling and disabling peripherals), encryption functions, etc. A firmware manager 37 supports enabling and disabling the firmware module, and enabling and disabling the wireless protocol stack.

    [0055] The firmware module 23 need not be a full operating system, in that it need not necessarily provide support for multi-threading, memory allocation, etc.

    [0056] An application interface (API) 29 for the firmware module 23 allows the software application 27 to invoke functions in the firmware module 23. It may be implemented entirely using system calls. When using an ARM (RTM) processor, each API function prototype is mapped to a firmware function via an associated supervisor call (SVC) number at compile time. This mapping can be provided to the developer of the software application 27 to allow the functions to be called correctly.

    [0057] The firmware module 23 can communicate events to the software application 27 as software interrupts, the content of which is buffered until read (polled) by the software application 27. The reading is done through an API call (e.g. event_get()).

    [0058] Figure 3 shows how the RAM 11 and flash 13 are shared between the firmware module 23 and the software application 27. The flash 13 is assigned addresses from zero (0x0000 0000) to SizeOfProgMem for storing executable program code.

    [0059] Another area of flash 13, which may be on its own flash page, extends from MemConfigStart to MemConfigEnd and is used for storing configuration data for use by the memory protection unit 9. In one set of embodiments, this page extends from 0x1000 0000 to 0x1000 07ff, but, as with all the address values mentioned herein, these values may depend on the particular processor architecture being used in any given embodiment.

    [0060] The RAM 11 is assigned addresses from 0x2000 0000 upwards to 0x2000 0000 + SizeOfRAM.

    [0061] The program area of the flash 13 comprises two distinct regions either side of address CLENR0 (code length region 0). Region 0, between zero and CLENR0, is where the firmware module 23 is loaded. A firmware interrupt vector table is stored at address zero. Region 1, extending upwards from CLENR0 to SizeOfProgMem, is where the software application 27 is loaded. It too can have an interrupt vector table, at address CLENR0.

    [0062] The RAM 11 similarly has a Region 0, from the base address 0x2000 000 to RLENR0, and a Region 1, extended upwards from RLENR0. RAM Region 0 provides heap storage for the firmware module 23 while RAM Region 1 provides heap storage for the software application 27. A call stack is shared between the firmware module 23 and the software application 27 and grows downwards from (0x2000 0000 + SizeOfRAM). The memory allocated to the call stack must be big enough for the needs of both the software application 27 and the firmware module 23.

    [0063] The values of CLENR0 and RLENR0 are stored in the memory-protection configuration area of the flash memory 13.

    [0064] On power up, relevant data stored in the memory protection configuration area of flash 13 is copied to memory protection configuration registers accessible to the memory protection logic 9. These registers are writeable only from a hardware state machine that executes only during power on of the microcontroller 1, such that the only way of changing the contents of these registers is to change the data in the memory protection configuration area of the flash 13.

    [0065] The memory protection logic 9 is arranged to intercept all memory access requests (e.g. data fetch or instruction fetch operations) from the processor 7 to the flash memory 13 and the RAM 11. It can identify an instruction-fetch operation from a "transaction type" on the memory bus. For every instruction fetch that the processor 7 makes from the flash memory 13, the memory protection logic 9 updates a single-bit flag in a "firmware region" register with a "1" if the address of the fetched instruction is less than CLENR0 and with a "0" if the address is greater than or equal to CLENR0.

    [0066] For every data access request, the memory protection logic 9 determines whether the source of the access request was from the firmware module 23 or elsewhere by checking the value of the "firmware region" register. It can be configured to detect if the source of the request is the debugger interface 18, or a direct-memory access (DMA) unit, by determining the identity of the active memory bus master. It also accesses the memory protection configuration registers to determine whether to allow or deny the access request based on the state of the "firmware region" register and the identity of the bus master.

    [0067] In some preferred embodiments, the software application 27 is denied read and write access to flash Region 0 and to RAM Region 0. This protects confidentiality for the firmware module 23 and can prevent inadvertent or malicious writing by the software application 27 to memory locations allocated to the firmware module 23, thereby increasing robustness and security. The software application flash Region 1 may also be protected from read access, e.g. to protect against read back via the external debugging interface 18.

    [0068] Figure 4 shows a decision table that the microcontroller 1 might implement for protecting the flash memory 13 from unauthorised access. Alternative implementations are, of course, possible.

    [0069] Two binary flags are stored in the memory-protection configuration region of the flash memory 13 (and are copied to registers on boot up). The first, when set, prevents data read and write access to all of the program flash via the debugging interface 18. The second, when set, prevents data read and write access to the Region 0 flash memory by anything other than code executing from Region 0 itself. Execution access (i.e. instruction fetches) by the processor 7 is still allowed, even when data read access is denied.

    [0070] If an attacker were able to change the data stored in the memory-protection configuration area of the flash memory 13, the protection mechanisms could be bypassed. However, the flash memory controller 20 prevents writing to the memory-protection configuration area unless it is in an erased state. Furthermore, the flash memory controller 20 prevents erasing of the memory-protection configuration area unless Regions 0 & 1 of the flash memory 13 have been erased first. It uses digital logic implementing a finite state machine to enforce these conditions.

    [0071] If the flash memory controller 20 receives an instruction to write a word to an address in the memory-protection configuration area, it will first read the existing contents at that address and will only allow the write if the existing contents are all binary "1"s, indicating that this address has not been written to since an erase of the memory-protection configuration area flash memory. If the check fails, it will deny the write and may raise an exception with the processor 7.

    [0072] If the flash memory controller 20 receives an instruction to erase the entire flash memory 13, it will respond by erasing the contents of flash Regions 0 and 1 first, before erasing the memory-protection configuration area. For this reasons, the memory-protection configuration area is preferably stored in its own erasable flash page, separate from any program areas of the flash memory 13.

    [0073] The flash memory controller 20 will deny any instruction to erase just the memory-protection configuration area.

    [0074] The skilled person will appreciate microcontroller 1 may also be configured to prevent code executing other than in Region 0 of the flash memory 13 from accessing important features, such as registers related to low-level functions of the radio communication logic 17, the power control logic 5, a direct-memory access (DMA) controller, or interrupt registers.


    Claims

    1. An integrated-circuit device (1) comprising a processor (7), non-volatile memory (13) for storing executable code, non-volatile memory control logic (20), and memory protection logic (9), wherein the memory protection logic is configured to:

    detect a memory read request by the processor;

    determine whether the read request is for an address in a protected region of the memory; and

    determine whether the processor issued the read request while executing code stored in the protected region of the memory;

    characterised in that the memory protection logic is further configured to:

    determine whether the processor issued the read request while executing code stored in the protected region of memory by determining whether the address of an instruction-fetch operation, immediately preceding the memory read request, was within the protected region;

    determine the state of a binary read protection flag for the protected region of the memory, the read protection flag being stored in a protection-configuration region of the non-volatile memory; and

    deny read requests for addresses in the protected region if the binary read protection flag for the protected region is set, unless at least one of one or more access conditions is met, wherein one of said access conditions is that the processor issued the read requests while executing code stored in the protected region,

    wherein the non-volatile memory control logic is arranged to prevent writing to any portion of the protection-configuration region unless that portion is in an erased state and to allow the protection configuration region to be erased only if a protected region of the non-volatile memory is in an erased state.
     
    2. A device (1) as claimed in claim 1, wherein the memory protection logic (9) comprises hardware logic that is separate from the processor (7).
     
    3. A device (1) as claimed in claim 1 or 2, wherein the memory protection logic (9) is configured to allow read requests for addresses in the protected region if the binary read protection flag for the protected region is not set.
     
    4. A device (1) as claimed in any preceding claim, wherein the memory protection logic (9) is configured to deny read requests for addresses in the protected region if the binary read protection flag for the protected region is set, unless the processor (7) issued the read requests while executing code stored in the protected region.
     
    5. A device (1) as claimed in any preceding claim, wherein the memory protection logic (9) is further configured to determine the state of a binary write protection flag for the protected region and to deny write requests for addresses in the protected region if the binary write protection flag for the protected region is set, unless the processor (7) issued the write requests while executing code stored in the protected region, the binary write protection flag also being stored in the protection-configuration region.
     
    6. A device (1) as claimed in any preceding claim, wherein the memory protection logic (9) is configured to monitor all accesses to the non-volatile memory (13).
     
    7. A device (1) as claimed in any preceding claim, wherein the memory protection logic (9) is configured to set a register on every instruction-fetch operation in accordance with whether the address of the fetched instruction is in the protected region or not.
     
    8. A device (1) as claimed in any preceding claim, wherein the protected region is variable and is defined by one or more addresses stored on the device.
     
    9. A device (1) as claimed in any preceding claim, wherein the protected region of the memory (13) extends between a predetermined constant address and a variable point within the memory address range, and the memory protection logic (9) is configured to determine whether the read request is for an address in the protected region by determining whether the address is between the predetermined constant address and the variable memory address.
     
    10. A device (1) as claimed in any preceding claim, wherein the device further comprises volatile memory (11), and wherein the memory protection logic (9) is further configured to deny read requests for addresses in a protected region of the volatile memory if a read protection flag for the protected region of the volatile memory is set, unless the processor (7) issued the read requests while executing code stored in the protected region of the non-volatile memory (13).
     
    11. A device (1) as claimed in any preceding claim, comprising an interface for allowing memory access by an external debugger or software loader, wherein the memory protection logic (9) is arranged to deny read requests received via said interface for addresses in one or more protected regions of volatile or non-volatile memory (11, 13) if a debugging protection flag for the region is set.
     
    12. A device (1) as claimed in any preceding claim, comprising integrated radio communication logic (17), wherein a firmware module (23) comprising code implementing a radio protocol stack is stored in the protected region of memory (13) and wherein a software application (25) which interfaces with the firmware module is stored in the memory outside the protected region.
     
    13. A method of controlling memory access on an integrated-circuit device (1) comprising a processor (7), non-volatile memory (13) for storing executable code, and non-volatile memory control logic (20), the method comprising:

    detecting a memory read request by the processor; and

    determining that the read request is for an address in a protected region of the memory,

    characterised by:

    determining whether the processor issued the read request while executing code stored in the protected region of memory by determining whether the address of an instruction-fetch operation, immediately preceding the memory read request, was within the protected region;

    determining that a binary read protection flag for a protected region of the memory is set, the read protection flag being stored in a protection-configuration region of the non-volatile memory, wherein the non-volatile memory control logic is arranged to prevent writing to any portion of the protection-configuration region unless that portion is in an erased state and to allow the protection configuration region to be erased only if the protected region of the non-volatile memory is in an erased state; and

    determining that the processor issued the read request while executing code stored in the protected region of the memory, and therefore allowing the read request.


     


    Ansprüche

    1. Integrierte Schaltungsvorrichtung (1), umfassend einen Prozessor (7), einen nicht flüchtigen Speicher (13) zum Speichern von ausführbarem Code, eine nicht flüchtige Speichersteuerlogik (20) und eine Speicherschutzlogik (9), wobei die Speicherschutzlogik konfiguriert ist zum:

    Detektieren einer Speicherleseanfrage durch den Prozessor;

    Bestimmen, ob die Leseanfrage für eine Adresse in einer geschützten Region des Speichers ist; und

    Bestimmen, ob der Prozessor die Leseanfrage abgegeben hat, während er Code ausführte, der in der geschützten Region des Speichers gespeichert war;

    dadurch gekennzeichnet, dass die Speicherschutzlogik weiterhin konfiguriert ist zum:

    Bestimmen, ob der Prozessor die Leseanfrage abgegeben hat, während er den Code ausführte, der in der geschützten Region des Speichers gespeichert war, indem bestimmt wird, ob die Adresse einer Anweisungsabrufoperation, die der Speicherleseanfrage unmittelbar vorherging, innerhalb der geschützten Region lag;

    Bestimmen des Zustands eines binären Leseschutz-Flags für die geschützte Region des Speichers, wobei das Leseschutz-Flag in einer Schutzkonfigurationsregion des nicht flüchtigen Speichers gespeichert ist; und

    Verweigern von Leseanfragen für Adressen in der geschützten Region, falls das binäre Leseschutz-Flag für die geschützte Region gesetzt ist, es sei denn, mindestens eine von einer oder mehreren Zugriffsbedingungen ist erfüllt, wobei eine der Zugriffsbedingungen darin besteht, dass der Prozessor die Leseanfragen abgab, während er Code ausführte, der in der geschützten Region gespeichert war,

    wobei die nicht flüchtige Speichersteuerlogik eingerichtet ist, um das Schreiben in einen beliebigen Abschnitt der Schutzkonfigurationsregion zu verhindern, es sei denn, dieser Abschnitt befindet sich in einem gelöschten Zustand, und um das Löschen der Schutzkonfigurationsregion nur zu erlauben, falls sich eine geschützte Region des nicht flüchtigen Speichers in einem gelöschten Zustand befindet.


     
    2. Vorrichtung (1) nach Anspruch 1, wobei die Speicherschutzlogik (9) eine Hardware-Logik umfasst, die von dem Prozessor (7) getrennt ist.
     
    3. Vorrichtung (1) nach Anspruch 1 oder 2, wobei die Speicherschutzlogik (9) konfiguriert ist, um Leseanfragen für Adressen in der geschützten Region zu erlauben, falls das binäre Leseschutz-Flag für die geschützte Region nicht gesetzt ist.
     
    4. Vorrichtung (1) nach einem der vorstehendvorstehenden Ansprüche, wobei die Speicherschutzlogik (9) konfiguriert ist, um Leseanfragen für Adressen in der geschützten Region zu verweigern, falls das binäre Leseschutz-Flag für die geschützte Region gesetzt ist, es sein denn, der Prozessor (7) gab die Leseanfragen ab, während er Code ausführte, der in der geschützten Region gespeichert war.
     
    5. Vorrichtung (1) nach einem der vorstehenden Ansprüche, wobei die Speicherschutzlogik (9) weiterhin konfiguriert ist, um den Zustand eines binären Schreibschutz-Flags für die geschützte Region zu bestimmen und Schreibanfragen für Adressen in der geschützten Region zu verweigern, falls das binäre Schreibschutz-Flag für die geschützte Region gesetzt ist, es sein denn, der Prozessor (7) gab die Schreibanfragen ab, während er Code ausführte, der in der geschützten Region gespeichert war, wobei das binäre Schreibschutz-Flag ebenfalls in der Schutzkonfigurationsregion gespeichert ist.
     
    6. Vorrichtung (1) nach einem der vorstehenden Ansprüche, wobei die Speicherschutzlogik (9) konfiguriert ist, um alle Zugriffe auf den nicht flüchtigen Speicher (13) zu überwachen.
     
    7. Vorrichtung (1) nach einem der vorstehenden Ansprüche, wobei die Speicherschutzlogik (9) konfiguriert ist, um ein Register bei jeder Anweisungsabrufoperation in Abhängigkeit davon zu setzen, ob die Adresse der abgerufenen Anweisung in der geschützten Region liegt oder nicht.
     
    8. Vorrichtung (1) nach einem der vorstehenden Ansprüche, wobei die geschützte Region variabel ist und durch eine oder mehrere Adressen, die in der Vorrichtung gespeichert sind, definiert ist.
     
    9. Vorrichtung (1) nach einem der vorstehenden Ansprüche, wobei sich die geschützte Region des Speichers (13) zwischen einer vorbestimmten konstanten Adresse und einem variablen Punkt innerhalb des Speicheradressenbereichs erstreckt und die Speicherschutzlogik (9) konfiguriert ist, um zu bestimmen, ob die Leseanfrage für eine Adresse in der geschützten Region ist, indem sie bestimmt, ob die Adresse zwischen der vorbestimmten konstanten Adresse und der variablen Speicheradresse liegt.
     
    10. Vorrichtung (1) nach einem der vorstehenden Ansprüche, wobei die Vorrichtung weiterhin einen flüchtigen Speicher (11) umfasst, und wobei die Speicherschutzlogik (9) weiterhin konfiguriert ist, um Leseanfragen für Adressen in einer geschützten Region des flüchtigen Speichers zu verweigern, falls ein Leseschutz-Flag für die geschützte Region des flüchtigen Speichers gesetzt ist, es sein denn, der Prozessor (7) gab die Leseanfragen ab, während er Code ausführte, der in der geschützten Region des nicht flüchtigen Speichers (13) gespeichert war.
     
    11. Vorrichtung (1) nach einem der vorstehenden Ansprüche, umfassend eine Schnittstelle, um einen Speicherzugriff durch ein externes Fehlersuchprogramm oder ein Software-Ladeprogramm zu erlauben, wobei die Speicherschutzlogik (9) eingerichtet ist, um Leseanfragen zu verweigern, die über die Schnittstelle für Adressen in einer oder mehreren geschützten Regionen des flüchtigen oder nicht flüchtigen Speichers (11, 13) empfangen werden, falls ein Fehlersuchschutz-Flag für die Region gesetzt ist.
     
    12. Vorrichtung (1) nach einem der vorstehenden Ansprüche, umfassend eine integrierte Funkkommunikationslogik (17), wobei ein Firmware-Modul (23), das Code umfasst, der einen Funkprotokollstapel umsetzt, in der geschützten Region des Speichers (13) gespeichert ist, und wobei eine Software-Anwendung (25), die eine Schnittstelle mit dem Firmware-Modul bildet, in dem Speicher außerhalb der geschützten Region gespeichert ist.
     
    13. Verfahren zum Steuern eines Speicherzugriffs auf eine integrierte Schaltungsvorrichtung (1), die einen Prozessor (7), einen nicht flüchtigen Speicher (13) zum Speichern von ausführbarem Code und eine nicht flüchtige Speichersteuerlogik (20) umfasst, wobei das Verfahren umfasst:

    Detektieren einer Speicherleseanfrage durch den Prozessor; und

    Bestimmen, dass die Leseanfrage für eine Adresse in einer geschützten Region des Speichers ist,

    gekennzeichnet durch:

    Bestimmen, ob der Prozessor die Leseanfrage abgab, während er Code ausführte, der in der geschützten Region des Speichers gespeichert war, indem bestimmt wird, ob die Adresse einer Anweisungsabrufoperation, die der Speicherleseanfrage unmittelbar vorherging, in der geschützten Region lag;

    Bestimmen, dass ein binäres Leseschutz-Flag für eine geschützte Region des Speichers gesetzt ist, wobei das Leseschutz-Flag in einer Schutzkonfigurationsregion des nicht flüchtigen Speichers gespeichert ist, wobei die nicht flüchtige Speichersteuerlogik eingerichtet ist, um das Schreiben in einen beliebigen Abschnitt der Schutzkonfigurationsregion zu verhindern, es sei denn, dieser Abschnitt befindet sich in einem gelöschten Zustand, und um das Löschen der Schutzkonfigurationsregion nur zu erlauben, falls sich die geschützte Region des nicht flüchtigen Speichers in einem gelöschten Zustand befindet; und

    Bestimmen, dass der Prozessor die Leseanfrage abgab, während er Code ausführte, der in der geschützten Region des Speichers gespeichert war, und daher Erlauben der Leseanfrage.


     


    Revendications

    1. Dispositif à circuit intégré (1) comprenant un processeur (7), une mémoire non volatile (13) pour stocker un code exécutable, une logique de commande de mémoire non volatile (20) et une logique de protection de mémoire (9), dans lequel la logique de protection de mémoire est configurée pour :

    détecter une demande de lecture de mémoire par le processeur ;

    déterminer si la demande de lecture est pour une adresse dans une région protégée de la mémoire ; et

    déterminer si le processeur a émis la demande de lecture tout en exécutant un code stocké dans la région protégée de la mémoire ;

    caractérisé en ce que la logique de protection de mémoire est en outre configurée pour :

    déterminer si le processeur a émis la demande de lecture tout en exécutant un code stocké dans la région protégée de la mémoire en déterminant si l'adresse d'une opération d'extraction d'instruction, précédant immédiatement la demande de lecture de mémoire, était dans la région protégée ;

    déterminer l'état d'un indicateur de protection de lecture binaire pour la région protégée de la mémoire, l'indicateur de protection de lecture étant stocké dans une région de configuration de protection de la mémoire non volatile ; et

    refuser des demandes de lecture pour des adresses dans la région protégée si l'indicateur de protection de lecture binaire pour la région protégée est activé, à moins qu'au moins une parmi une ou plusieurs conditions d'accès ne soit satisfaite, dans lequel une desdites conditions d'accès est que le processeur ait émis les demandes de lecture tout en exécutant un code stocké dans la région protégée,

    dans lequel la logique de commande de mémoire non volatile est agencée pour empêcher l'écriture sur n'importe quelle portion de la région de configuration de protection à moins que cette portion ne soit dans un état effacé et pour permettre à la région de configuration de protection d'être effacée seulement si une région protégée de la mémoire non volatile est dans un état effacé.


     
    2. Dispositif (1) selon la revendication 1, dans lequel la logique de protection de mémoire (9) comprend une logique matérielle qui est séparée du processeur (7).
     
    3. Dispositif (1) selon la revendication 1 ou 2, dans lequel la logique de protection de mémoire (9) est configurée pour permettre des demandes de lecture pour des adresses dans la région protégée si l'indicateur de protection de lecture binaire pour la région protégée n'est pas activé.
     
    4. Dispositif (1) selon l'une quelconque des revendications précédentes, dans lequel la logique de protection de mémoire (9) est configurée pour refuser des demandes de lecture pour des adresses dans la région protégée si l'indicateur de protection de lecture binaire pour la région protégée est activé, à moins que le processeur (7) n'ait émis les demandes de lecture tout en exécutant un code stocké dans la région protégée.
     
    5. Dispositif (1) selon l'une quelconque des revendications précédentes, dans lequel la logique de protection de mémoire (9) est en outre configurée pour déterminer l'état d'un indicateur de protection d'écriture binaire pour la région protégée et pour refuser des demandes de lecture pour des adresses dans la région protégée si l'indicateur de protection d'écriture binaire pour la région protégée est activé, à moins que le processeur (7) n'ait émis les demandes d'écriture tout en exécutant un code stocké dans la région protégée, l'indicateur de protection d'écriture binaire étant également stocké dans la région de configuration de protection.
     
    6. Dispositif (1) selon l'une quelconque des revendications précédentes, dans lequel la logique de protection de mémoire (9) est configurée pour surveiller tous les accès à la mémoire non volatile (13).
     
    7. Dispositif (1) selon l'une quelconque des revendications précédentes, dans lequel la logique de protection de mémoire (9) est configurée pour établir un registre sur chaque opération d'extraction d'instruction suivant que l'adresse de l'instruction extraite soit ou non dans la région protégée.
     
    8. Dispositif (1) selon l'une quelconque des revendications précédentes, dans lequel la région protégée est variable et est définie par une ou plusieurs adresses stockées sur le dispositif.
     
    9. Dispositif (1) selon l'une quelconque des revendications précédentes, dans lequel la région protégée de la mémoire (13) s'étend entre une adresse constante prédéterminée et un point variable dans la plage d'adresses mémoire et la logique de protection de mémoire (9) est configurée pour déterminer si la demande de lecture est pour une adresse dans la région protégée en déterminant si l'adresse est entre l'adresse constante prédéterminée et l'adresse mémoire variable.
     
    10. Dispositif (1) selon l'une quelconque des revendications précédentes, dans lequel le dispositif comprend en outre une mémoire volatile (11) et dans lequel la logique de protection de mémoire (9) est en outre configurée pour refuser des demandes de lecture pour des adresses dans une région protégée de la mémoire volatile si un indicateur de protection de lecture pour la région protégée de la mémoire volatile est activé, à moins que le processeur (7) n'ait émis les demandes de lecture tout en exécutant un code stocké dans la région protégée de la mémoire non volatile (13).
     
    11. Dispositif (1) selon l'une quelconque des revendications précédentes, comprenant une interface pour permettre l'accès à la mémoire par un débogueur externe ou un chargeur de logiciel, dans lequel la logique de protection de mémoire (9) est agencée pour refuser des demandes de lecture reçues via ladite interface pour des adresses dans une ou plusieurs régions protégées de mémoire volatile ou non volatile (11, 13) si un indicateur de protection de débogage pour la région est activé.
     
    12. Dispositif (1) selon l'une quelconque des revendications précédentes, comprenant une logique de communication radio intégrée (17), dans lequel un module de microprogramme (23) comprenant un code mettant en Ĺ“uvre une pile de protocoles radio est stocké dans la région protégée de mémoire (13) et dans lequel une application logicielle (25) qui s'interface avec le module de microprogramme est stockée dans la mémoire à l'extérieur de la région protégée.
     
    13. Procédé de commande d'accès à la mémoire sur un dispositif à circuit intégré (1) comprenant un processeur (7), une mémoire non volatile (13) pour stocker un code exécutable et une logique de commande de mémoire non volatile (20), le procédé comprenant :

    la détection d'une demande de lecture de mémoire par le processeur ; et

    la détermination que la demande de lecture est pour une adresse dans une région protégée de la mémoire,

    caractérisé par :

    la détermination si le processeur a émis la demande de lecture tout en exécutant un code stocké dans la région protégée de la mémoire en déterminant si l'adresse d'une opération d'extraction d'instruction, précédant immédiatement la demande de lecture de mémoire, était dans la région protégée ;

    la détermination qu'un indicateur de protection de lecture binaire pour une région protégée de la mémoire est activé, l'indicateur de protection de lecture étant stocké dans une région de configuration de protection de la mémoire non volatile, dans lequel la logique de commande de mémoire non volatile est agencée pour empêcher l'écriture sur n'importe quelle portion de la région de configuration de protection à moins que cette portion ne soit dans un état effacé et pour permettre à la région de configuration de protection d'être effacée seulement si la région protégée de la mémoire non volatile est dans un état effacé ; et

    la détermination que le processeur a émis la demande de lecture tout en exécutant un code stocké dans la région protégée de la mémoire et par conséquent autoriser la demande de lecture.


     




    Drawing

















    Cited references

    REFERENCES CITED IN THE DESCRIPTION



    This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

    Patent documents cited in the description