US9262340B1 - Privileged mode methods and circuits for processor systems - Google Patents
Privileged mode methods and circuits for processor systems Download PDFInfo
- Publication number
- US9262340B1 US9262340B1 US13/340,418 US201113340418A US9262340B1 US 9262340 B1 US9262340 B1 US 9262340B1 US 201113340418 A US201113340418 A US 201113340418A US 9262340 B1 US9262340 B1 US 9262340B1
- Authority
- US
- United States
- Prior art keywords
- privileged
- memory
- mode
- protection
- access
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active, expires
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/14—Protection against unauthorised use of memory or access to memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/14—Protection against unauthorised use of memory or access to memory
- G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/14—Protection against unauthorised use of memory or access to memory
- G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/14—Protection against unauthorised use of memory or access to memory
- G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
- G06F12/1491—Protection against unauthorised use of memory or access to memory by checking the subject access rights in a hierarchical protection system, e.g. privilege levels, memory rings
Definitions
- the present disclosure relates generally to processor systems, and more particularly to protection modes for processor systems.
- Some systems can include a processor that operates according to code stored in one or more memory circuits.
- processors do not have a built-in privilege mode for limiting access to memory circuits and registers of the system.
- FIGS. 1A to 1C are block schematic diagrams showing a system and operations according to an embodiment.
- FIG. 2 is a table showing vector relocation in a processor system according to an embodiment.
- FIG. 3 is a diagram showing vectors and handlers in a processor system according to an embodiment.
- FIG. 4 is a table showing protection modes for a processor system according to an embodiment.
- FIG. 5 is a table showing restrictions in a processor system for different protection modes according to an embodiment.
- FIG. 6 is a state diagram showing a processor system protection policy according to an embodiment.
- FIG. 7 is a diagram showing a processor system protection policy implemented with a block erasable memory according to an embodiment.
- FIG. 8 is a block schematic diagram showing a processor system according to another embodiment.
- FIGS. 9A to 9D show a sequence of block schematic diagrams illustrating privileged mode circuits and operations of a processor system according to an embodiment.
- FIGS. 10A to 100 are block schematic diagrams showing privileged mode circuits and operations of a processor system according to another embodiment.
- FIG. 11 is a diagram showing a system call function according to one particular embodiment.
- FIGS. 12A and 12B are diagrams showing an interrupt handler corresponding to the system call function of FIG. 11 , according to a particular embodiment.
- FIGS. 13A and 13B are flow diagrams showing interrupt handling of system call functions according to embodiments.
- processor systems include processor systems, associated circuits, and methods for enabling protected modes of operation.
- Such embodiments can implement privileged modes of operation for systems having processors that do not have such features built-in.
- System 100 can include a processor 102 , a vector relocator 104 , a system bus 106 , a first memory 108 , a second memory 110 , a test access port 112 , a privilege mode emulator 114 , and a bus bridge 116 .
- the various parts of the system 100 can be formed in a same integrated circuit package 117 . In a particular embodiment, the various parts of the system 100 can be formed in a same integrated circuit substrate.
- a system 100 can take various forms, including but not limited to: a microcontroller, system-on-chip, or application specific standard product (ASSP).
- ASSP application specific standard product
- portions of system 100 can be formed with programmable circuits.
- a vector relocator 104 and privilege mode emulator 114 can be formed all, or in part, with programmable logic circuits.
- a processor 102 can execute instructions stored in first or second memories ( 108 / 110 ) (or other memories not shown). In the embodiment shown, the processor 102 can be respond to hardware related event, such as a reset or interrupts by initiating requests to predetermined addresses.
- a vector relocator 104 can redirect vector calls from a processor 102 according to values stored in privileged registers. It is understood that a privileged registers can only be accessed when the system 100 is in a privileged mode, as will be described herein, and equivalents. Accordingly, a vector relocator 104 can alter addresses issued by processor 102 before such addresses are applied to bus 106 . When not servicing a vector call, addresses and data can pass-through a vector relocator 104 .
- a bus 106 can be an address and data bus having control/status lines, address lines and data lines.
- a bus 106 can include one or more protection mode lines that can signify a privileged mode of operation.
- a protection mode line(s) can be driven according values established by privileged mode emulator 114 .
- a first memory 108 can include a privileged section 118 , and in the embodiment shown can be system read-only-memory (ROM).
- First memory 108 can include hardware for limiting access to its privileged section 118 .
- privileged section 118 can only be accessed in response to predetermined events, such as a reset of the system 100 or one or more nonmaskable interrupts (NMIs).
- predetermined events such as a reset of the system 100 or one or more nonmaskable interrupts (NMIs).
- NMIs nonmaskable interrupts
- within privileged section 118 can be a boot sequence 120 and a handler 122 .
- a boot sequence 120 can be a sequence executed by processor 102 in the event of a reset event.
- a handler 122 can service one or more predetermined NMIs, as will be described in more detail below.
- a second memory 110 can include a supervisory section 124 .
- a supervisory section 124 can also be a privileged memory region. Further, a supervisory section 124 can have limitations on how data is accessed. In particular, certain data values can be written (e.g., programmed) to bit locations, but other data values require block clearing of such values.
- a second memory 110 can be a flash type electrically erasable programmable read-only-memory, the implements block erase. However, alternate embodiments may include other types of memories that implement a block type erase, or equivalent function. Such a block erase function can enable stored data to be cleared when switching from a higher protection state (i.e., a state that prevents access to more locations) to a lower protection state.
- a test access port 112 can enable access to the system 100 for testing and/or debugging. As will be described in more detail below, a test access port 112 can allow free access, limited access, or no access to various regions of the system 100 depending upon a protection mode.
- a privilege mode emulator 114 can generate a privilege mode indication based on privilege mode register values 126 . Such register values 126 can be programmed by operation of handler 122 , as described herein, or an equivalent. A privilege mode emulator 114 can receive NMI signals, and generate its own NMI signal(s). Control registers 126 can be privileged registers for storing values that establish protection modes for system 100 . In the embodiment shown, control registers can include a protection mode register 126 - 0 and a privilege mode register 126 - 1 .
- a bridge 116 can allow other portions of a system or other devices to share bus 106 .
- control registers 126 can be accessed via bridge 116 .
- a system 100 can include various other system circuit resources accessible via bus 106 . Access to such system circuit resources can be limited based on a protection mode of the system (i.e., established by values in register 126 - 0 ). System circuit resources can include, but are not limited to, other memories, and other registers, including control registers.
- FIGS. 1A to 1C show how protection modes of operation can be established according to one embodiment.
- a system 100 in the event of a reset condition, can enter a boot state.
- protection mode register 126 - 0 can output predetermined protection values, established by hardware, that indicates the BOOT state.
- Such BOOT state protection values can place test access port 112 into a stalled state preventing access to system 100 via such a port.
- a processor 102 can execute boot sequence 120 .
- a boot sequence 120 can result in processor 102 reading an encoded protection mode value (EP) from supervisory section 124 , decoding such a value, and writing the decoded protection value (PROT) into protection mode register 126 - 0 .
- EP encoded protection mode value
- PROT decoded protection value
- protection mode register 126 - 0 a protection mode for the system 100 can be established.
- protected states established from decoded values stored in supervisory section can be different from the BOOT state. That is, a BOOT mode can be a transitory mode used to establish a programmed protection level for the system 100 .
- An encoded protection value (EP) stored within supervisory section 124 can be altered to change a protection mode for a system 100 .
- EP encoded protection value
- Such changes in protection mode can be restricted, with changes to lower protection modes resulting in an erasure of code subsequently programmed for the system 100 .
- FIGS. 1B and 1C show the changing of a protection mode for a system 100 .
- a processor 102 in response to an NMI, can execute handler 122 .
- a handler 122 can initiate a write to privilege mode register 126 - 1 . If suitable hardware conditions exist, a system function can be executed that can enable a write to flash memory 110 .
- accesses to supervisory section 124 can be allowed, subject to protection mode policies.
- returns to lower protection states can result in an erasure of entire sections of flash memory 110 .
- embodiments can include a vector relocator (e.g., 104 ) for remapping requests made by a processor 102 .
- a vector relocator e.g., 104
- Such remapping will now be described.
- FIG. 2 is a table showing vector relocation according to an embodiment.
- column “Vector” indicates a vector called by a processor.
- Column “MASTER” indicates system bus signal that can identify the origin of a request, with a 0 indicating a processor call and a 1 indicating a call from elsewhere.
- Columns are shown for three configuration bits: CPUSS_SYSREQ.NO_RST_OVR, CPUSS_SYSREQ.SYSREQ, CPUSS_SYSREQ.VECS_IN_RAM.
- Such configuration bits can be stored in a privileged mode register (e.g., 126 - 1 ).
- Column “Go To” shows how a vector call can be redirected to any of numerous other locations.
- a system can include a ROM, Flash Memory, and random access memory (RAM).
- Column “Comments” describes the type of vector. Values 0 and 1 indicate bit values, with X indicating a don't care value.
- Configuration bit CPUSS_SYSREQ.NO_RST_OVR can indicate a non-reset indication bit.
- vector calls to 0,1 can indicate a reset event, and the system is directed to execute code in ROM.
- a vector call to 0,1 can be directed to a location in Flash memory.
- Such a capability can enable test routines to be executed in a flash memory.
- Configuration bit CPUSS_SYSREQ.SYSREQ can indicate a system call.
- a system call can access privileged sections of a ROM under certain conditions (including an NMI). Accordingly, when such a bit value is set (e.g., 1), the vector call for the NMI is directed to executable code in ROM. However, when such a bit is not set, it is possible to re-direct vector calls to Flash or RAM (e.g., appropriate user NMI handlers can be stored in Flash or RAM).
- Configuration bit CPUSS_SYSREQ.VEC_IN_RAM can indicate when a vector is stored in RAM. Accordingly, a vector call can be re-directed to RAM of such a bit is set.
- FIG. 3 is a diagram showing vector tables and corresponding handlers and responses according to an embodiment.
- FIG. 3 shows how vector handlers can be used, under suitable conditions, to access privileged regions of a system.
- FIG. 3 shows a ROM vector table 302 , a Flash vector table 304 and RAM vector table 306 .
- reset vector calls are not redirected, and so will access ROM vector table 302 .
- ROM vector table 302 can point to boot code 308 .
- Boot code 308 can access a flash limit register (CPUSS_PRIV_FLASH.FLASH_LIMIT) and user start address (SFLASH_FLASH_START) according to a privileged flash access register (SFLASH_FLASH_CTRL.PRIV_FLASH).
- CPUSS_PRIV_FLASH.FLASH_LIMIT flash limit register
- SFLASH_FLASH_START user start address
- SFLASH_FLASH_CTRL.PRIV_FLASH a privileged flash access register
- registers CPUSS_PRIV_FLASH.FLASH_LIMIT and SFLASH_FLASH_START can be located in a supervisory area of a Flash memory, while register CPUSS_PRIV_FLASH.FLASH_LIMIT can be a privileged register.
- NMI vectors calls can be selectively redirected according to register values.
- the ROM vector table 302 is accessed.
- a corresponding system request hander 310 can be executed, or alternatively, a copy of a handler 310 ′ residing in Flash memory can be executed.
- an appropriate system call routine can be looked up from a privileged area of the ROM 312 , and the system call function (e.g., one of 314 - 0 to -n) can be executed.
- a handler 310 / 310 ′ can look up the patched system call routine from a privileged section of the Flash memory 316 , the patched system call function 318 can be executed.
- a selected system call function ( 314 - 1 ) can upload test code to a RAM 315 .
- a user's NMI handler 320 can be called from a non-privileged (e.g., user mode) section of Flash or RAM.
- vector calls to the Flash memory vector table 304 can result in a suitable user handler (e.g., fault handler 322 , interrupt service request 324 - 0 / 1 ) stored in the Flash memory or in RAM.
- vectors 0,1 in the Flash vector table 304 can include start addresses for a user's main code (e.g., firmware) 326 .
- Vector calls to the RAM vector table 306 can also result in a suitable user handler (e.g., user NMI hander 328 , fault handler 330 , interrupt service request 332 - 0 / 1 ) stored in the Flash memory or in the RAM.
- a suitable user handler e.g., user NMI hander 328 , fault handler 330 , interrupt service request 332 - 0 / 1
- a system can include multiple protection modes, including a transitory BOOT mode.
- System protection modes according to one particular embodiment will now be described with reference to FIGS. 4 and 5 .
- column NAME identifies different modes.
- Column “PROT[ 3 : 0 ]” shows bit values in a protection value register corresponding to the different modes.
- An “X” indicates a don't care value (i.e., bit value does not affect mode).
- a most significant bit PROT[ 3 ] can be “1” in the transitory BOOT mode.
- a boot sequence can overwrite such a bit value when any of the other protection modes (VIRGIN, OPEN, PROTECTED, KILL) is established.
- Registers storing protection values PROT[ 3 : 0 ] are writable from a privileged mode only.
- Flash Encoding shows how a protection value can be encoded in a Flash memory. Such encoding can ensure that if a programming operation to a portion of the memory (e.g., supervisory section) is interrupted between an erase and program action, the system can be placed in the OPEN mode. While FIG. 4 shows such an encoding for a Flash memory, embodiments utilizing other memories can be adjusted accordingly (i.e., if a memory erases to a 1 state, OPEN would be encoded as 111).
- Column “CPU” shows restrictions on a processor in the different modes.
- column “Debug” shows restrictions on accesses from a debug access port
- “Test” shows restrictions on accesses from a test port.
- a VIRGIN mode represents a most open mode.
- a system can leave a fabrication facility in a VIRGIN mode. Systems in a VIRGIN mode can still be subject to test, program, and if appropriate, repair steps.
- a next more restrictive mode can be the OPEN mode.
- a processor can have access to privileged locations only in a privileged mode. Accesses via debug and test ports can only access nonprivileged (i.e., user) regions.
- systems can be programmed with proprietary manufacturer code. Any areas of memory (e.g., ROM, Flash memory and/or RAM) that need to be protected can be identified in predetermined supervisory sections of the Flash memory. Systems can then be programmed into the OPEN mode to prevent access to such areas needing protection. In one embodiment, systems can be shipped to customers in the OPEN mode.
- the next more restrictive mode can be the PROTECTED mode.
- a processor can have access to privileged locations as in the OPEN mode. However, accesses via a debug access port are prohibited. Further, access via a test port can be restricted to non-privileged registers. Access to nonprivileged mode registers can enable system calls (as described herein) to be made.
- a user e.g., customer
- the system can be placed in the PROTECTED MODE, providing protection to the user's code.
- re-programming to a less restrictive mode e.g., OPEN, VIRGIN
- a most restrictive mode can be the KILL mode. In a KILL mode no test or debug access is possible. It is noted that such a mode prevents any failure analysis of the system by such restrictive access.
- the BOOT mode can be a transitory state, rather than a mode established by a manufacturer or customer.
- a processor has free access to system locations, while debug and test ports are stalled.
- FIG. 5 is another table showing restrictions on accesses of a processor system based on different modes according to one particular embodiment.
- column “Protection” identifies a protection mode.
- a column “From” indicates a source of an access.
- CPU(PM) represents a processor request in a privileged mode.
- CPU(UM) represents a processor request in a nonprivileged (i.e., user) mode.
- DAP represents a debug/test access port.
- CPU PBB can be system regions of a processor.
- ROM can be a system ROM.
- FLASH can be a flash memory having supervisory sections.
- SFLASH can be additional system flash memory.
- BUS Registers can be storage registers in a processor system and can include both privilege registers and nonprivileged (user mode) registers. In the various columns, “Exec Only” represents execution only accesses. That is, such accesses do not read data from such a location, but rather execute code residing at the location. (However, in some embodiments, such executable code can be can be programmed to read data from such locations).
- UM stands for user mode.
- a DAP port cannot access privileged registers.
- such a restriction prevents access to program and erase registers in a Flash memory programming interface. Accordingly, programming and/or erasing of a Flash memory can be accomplished through system calls into the ROM.
- a protection mode policy according to one embodiment is shown in a state transition diagram in FIG. 6 .
- a protection policy 600 can be implemented in supervisory ROM code. As shown, upon completion of manufacturing, a processor system can be in the VIRGIN mode 602 . From the VIRGIN mode, a processor system can be loaded with manufacturer's (mfg) proprietary code, and then programmed to the OPEN mode 604 to restrict access to the mfg's proprietary locations. A customer can program the processor system with its own proprietary code. A customer can then program the system to the PROTECTED mode 606 to restrict access to the customer's code.
- manufacturer's mfg
- a KILL mode 608 can be irreversible. That is, once a processor system is programmed into such a mode, it cannot be programmed to any other protection mode.
- a processor system can be returned to the OPEN mode 604 .
- such an action results in an erasure of customer data (but not mfg data).
- a processor system can be returned to the VIRGIN mode 602 .
- such an action results in an erasure of manufacturer data.
- a protection policy for a Flash memory will now be described.
- Such a protection policy can be implemented in supervisory ROM.
- a Flash memory 710 can include a supervisory region 710 - 0 and a main area 710 - 2 .
- a privileged area 710 - 1 can be created by restricting access based on restriction data 728 stored within supervisory region.
- restriction data 728 can be a per row bit mask that identifies restricted rows within a Flash memory.
- increasing a number of restricted rows can be accomplished with system calls.
- Such system calls can increase to restriction data 728 by identifying additional privileged areas ( 710 - 1 ), and enabling data to be programmed into such additional privileged areas.
- reduction of protected rows is only possible with a full erase that returns the Flash memory 710 to the OPEN, VIRGIN or an empty state.
- a processor system 800 can be one implementation of that shown in FIG. 1 , and like sections are referred to by the same reference character but with the first digit being an “8” instead of a “1”.
- a system 800 can implement any of the protection schemes noted above or equivalents.
- FIG. 8 differs from FIG. 1 in that is shows a RAM 830 and peripheral devices 832 - 00 to - 1 N connected to bus bridges 816 - 0 / 1 .
- a Flash memory 810 has a read accelerator circuit 834 and program interface (I/F) 836 .
- RAM 830 shows a RAM controller 838 and ROM 808 shows a ROM controller 840 .
- a debug I/F 844 - 0 and a program test interface 844 - 1 can be connected to a test/debug access port 812 .
- a bus 806 in addition to data, address and other control signals, can include protection signals prot[ 0 ], prot[ 1 ], and a bus master signal “master”.
- Signal prot[ 0 ] can indicate whether an access is a code fetch or data read/write.
- Signal prot[ 1 ] can indicate whether a processor 802 is operating in a privileged mode or nonprivileged mode.
- Signal “master” can indicate if the transaction originates from a processor 802 or test access port 812 .
- a processor 802 can block all or part of accesses via test access port 812 based on a protection mode. In particular, when in a PROTECTED mode, accesses to privileged regions can be blocked, and when in a KILL mode, all access can be blocked.
- a test access port 812 can be a slave device with respect to control via bus 806 .
- a read accelerator circuit 834 can block read accesses based on both a protection mode (e.g., VIRGIN, OPEN, PROTECTED, KILL), as well as processor mode (e.g., privileged or user).
- a programming I/F 836 can block programming accesses to Flash memory 810 according to a protection mode and registers that can distinguish protected regions from nonprotected regions.
- RAM controller 838 can block access to protected regions based on a protection mode and processor mode of operation (i.e., privileged or not).
- Code within ROM 808 can implement protection policies for programming and erasing Flash memory 810 as noted above (e.g., erasing blocks when switching to a lower protection mode). Such actions are only accessible in a privileged mode of operation. Access to ROM 808 can be prevented except by a system call (execution of code from a reset condition or NMI). A ROM controller 840 can monitor all code fetch accesses based on signal prot[ 0 ]. As noted above, such a signal can indicate when an access is not a code fetch from ROM 808 . Accesses to addresses corresponding to reset and NMI vector calls are always permitted. When such accesses occur, a system call and privileged mode emulator 814 can open up a ROM 808 for further code execution. In one embodiment, this can include setting a ROM access enable bit. Such a bit can be reset in the event a fetch is from somewhere other than the ROM 808 .
- peripheral devices 832 - 00 to - 1 N can be connected to bus bridges 816 - 0 / 1 . Access to peripheral devices ( 832 - 00 to - 1 N) can be restricted based on both protection mode, and mode of operation (e.g., privileged or non-privileged).
- a processor system can be placed into a privileged mode in response to an interrupt and system call.
- Implementation of such privileged mode according to one embodiment will now be described. It is noted that such an implementation need not modify a processor. That is, the following embodiments can enable the creation of a privileged mode of operation when such a feature is not built into a processor.
- FIGS. 9A to 9D are a sequence of block schematic diagrams showing privileged mode operations according to an embodiment.
- FIGS. 9A to 9D show items like those in FIGS. 1 and 8 , and such like items are referred to by the same reference character but with the first digit being “9”.
- FIGS. 9A to 9E show a privileged mode emulator 914 having a system call ID register 946 and a control register 948 .
- Such registers can store control bits for establishing a privileged mode of operation, as well as identification data, which can identify a system function for execution in the privileged mode.
- An interrupt multiplexer (MUX) 950 can apply NMIs to processor 902 .
- NMIs can originate from suitable hardware (not shown), and can also originate from privileged mode emulator 914 .
- a ROM 908 can include a privileged region 918 which can hold an NMI handler 954 and a system function 952 . It is noted that such code can be stored in protected regions of other memories. However, a vector table pointing to NMI handler 954 resides in ROM 940 .
- FIGS. 9A to 9D also show a user (nonprivileged) memory region 958 which can store a system call 956 for execution. It is understood that a user memory region 958 can be part of any suitable memory in the system 900 , such as a user region of a ROM 908 , Flash memory 910 , or RAM 930 , as but examples.
- a switch to a privileged mode of operation a system call 956 can be made from a user region 958 .
- a switch to a privileged mode can be started in a nonprivileged mode.
- Execution of a system call 956 can include the writing of values to registers 946 and 948 that can identify a particular system function for execution.
- a system call 956 may then wait for a particular interrupt.
- a processor 902 in response to an appropriate interrupt (shown by circle 1 ), can jump to a vector table in ROM 908 to execute an NMI handler 954 (shown by circle 2 ).
- NMI handler 954 can write control values to register 948 that can place the system into a privileged state (shown by circle 3 ).
- registers 946 and 948 can be cleared, returning system 900 to a nonprivileged state.
- An interrupt through interrupt MUX 950 is de-asserted, and signal prot[ 1 ] on bus 906 can be de-asserted.
- a system call in a nonprivileged state can utilize an NMI and corresponding handler to enter a privileged state.
- System 1000 can include sections like those of FIGS. 9A-9D , and like sections are referred to by the same reference character but with the leading digits being a “10” instead of a “9”.
- a system 1000 can implement any of the protection schemes noted above or equivalents.
- a processor system 1000 can be all or part of a programmable system-on-chip, and can include a programmable section 1060 .
- a programmable section 1060 can include programmable blocks 1062 and an interconnect fabric 1064 .
- Programmable blocks 1062 can be programmed into various circuits according to configuration data.
- Interconnect fabric 1064 can be programmed to provide interconnection between programmable blocks 1062 .
- either of privilege mode emulator 1014 or interrupt MUX 1050 can be formed from programmable blocks (i.e., are part of 1062 ).
- a privilege mode emulator 1014 can include registers CPUSS_SYSARG and CPUSS_SYSREG.
- Register CPUSS_SYSARG can store a value “arg” that can be an argument corresponding to a system function called by a system call.
- arg can be a 32-bit value.
- a portion of register CPUSS_SYSREQ can store a system function ID “cmd”, while another portion can store control bits “ctrl”.
- cmd can be a sixteen-bit value.
- Control bits “ctrl” can provide output signal “syscallreq”, which can serve as an interrupt, and “privileged” which can serve as a mode indicator for a bus line (prot[ 1 ]). In one embodiment, four control bits can be provided.
- a ROM controller 1040 can provide output values (ROMaccdata) to privilege mode emulator 1014 . Such values can indicate when accesses are (or are not) to the ROM.
- a privilege mode emulator 1014 can use such values to determine whether or not conditions exist for a privileged mode, or to reset control bits (ctrl) to exit a privilege mode for improper accesses.
- privilege mode emulator 1014 can provide a ROM access enable signal “rom_access_en” that can enable access to privileged ROM locations in a privilege mode.
- an NMI handler in a privileged mode, can be executed in response to an NMI.
- the NMI handler can maintain an NMI in an asserted state by writing to register 1048 to enable privilege mode emulator 1014 to assert syscallreq.
- privilege mode emulator 1014 can restrict accesses to ROM (not shown) except for accesses resulting from a NMI initiated system call, as described herein.
- One exception to such a restriction can be a reset event, which can end up executing from the ROM, as described above.
- a register CPUSS_SYSREQ can further include a DSI_NMI. Such a bit can be set to ensure a system call cannot be made from within an NMI handler.
- Signals “wdata[i]”, “wdata[j]” can be write data values.
- a “master” signal can indicate an access by ROM (0), or some other source (1) (e.g., debug access port).
- Signal “code_rd_not_rom” can be a signal from a ROM controller indicating that an access is not from the ROM.
- Signal “access_to_vec” can also be generated by a ROM controller to indicate that an access is a vector access.
- Signal “cpuss_sys_req_wr” can be a request to write to control register 1048 (only the control bit portion of control register 1048 is shown in FIG. 10B ).
- Signals “prot[ 0 ]” can indicate a code fetch or data read/write.
- Signal “sel” can indicate a start of a transfer over a bus.
- Signal “trans[ 1 ]” can indicate a type of transfer on a bus.
- Signals addr[ ] can be address values on a bus.
- Value “rom_limit” can be a ROM address limit provided to 1072 .
- Value PROT can be a protection value as noted above (e.g., VIRGIN, OPEN, PROTECTED, KILL).
- Signal “code_rd” can indicate a code read is occurring.
- Signal “rom_rd” can indicate a ROM read is occurring.
- Signal “rom_access_ok” can indicate that a current ROM access is permitted.
- section 1070 can compare a received address to an address limit to determine if a vector call is occurring. If such a condition is true, it can provide an output of logic 1. In the embodiment shown, if an address is less than 0000 — 0010, it can be determined to be a vector call. Section 1072 can compare an address to a ROM limit. If an address is less than a limit, section 1072 can output a logic 1. Section 1074 can determine if a protection mode is low enough to allow ROM access. In the embodiment shown, if a protection mode is VIRGIN or BOOT, an output can be asserted to logic 1.
- SystemCall a system call routine
- Such a SystemCall routine can set registers to values to identify a system function (with cmd and arg). In addition, it can set control bits to asserted levels (1U ⁇ 31). While such bits remain set, the SystemCall can wait for an interrupt to initiate an interrupt handler.
- a SystemCall sequence can also be performed with a tester or debug probe. In such a case, a bit in CPUSS_SYSREQ can be set to indicate the source of the SystemCall.
- NMI handler NMI handler
- NMI ISR system call NMI
- Embodiments above have shown System Call routines that can wait for particular interrupt(s) to trigger a desired NMI handler for entering a privileged mode.
- System Call routines can be responsive to other interrupts. Embodiments incorporating such capabilities will now be described.
- SystemCall N a System Call routine 1300 -A (hereinafter SystemCall N) responsive to other interrupts is shown in a flow diagram.
- SystemCall N can be called in a nonprivileged mode of operation, as described above, or in an equivalent fashion.
- SystemCall N can be initiated ( 1302 ).
- SystemCall N can then designate other interrupts that can be responded to ( 1304 ).
- SystemCall N can wait for an interrupt ( 1306 ).
- SystemCall N can execute the intended INT handler ( 1308 ).
- INT handler 1308 can place a processor system into a privileged mode by setting control bits ( 1308 - 0 ), can call a SystemFunction identified by SystemCall N ( 1308 - 1 ), and upon conclusion, clear control bits ( 1308 - 2 ) to return to a nonprivileged mode.
- the interrupt handler associated with INT X 1312 can be executed.
- the INT X interrupt handler 1312 can execute its own system call routine (SystemCall X) 1302 - 0 , which in the embodiment shown, can call a system function identified in SystemCall X 1302 - 1 .
- SystemCall X system call routine
- Upon completion of the INT X handler 1312 control is returned to SystemCall N. Accordingly, interrupts remain in the states established by SystemCall N (in box 1304 ).
- a system call routine can implement a non-blocking wait for interrupt.
- SystemCall N 1300 -B can include sections like those of FIG. 13A , and such like sections are referred to by the same reference character.
- SystemCall N 1300 -B can differ from that of FIG. 13A in that all interrupts except those associated with intervening SystemCall X can be disabled ( 1314 ). Further, control is not returned to SystemCall N 1300 -B. That is, the intervening interrupt (INT X) can block completion of SystemCall N 1300 -B.
- a system call routine can implement a blocking wait for interrupt.
- processor systems implemented as microcontrollers, ASSPs or programmable and/or nonprogrammable systems-on-chip
- processor systems can form all or part of a PSoC@ programmable embedded system-on-chip manufactured by Cypress Semiconductor Corporation of San Jose, Calif., having an ARM® CortexTM processor embedded therein.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
Abstract
Description
Claims (18)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/340,418 US9262340B1 (en) | 2011-12-29 | 2011-12-29 | Privileged mode methods and circuits for processor systems |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/340,418 US9262340B1 (en) | 2011-12-29 | 2011-12-29 | Privileged mode methods and circuits for processor systems |
Publications (1)
Publication Number | Publication Date |
---|---|
US9262340B1 true US9262340B1 (en) | 2016-02-16 |
Family
ID=55275426
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/340,418 Active 2034-04-27 US9262340B1 (en) | 2011-12-29 | 2011-12-29 | Privileged mode methods and circuits for processor systems |
Country Status (1)
Country | Link |
---|---|
US (1) | US9262340B1 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10384625B2 (en) * | 2015-05-18 | 2019-08-20 | National University Corporation Nagoya University | Communication device and non-transitory recording medium |
US20190278633A1 (en) * | 2018-03-07 | 2019-09-12 | Hamilton Sundstrand Corporation | Jtag lockout with dual function communication channels |
GB2624257A (en) * | 2022-11-08 | 2024-05-15 | Cirrus Logic Int Semiconductor Ltd | Systems and methods for access protection of system peripherals |
US12099602B2 (en) | 2019-10-23 | 2024-09-24 | Huawei Technologies Co., Ltd. | Secure peripheral component access |
Citations (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5293610A (en) * | 1989-08-04 | 1994-03-08 | Motorola, Inc. | Memory system having two-level security system for enhanced protection against unauthorized access |
US6349355B1 (en) | 1997-02-06 | 2002-02-19 | Microsoft Corporation | Sharing executable modules between user and kernel threads |
US6349057B2 (en) * | 2000-06-29 | 2002-02-19 | Sanyo Electric Co., Ltd. | Read protection circuit of nonvolatile memory |
US20040243783A1 (en) | 2003-05-30 | 2004-12-02 | Zhimin Ding | Method and apparatus for multi-mode operation in a semiconductor circuit |
US20050132217A1 (en) * | 2003-02-07 | 2005-06-16 | Broadon Communications Corp. | Secure and backward-compatible processor and secure software execution thereon |
US20060143411A1 (en) | 2004-12-23 | 2006-06-29 | O'connor Dennis M | Techniques to manage partition physical memory |
US7185183B1 (en) | 2001-08-02 | 2007-02-27 | Mips Technologies, Inc. | Atomic update of CPO state |
US20070162759A1 (en) * | 2005-12-28 | 2007-07-12 | Motorola, Inc. | Protected port for electronic access to an embedded device |
KR20070107426A (en) | 2006-05-03 | 2007-11-07 | 연세대학교 산학협력단 | Operating System and Method of Embedded Hardware Including Microcontroller Without Storage Management Device |
US20080244206A1 (en) | 2007-03-30 | 2008-10-02 | Samsung Electronics Co., Ltd. | Method of controlling memory access |
US20090049220A1 (en) * | 2007-05-10 | 2009-02-19 | Texas Instruments Incorporated | Interrupt-related circuits, systems, and processes |
US20090199048A1 (en) * | 2008-02-04 | 2009-08-06 | Honeywell International Inc. | System and method for detection and prevention of flash corruption |
US20090205050A1 (en) * | 2008-02-07 | 2009-08-13 | Analog Devices, Inc. | Method and apparatus for hardware reset protection |
US7600100B2 (en) | 2002-10-22 | 2009-10-06 | Mips Technologies, Inc. | Instruction encoding for system register bit set and clear |
US7661105B2 (en) | 2002-11-18 | 2010-02-09 | Arm Limited | Exception types within a secure processing system |
US20100106954A1 (en) * | 2008-10-23 | 2010-04-29 | Robert Michael Muchsel | Multi-Layer Content Protecting Microcontroller |
US7788725B2 (en) | 2006-01-05 | 2010-08-31 | International Business Machines Corporation | Method and system for probing FCode in problem state memory |
US20110161672A1 (en) | 2009-12-31 | 2011-06-30 | Martinez Alberto J | Provisioning, upgrading, and/or changing of hardware |
-
2011
- 2011-12-29 US US13/340,418 patent/US9262340B1/en active Active
Patent Citations (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5293610A (en) * | 1989-08-04 | 1994-03-08 | Motorola, Inc. | Memory system having two-level security system for enhanced protection against unauthorized access |
US6349355B1 (en) | 1997-02-06 | 2002-02-19 | Microsoft Corporation | Sharing executable modules between user and kernel threads |
US6349057B2 (en) * | 2000-06-29 | 2002-02-19 | Sanyo Electric Co., Ltd. | Read protection circuit of nonvolatile memory |
US7185183B1 (en) | 2001-08-02 | 2007-02-27 | Mips Technologies, Inc. | Atomic update of CPO state |
US7600100B2 (en) | 2002-10-22 | 2009-10-06 | Mips Technologies, Inc. | Instruction encoding for system register bit set and clear |
US7661105B2 (en) | 2002-11-18 | 2010-02-09 | Arm Limited | Exception types within a secure processing system |
US20050132217A1 (en) * | 2003-02-07 | 2005-06-16 | Broadon Communications Corp. | Secure and backward-compatible processor and secure software execution thereon |
US20040243783A1 (en) | 2003-05-30 | 2004-12-02 | Zhimin Ding | Method and apparatus for multi-mode operation in a semiconductor circuit |
US20060143411A1 (en) | 2004-12-23 | 2006-06-29 | O'connor Dennis M | Techniques to manage partition physical memory |
US20070162759A1 (en) * | 2005-12-28 | 2007-07-12 | Motorola, Inc. | Protected port for electronic access to an embedded device |
US7788725B2 (en) | 2006-01-05 | 2010-08-31 | International Business Machines Corporation | Method and system for probing FCode in problem state memory |
KR20070107426A (en) | 2006-05-03 | 2007-11-07 | 연세대학교 산학협력단 | Operating System and Method of Embedded Hardware Including Microcontroller Without Storage Management Device |
US20080244206A1 (en) | 2007-03-30 | 2008-10-02 | Samsung Electronics Co., Ltd. | Method of controlling memory access |
US20090049220A1 (en) * | 2007-05-10 | 2009-02-19 | Texas Instruments Incorporated | Interrupt-related circuits, systems, and processes |
US20090199048A1 (en) * | 2008-02-04 | 2009-08-06 | Honeywell International Inc. | System and method for detection and prevention of flash corruption |
US20090205050A1 (en) * | 2008-02-07 | 2009-08-13 | Analog Devices, Inc. | Method and apparatus for hardware reset protection |
US20100106954A1 (en) * | 2008-10-23 | 2010-04-29 | Robert Michael Muchsel | Multi-Layer Content Protecting Microcontroller |
US20110161672A1 (en) | 2009-12-31 | 2011-06-30 | Martinez Alberto J | Provisioning, upgrading, and/or changing of hardware |
Non-Patent Citations (1)
Title |
---|
Lanfranco Lopriore, "Hardware/Compiler Memory Protection in Sensor Nodes," WWW.SCiRP.org/journal/ijcns, Aug. 2008, 6 pages. |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10384625B2 (en) * | 2015-05-18 | 2019-08-20 | National University Corporation Nagoya University | Communication device and non-transitory recording medium |
US20190278633A1 (en) * | 2018-03-07 | 2019-09-12 | Hamilton Sundstrand Corporation | Jtag lockout with dual function communication channels |
US10540213B2 (en) * | 2018-03-07 | 2020-01-21 | Hamilton Sundstrand Corporation | JTAG lockout with dual function communication channels |
US12099602B2 (en) | 2019-10-23 | 2024-09-24 | Huawei Technologies Co., Ltd. | Secure peripheral component access |
GB2624257A (en) * | 2022-11-08 | 2024-05-15 | Cirrus Logic Int Semiconductor Ltd | Systems and methods for access protection of system peripherals |
GB2624257B (en) * | 2022-11-08 | 2024-11-06 | Cirrus Logic Int Semiconductor Ltd | Systems and methods for access protection of system peripherals |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8443423B2 (en) | Secure information processing | |
US5684948A (en) | Memory management circuit which provides simulated privilege levels | |
US6779065B2 (en) | Mechanism for interrupt handling in computer systems that support concurrent execution of multiple threads | |
US9575816B2 (en) | Deadlock/livelock resolution using service processor | |
US8683191B2 (en) | Reconfiguring a secure system | |
US7934076B2 (en) | System and method for limiting exposure of hardware failure information for a secured execution environment | |
US6594756B1 (en) | Multi-processor system for selecting a processor which has successfully written it's ID into write-once register after system reset as the boot-strap processor | |
US7840845B2 (en) | Method and system for setting a breakpoint | |
US20140359788A1 (en) | Processing system | |
US20040243783A1 (en) | Method and apparatus for multi-mode operation in a semiconductor circuit | |
JP2010515149A5 (en) | ||
CN111033630A (en) | Multiprocessor core device with MBIST | |
US9262340B1 (en) | Privileged mode methods and circuits for processor systems | |
US10061940B2 (en) | Secure protection processor and method including comparing an instruction security attribute of an instruction and a security attribute of an operational event | |
US6968410B2 (en) | Multi-threaded processing of system management interrupts | |
US7536694B2 (en) | Exception handling in a multiprocessor system | |
EP2817714B1 (en) | Hiding logical processors from an operating system on a computer | |
US8612720B2 (en) | System and method for implementing data breakpoints | |
KR100928757B1 (en) | System and method for control registers accessed via private operations | |
US7774758B2 (en) | Systems and methods for secure debugging and profiling of a computer system | |
Kleen | Machine check handling on Linux | |
US20010049794A1 (en) | Write protection software for programmable chip | |
KR20210096062A (en) | Exception-raised event handling system and method | |
US11152076B2 (en) | Apparatus and method for executing debug instructions | |
CN119045891A (en) | Method and device for preventing processor from being blocked when target program performs memory access |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: CYPRESS SEMICONDUCTOR CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:VAN ANTWERPEN, HANS;REEL/FRAME:027611/0328 Effective date: 20120118 |
|
AS | Assignment |
Owner name: MORGAN STANLEY SENIOR FUNDING, INC., NEW YORK Free format text: SECURITY INTEREST;ASSIGNORS:CYPRESS SEMICONDUCTOR CORPORATION;SPANSION LLC;REEL/FRAME:035240/0429 Effective date: 20150312 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
AS | Assignment |
Owner name: MUFG UNION BANK, N.A., CALIFORNIA Free format text: ASSIGNMENT AND ASSUMPTION OF SECURITY INTEREST IN INTELLECTUAL PROPERTY;ASSIGNOR:MORGAN STANLEY SENIOR FUNDING, INC.;REEL/FRAME:050896/0366 Effective date: 20190731 |
|
AS | Assignment |
Owner name: MORGAN STANLEY SENIOR FUNDING, INC., NEW YORK Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE 8647899 PREVIOUSLY RECORDED ON REEL 035240 FRAME 0429. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY INTERST;ASSIGNORS:CYPRESS SEMICONDUCTOR CORPORATION;SPANSION LLC;REEL/FRAME:058002/0470 Effective date: 20150312 |
|
AS | Assignment |
Owner name: SPANSION LLC, CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MUFG UNION BANK, N.A.;REEL/FRAME:059410/0438 Effective date: 20200416 Owner name: CYPRESS SEMICONDUCTOR CORPORATION, CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MUFG UNION BANK, N.A.;REEL/FRAME:059410/0438 Effective date: 20200416 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |