US20060259828A1 - Systems and methods for controlling access to secure debugging and profiling features of a computer system - Google Patents
Systems and methods for controlling access to secure debugging and profiling features of a computer system Download PDFInfo
- Publication number
- US20060259828A1 US20060259828A1 US11/383,475 US38347506A US2006259828A1 US 20060259828 A1 US20060259828 A1 US 20060259828A1 US 38347506 A US38347506 A US 38347506A US 2006259828 A1 US2006259828 A1 US 2006259828A1
- Authority
- US
- United States
- Prior art keywords
- target application
- secure
- request
- processor
- target
- 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.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
- G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3648—Software debugging using additional hardware
- G06F11/3656—Software debugging using additional hardware using a specific debug interface
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/76—Architectures of general purpose stored program computers
- G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/76—Architectures of general purpose stored program computers
- G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
- G06F15/7839—Architectures of general purpose stored program computers comprising a single central processing unit with memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/43—Checking; Contextual analysis
Definitions
- Some illustrative embodiments include a system that includes a processor, and a memory coupled to the processor (the memory used to store information and an attribute associated with the stored information). At least one bit of the attribute determines a security level, selected from a plurality of security levels, of the stored information associated with the attribute. Asserting at least one other bit of the attribute enables exportation of the stored information from the computer system if the security level of the stored information is higher than at least one other security level of the plurality of security levels.
- Other illustrative embodiments include a method that includes receiving a request from a requestor to enable secure testing of a target application executing on a target system, sending an authorization request to the target application, and enabling secure testing of the target application and notifying the requester that secure testing is allowed, if the target application allows the request.
- Yet other illustrative embodiments include an Information carrier medium that includes software that can be executed on a processor to cause the processor to receive a request from a requester to enable secure testing of a target application executing on a target system; to send an authorization request to the target application; and to enable secure testing of the target application and notifying the requester that secure testing is allowed, if the target application allows the request.
- Still other illustrative embodiments include a method that includes receiving a request for secure test access to a target application executing within a target system, the request received by the target application, attempting to validate the authentication credentials within the request using validation data stored within the target application, and sending a response to the request indicating that secure test access is allowed if the authentication credentials are validated.
- Still further illustrative embodiments include an Information carrier medium comprising software that can be executed on a processor to cause the processor to receive a request for secure test access to a target application executing within a target system, the request received by the target application; to attempt to validate the authentication credentials within the request using validation data stored within the target application; and to send a response to the request indicating that secure test access is allowed if the authentication credentials are validated.
- Yet further illustrative embodiments include a method that includes receiving a request from a user to securely test a target application, sending a request to a target system to securely test the target application, the request comprising authentication credentials, and receiving test data from the target application if a response is received to the request sent to the target system indicating that test access to the target application is allowed.
- Still further illustrative embodiments include an Information carrier medium comprising software that can be executed on a processor to cause the processor to receive a request from a user to securely test a target application; to send a request to a target system to securely test the target application, the request comprising authentication credentials; and to receive test data from the target application if a response is received to the request sent to the target system indicating that test access to the target application is allowed.
- Yet further illustrative embodiments include a system for debugging and profiling a computer system that includes a target computer system comprising a processor, wherein an operating system executes on the processor and a target application and a kernel execute within the operating system on the processor, and further comprising a memory coupled to the processor, wherein the target application and a page attribute table are stored in the memory; and a test workstation coupled to the target system, wherein a debug and profiling application executes on the test workstation.
- the kernel asserts a bit within an entry in the page attribute table, the entry associated with the location in memory where the target application is stored, and the assertion enables the target application to provide test information to the debug and profiling application.
- the target application is stored in a secure region of memory and executes one the processor in a secure mode.
- FIG. 1 shows a system for testing and debugging a target system, in accordance with at least some illustrative embodiments
- FIG. 2 shows a page attribute table entry, in accordance with at least some illustrative embodiments
- FIG. 3A shows a memory with secure emulation logic, in accordance with at least some illustrative embodiments
- FIG. 3B shows a portion of a pipelined processor with secure emulation logic, in accordance with at least some illustrative embodiments
- FIG. 3C shows a processor register with secure emulation logic, in accordance with at least some illustrative embodiments
- FIG. 4A shows secure emulation logic, in accordance with at least some illustrative embodiments
- FIG. 4B shows a truth table for the secure emulation logic of FIG. 4A ;
- FIG. 5 shows a system for testing and debugging a target system that uses a debug authentication mechanism, in accordance with at least some illustrative embodiments
- FIG. 6 shows a method for requesting secure testing of a target application, in accordance with at least some illustrative embodiments
- FIG. 7 shows a method for authenticating within a target application a request for secure testing, in accordance with at least some illustrative embodiments.
- FIG. 8 shows a method for processing a request for secure testing of a target application, and for acting on an authorized request, in accordance with at least some illustrative embodiments.
- Couple or “couples” is intended to mean either an indirect or direct electrical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical connection, or through an indirect electrical connection via other devices and connections.
- system refers to a collection of two or more parts and may be used to refer to an electronic system such as a computer system or a portion of a computer system.
- software includes any executable code capable of running on a processor, regardless of the media used to store the software.
- code stored in non-volatile memory and sometimes referred to as “embedded firmware,” is included within the definition of software.
- FIG. 1 shows a system 100 for debugging and profiling a target system 110 , constructed in accordance with at least some illustrative embodiments of the invention, which comprises processor 200 , memory system 170 , and test interface (Test I/F) 120 .
- Processor 200 couples to test interface 120 , which couples to both memory system 170 and test workstation 180 .
- Test workstation 180 permits a user to monitor debug and profiling data 290 collected from both processor 200 and memory system 170 of target system 110 , and further permits the user to control the testing of target system 110 .
- Debug and profiling data may also be collected from a number of other sources within target system 110 , and all such sources are intended to be within the scope of the present disclosure.
- Processor 200 also couples to memory system 170 , which comprises level 1 cache memory (L1 Cache) 130 (the highest cache level with the fastest memory), level 2 cache memory (L2 Cache) 150 (the lowest cache level with memory slower than the memory of the L1 cache), main memory subsystem 160 (with memory slower than the memory of both the L1 and L2 caches), and memory management unit (MMU) 125 .
- L1 cache 130 which is the first level of a multilevel cached memory system, includes data memory controller 132 and program memory controller 142 , which each couple to processor 200 .
- Data memory controller 132 couples to L1 data memory 134 , which includes cached data (Data) 135 , cached data tag information (Tag) 137 , and data page attribute table (PAT) 139 .
- program memory controller 142 couples to L1 program memory 144 , which includes cached program instructions (Prog) 145 , cached instruction tag information (Tag) 147 , and program page attribute table (PAT) 149 .
- Data memory controller 132 and program memory controller 142 each couple to unified memory controller 152 , which is part of L2 cache 150 .
- L2 cache 150 also includes L2 memory 154 , which also couples to unified memory controller 152 .
- L2 memory 154 includes cached data and program instructions (D/P) 155 , cached data and program tag information (Tag) 157 , and data and program page attribute table (PAT) 159 .
- Unified memory controller 152 couples to main memory controller 162 , which is part of main memory subsystem 160 .
- Main memory subsystem 160 also includes main memory 164 , which also couples to main memory controller 162 .
- Main memory 164 includes data and program information 165 , as well as data and program page attribute table (PAT) 169 .
- Memory management unit 125 couples to, and interacts with, each of the memory controllers ( 132 , 142 , 152 , and 162 ) at each level of memory (L1, L2, and Main).
- processor 200 When processor 200 reads an instruction or data from memory, an attempt is made to first retrieve the instruction or data from L1 cache 130 . If the instruction or data is not located within L1 cache 130 , an attempt is subsequently made to read the instruction or data from L2 cache 150 . If the instruction or data is located in L2 cache 150 , L1 cache 130 may be updated to include the instruction or data from L2 cache 150 (making it available in L1 cache 130 for subsequent reads), and processor 200 may proceed with processing the instruction or data. If the instruction or data is not located within L2 cache 150 , the instruction or data is read from main memory subsystem 160 . L1 cache 130 and L2 cache 150 may be updated to include the instruction or data read.
- Processor 200 in accordance with at least some embodiments, is capable of executing code within two different execution modes, supervisor mode and user mode. In supervisor mode, all functions of processor 200 are available to the program executing on the processor. In user mode, the program executing on processor 200 is blocked from executing some instructions and from accessing some control registers within the processor. This prevents an unprivileged program from bypassing the management of hardware by supervisory software. Processor 200 is also capable of operating at two different security levels, a secure level and a non-secure level. Resources (e.g., memory pages) within target system 110 are configured to operate at one of the two security levels, and programs executing while the processor is operating at a non-secure level are blocked from accessing resources configured as secure resources.
- Resources e.g., memory pages
- Security levels may be defined in a number of different ways depending upon the design of processor 200 .
- the security level reflects the security level of the instruction being executed by the processor.
- the security level of the instruction in turn depends upon the security level of the resource that stores the instruction (e.g., an instruction stored within a read-only memory that is configured as a secure resource is a secure instruction).
- an instruction stored within a read-only memory that is configured as a secure resource is a secure instruction.
- processor 200 is a pipelined processor with multiple execution stages operating simultaneously, each stage operates at one of the defined security levels, independently of some or all other stages, Accordingly, the security level of each stage reflects the security level of the instruction being processed by that stage.
- the instruction fetch stage is operating at a secure level
- the instruction decode stage is operating at a non-secure level.
- target system 110 can be configured to include “trusted” resources. These resources are configured to operate, execute and/or be accessed while processor 200 is operating in supervisor mode by instructions loaded by the processor from a secure resource. Because the resource is secure, it may only be accessed by trusted code, and if the resource is a modifiable medium (e.g., a flash memory), the contents of the resource (i.e., the trusted code) may only be modified by the trusted code.
- target system 100 is configured to initialize processor 200 in a supervisor mode, and to initially load and execute code from a secure region of non-volatile memory (e.g., an electrically erasable programmable read-only memory (EEPROM)).
- EEPROM electrically erasable programmable read-only memory
- Trusted code executed upon boot-up of the target system 110 may be part of a basic input and output system (BIOS), or may be the core portion (kernel) of an operating system.
- the trusted code configures the system for operation, and configures other selected resources as secure resources.
- BIOS or kernel code By storing the BIOS or kernel code in a secure resource, the code is protected from modification by other programs, even if those programs are executing in supervisor mode. Only trusted code stored in a secure resource, such as the BIOS or kernel code itself, can make modifications to any portion of the trusted code (assuming the device within which the code is stored is writeable). Because trusted code is used to initialize the security configuration of the system before any other code executes, the secure resources of the system are also protected from unauthorized access or other tampering upon boot-up.
- each page attribute table is maintained within each memory (e.g., L1 data, L1 program, L2, and Main).
- each page attribute table has a plurality of entries wherein each entry determines, among other things, the security level of a page of the corresponding memory.
- entries within page attribute table 149 determine the security level of memory pages within L1 program memory 144 .
- the page attribute table entry is also updated to reflect the page attribute table entry of the source providing the updated instructions or data.
- the attribute corresponding to the memory page in L1 cache 130 where the data is stored is updated with the attribute corresponding to the memory page where the data is stored in L2 cache 150 .
- the attributes associated with the memory pages where the instructions or data are stored also ripple through the page attribute tables within each level of cache memory.
- each of the page attribute tables are each maintained within secure areas of memory to prevent unauthorized access and/or modification of the contents of the page attribute table. Thus, only trusted code and/or secure hardware may modify the contents of the page attribute tables.
- FIG. 2 illustrates an example of how some of the bits of a page attribute table entry may be used to determine the security level of an instruction, and to also control the export of debug and profiling information.
- the non-secure (NS) bit within the security field of the page attribute table entry shown reflects the security level of the page to which the entry corresponds. Thus, if a program instruction is read from main memory 164 , and the corresponding entry within page attribute table 169 indicates that the page is a secure page, the instruction read will be executed by processor 200 at a secure level and will be allowed to access other secure resources.
- the page attribute table entry shown in FIG. 2 also includes a secure emulation (EMU) bit within the security field. This bit, when combined with the non-secure bit, provides the ability to control the exportation of information when debugging and profiling a trusted applications using test interface 120 ( FIG. 1 ).
- EMU secure emulation
- FIG. 3A shows how the export of debug and profiling information from a memory 320 is controlled by the security field bits of a page attribute table (PAT) entry 302 .
- PAT entry 302 is associated with memory page 304 , which includes data 306 .
- PAT entry 302 provides the security field bits that control whether data 306 is exported as debug and profile data to test workstation 180 ( FIG. 1 ).
- Memory 320 couples to secure emulation logic 308 , which combines the security field bits of PAT entry 302 to generate secure emulation enable signal 309 . If the memory page is identified by the non-secure bit as a secure page, data will only be exported if the emulation bit is also asserted.
- Memory 320 and the output of secure emulation logic 308 both couple to inputs of AND gate 311 , allowing secure emulation enable signal 309 to act as a gating signal that enables the export of data 306 as memory debug and profile data 311 .
- This data is forwarded to test interface 120 ( FIG. 1 ) as part of the debug and profiling data 290 , which in turn is sent to test workstation 180 .
- the security level of a given pipeline stage reflects the security level of the instruction being executed by that pipeline stage.
- the security level of the instruction being executed is tracked by providing a register for at least some of the pipeline stages which each stores the security field bits of the page attribute table entry corresponding to the instruction being executed.
- the exportation of information related to instructions being processed by a pipelined processor stage may also be controlled using the security field bits associated with the instruction.
- FIG. 3B illustrates an example of an embodiment of a section of a pipelined processor 350 , which provides secure emulation logic that stores and decodes the security bits of an instruction executing at each pipeline stage.
- a program instruction and the corresponding security bits enter the pipeline at stage Si ( 332 ) and secure emulation logic (SE) 338 respectively. Both the program instruction and the security bits are synchronously shifted through the pipelined processor 350 until both have been processed by all of the pipeline stages in sequence as indicated by the arrows between stages shown in FIG. 3B .
- Each of the pipeline stages S 1 , S 2 and S 3 ( 332 , 334 , and 336 ) has corresponding secure emulation logic ( 338 , 340 , and 342 ).
- stage S 2 ( 334 ) has a security designation determined by SE 340 .
- SE 340 stores both the non-secure bit and the secure emulation bit for the instruction executed by stage S 2 .
- the bits are combined to generate secure emulation enable signal 341 .
- Processor stage S 2 and the output of secure emulation logic 340 both couple to inputs of AND gate 344 , allowing secure emulation enable signal 341 to act as a gating signal that enables the export of information related to processor stage 334 as processor stage debug and profile data 345 .
- This data is forwarded to test interface 120 ( FIG. 1 ) as part of the debug and profiling data 290 , which in turn is sent to test workstation 180 .
- registers within pipelined processor 350 of the illustrative embodiments described also store data and attribute bits.
- the attribute bits include security field bits that determine the security designation of the data stored within the register, as shown in FIG. 3C .
- Register 380 holds both register data 362 and an attribute 364 .
- Attribute 364 includes the same non-secure and secure emulation bits described in relation to the page attribute table entry of FIG. 2 .
- register 380 couples to secure emulation logic 366 , which combines the security field bits of attribute 364 to generate secure emulation enable signal 367 . If the register contents are identified by the non-secure bit as secure, the register contents will only be exported if the emulation bit is also asserted.
- Register 380 and the output of secure emulation logic 366 both couple to inputs of AND gate 368 , allowing secure emulation enable signal 367 to control the export of data 362 as register debug and profile data 369 .
- This data is forwarded to test interface 120 ( FIG. 1 ) as part of the debug and profiling data 290 , which in turn is sent to test workstation 180 .
- the non-secure and secure emulation bits described above are stored and combined as shown in the illustrative embodiment of secure emulation logic 400 of FIG. 4A , which is representative of the SE logic in FIGS. 3A, 3B and 3 C.
- Secure emulation input signal (EMU In) 401 and non-secure input signal (NS In) 403 drive the respective inputs that determine the values of the EMU and NS bits of security bits register 402 .
- These signals may be driven by a number of sources, including, for example, values loaded from memory (e.g., from page attribute table entry 302 of FIG. 3A ), or the security bits register of a preceding pipelined processor stage (e.g., the security bits register within SE 338 of FIG. 3B ).
- each bit of the security bits register 402 , secure emulation output signal (EMU Out) 405 and non-secure output signal (NS Out) 407 are provided as the inputs to OR gate 404 (and may also serve as inputs to another SE logic stage, as in the example of FIG. 3B ).
- the output of OR gate 404 (secure emulation stage enable signal 409 ) is used to gate debug and profile information exported by a data source (e.g., data 306 in FIG. 3A , stage S 2 information in FIG. 3B , and register data 362 in FIG. 3C ).
- the output of the OR gate is asserted regardless of the state of the secure emulation bit.
- the output of the OR gate depends upon the state of the secure emulation bit. For example, referring back to FIG. 3B , if the processor stage S 2 ( 334 ) is executing a secure instruction (i.e., the non-secure bit is not asserted), and the secure emulation bit is asserted, the output of SE 340 will be asserted.
- Debug and profile data 290 is forwarded to test interface 120 , and subsequently to workstation 180 .
- trusted applications can be debugged without adding any special code to the program that could alter the behavior of the code being tested.
- debugging is complete, only the boot-up code is altered, and only the value of the secure emulation bits for the pages of memory where trusted applications are stored are changed (and subsequently propagated throughout the system as the contents of the memory pages are loaded into registers and processor stages).
- the behavior of the trusted application will remain unaltered after the secure emulation bits are de-asserted.
- the secure emulation bits Once the secure emulation bits are de-asserted, access to the trusted application through the test interfaces is blocked, and the trusted application is protected from unauthorized access and observation. Such protection may be necessary, for example, if the trusted application handles encryption and decryption keys stored in secure memory. Such keys should not be accessible outside of a trusted, secure environment.
- the secure emulation configuration of the various secure applications that may be provided with the target system may also be changed after boot-up by a trusted application.
- a secure kernel within an operating system that is loaded from a trusted resource can make such changes, provided that an authentication mechanism exists to confirm that a user or application requesting the change is authorized to do so.
- FIG. 5 illustrates a system 500 for debugging a target system 510 , constructed in accordance with at least some illustrative embodiments, configured to provide such an authentication mechanism.
- Target system 510 includes processor 502 , which couples to memory 570 and test interface 520 .
- Test interface also couples to test workstation 580 , which executes debug and profiling application 582 .
- Operating system 504 includes kernel 506 , which executes on processor 502 .
- Target application 578 ′ also executes under operating system 504 on processor 502 , and represents the portion of target application 578 , resident within memory page 576 , that is currently loaded and executing within processor 502 .
- Memory 570 includes page attribute table (PAT) 572 , which includes PAT entry 574 .
- PAT entry 574 is associated with memory page 576 , which includes target application 578 .
- target application 578 is shown in FIG. 5 as contained within a single memory page, other applications may occupy more than one memory page, and all such applications are intended to be within the scope of the present disclosure.
- Kernel 506 communicates with both executing target application 578 ′ and with debug and profiling application 582 (via test interface 520 ). Kernel 506 , as a trusted application, has access to page attribute table 572 (stored in a secure area of memory). As a trusted application, kernel 506 is authorized to change the security field bits of PAT entries within page attribute table 572 . The ability to alter the security field bits of PAT entries allows secure applications to be debugged in the field, even though the secure emulation bits are de-asserted when the system is first booted. The state of the secure emulation bit within a PAT entry can be toggled by kernel 506 upon request from a user controlling debug and profiling application 582 .
- a request is sent by debug and profiling application 582 to kernel 506 , identifying executing target application 578 ′ as the application targeted by the request.
- Kernel 506 verifies that target application 578 ′ is executing on processor 502 and forwards the request to executing target application 578 ′.
- the request is authenticated by executing target application 578 ′, which notifies kernel 506 of the success or failure of the authentication of the security credentials presented by debug and profiling application 582 . If the authentication succeeds, the request to alter the state of the secure emulation bits is honored, and the secure emulation bit of PAT entry 572 (associated with target application 578 ) is updated to reflect the state requested.
- FIG. 6 illustrates a method 600 for requesting secure testing of a target application executing on a target system, in accordance with at least some illustrative embodiments.
- the debug and profiling application accepts a request from a user for secure testing of an application (block 602 ).
- the user generates the request by operating a test workstation (e.g., test workstation 580 of FIG. 5 ) on which the debug and profiling application executes.
- a request is built (block 604 ) that includes information that identifies the target application to be tested, as well as authentication credentials that can be verified by the target application to be tested (e.g., a digital signature generated by a private key provided by the user).
- the request is sent by the debug and profiling application to the kernel executing on the target system that also executes the target application (block 606 ).
- the debug and profiling application receives a response to the request from the kernel (block 608 ) and checks to see if the request was granted (block 610 ). If the request is granted, the debug and profiling application is given test access to the target application and can begin to receive debug and profiling test data from the target application, and the user may begin to test the target application (block 612 ). If the request is denied, the user is notified of the denial (block 614 ).
- the method 600 completes when the user ends the debug and profile session for the target application, or after the user is notified that the request was denied (block 616 ).
- FIG. 7 illustrates a method 700 for authenticating within a target application a request for secure testing of the target application, in accordance with at least some illustrative embodiments.
- the target application receives a request for secure testing of the target application from the kernel executing on the same target system as the target application (block 702 ).
- the target application authenticates credentials provided within the request to determine if the request originates from an authorized user (block 704 ). This may be done, for example, by applying a public decryption key, embedded within the application, to a digital signature included within the request to verify the authorization of the requestor. If the credentials are valid (block 706 ), the target application notifies the kernel that secure testing of the target application is allowed (block 708 ), and the method completes (block 712 ). If the credentials are not valid (block 706 ) the kernel is notified of the refusal (block 710 ) and the method completes (block 712 ).
- FIG. 8 illustrates a method 800 for receiving and processing a request for secure testing of a target application, and for acting on an authorized request, in accordance with at least some illustrative embodiments.
- the kernel executing on the target system receives a request for secure testing of a target application executing on the same target system as the kernel (block 802 ).
- the kernel checks to confirm that the target application identified in the request is actually executing (block 804 ), and the method ends if the application is not executing (block 820 ). If the target application is executing (block 804 ), the kernel forwards the received request to the target application for authorization (block 806 ).
- the kernel receives a response to the forwarded request (block 808 ), the response is check to determine if the request was authorized (block 810 ). If the request is not authorized by the target application, the kernel sends a message back to the originator of the request indicating that the secure testing request was denied (block 816 ), and the method ends (block 818 ). If the request is authorized by the target application, the kernel asserts the secure emulation bit of each page attribute table entry that is associated with a memory page in which the target application is loaded (block 812 ), thus enabling the export of debug and profiling data associated with the target application from the target system. The originator of the request is notified that the request was granted (block 814 ) and the method ends (block 818 ).
- a target system can include a collection of software applications from different vendors, with separate authentication information embedded within each vendor's software application. Since each vendor can embed their own authentication key within their respective applications, each vendor is limited to debugging their own application, and the target applications included by other vendors are thus not exposed by the first vendor's testing. Each vendor may thus allow secure testing of their target applications by an authorized user, without that authorization extending to a user authorized to debug another vendor's target application.
Abstract
The present disclosure describes systems and methods for controlling access to secure debugging and profiling features of a computer system. Some illustrative embodiments include a system that includes a processor, and a memory coupled to the processor (the memory used to store information and an attribute associated with the stored information). At least one bit of the attribute determines a security level, selected from a plurality of security levels, of the stored information associated with the attribute. Asserting at least one other bit of the attribute enables exportation of the stored information from the computer system if the security level of the stored information is higher than at least one other security level of the plurality of security levels.
Description
- The present application claims the benefit of provisional application Ser. No. 60/681,494, filed May 16, 2005 and entitled “Debug event instructions accesses application in secure mode,” and provisional application Ser. No. 60/681,427, filed May 16, 2005 and entitled “Debugging software-controlled cache coherence,” both of which are herein incorporated by reference. The present application is also related to non-provisional application U.S. Ser. No. ______, Attorney Docket No. TI-60629 (1962-33500); filed May 15, 2006 and entitled “Systems and Methods for Secure Debugging and Profiling of a Computer System,” which is also herein incorporated by reference.
- The increase in the complexity of modern microprocessors has created a comparable increase in the complexity of the tools used to debug and profile such microprocessors. In-circuit emulators have given way to microprocessors with built-in debug and test ports, through which external computer systems, running debug and test software, communicate with the microprocessor to debug problems and profile the performance of software executing on the microprocessor within a target system. But debug and test ports may be used by a malicious user to bypass security measures implemented within a microprocessor. Regardless of whether such security measures are implemented in hardware or software, the debug and test ports can potentially give a malicious user access to secure portions of a computer system that might otherwise be protected from unauthorized access during non-debug and non-test modes of operation.
- The present disclosure describes systems and methods for controlling access to secure debugging and profiling features of a computer system. Some illustrative embodiments include a system that includes a processor, and a memory coupled to the processor (the memory used to store information and an attribute associated with the stored information). At least one bit of the attribute determines a security level, selected from a plurality of security levels, of the stored information associated with the attribute. Asserting at least one other bit of the attribute enables exportation of the stored information from the computer system if the security level of the stored information is higher than at least one other security level of the plurality of security levels.
- Other illustrative embodiments include a method that includes receiving a request from a requestor to enable secure testing of a target application executing on a target system, sending an authorization request to the target application, and enabling secure testing of the target application and notifying the requester that secure testing is allowed, if the target application allows the request.
- Yet other illustrative embodiments include an Information carrier medium that includes software that can be executed on a processor to cause the processor to receive a request from a requester to enable secure testing of a target application executing on a target system; to send an authorization request to the target application; and to enable secure testing of the target application and notifying the requester that secure testing is allowed, if the target application allows the request.
- Still other illustrative embodiments include a method that includes receiving a request for secure test access to a target application executing within a target system, the request received by the target application, attempting to validate the authentication credentials within the request using validation data stored within the target application, and sending a response to the request indicating that secure test access is allowed if the authentication credentials are validated.
- Still further illustrative embodiments include an Information carrier medium comprising software that can be executed on a processor to cause the processor to receive a request for secure test access to a target application executing within a target system, the request received by the target application; to attempt to validate the authentication credentials within the request using validation data stored within the target application; and to send a response to the request indicating that secure test access is allowed if the authentication credentials are validated.
- Yet further illustrative embodiments include a method that includes receiving a request from a user to securely test a target application, sending a request to a target system to securely test the target application, the request comprising authentication credentials, and receiving test data from the target application if a response is received to the request sent to the target system indicating that test access to the target application is allowed.
- Still further illustrative embodiments include an Information carrier medium comprising software that can be executed on a processor to cause the processor to receive a request from a user to securely test a target application; to send a request to a target system to securely test the target application, the request comprising authentication credentials; and to receive test data from the target application if a response is received to the request sent to the target system indicating that test access to the target application is allowed.
- Yet further illustrative embodiments include a system for debugging and profiling a computer system that includes a target computer system comprising a processor, wherein an operating system executes on the processor and a target application and a kernel execute within the operating system on the processor, and further comprising a memory coupled to the processor, wherein the target application and a page attribute table are stored in the memory; and a test workstation coupled to the target system, wherein a debug and profiling application executes on the test workstation. The kernel asserts a bit within an entry in the page attribute table, the entry associated with the location in memory where the target application is stored, and the assertion enables the target application to provide test information to the debug and profiling application. The target application is stored in a secure region of memory and executes one the processor in a secure mode.
- For a detailed description of the illustrative embodiments of the invention, reference will now be made to the accompanying drawings in which:
-
FIG. 1 shows a system for testing and debugging a target system, in accordance with at least some illustrative embodiments; -
FIG. 2 shows a page attribute table entry, in accordance with at least some illustrative embodiments; -
FIG. 3A shows a memory with secure emulation logic, in accordance with at least some illustrative embodiments; -
FIG. 3B shows a portion of a pipelined processor with secure emulation logic, in accordance with at least some illustrative embodiments; -
FIG. 3C shows a processor register with secure emulation logic, in accordance with at least some illustrative embodiments; -
FIG. 4A shows secure emulation logic, in accordance with at least some illustrative embodiments; -
FIG. 4B shows a truth table for the secure emulation logic ofFIG. 4A ; -
FIG. 5 shows a system for testing and debugging a target system that uses a debug authentication mechanism, in accordance with at least some illustrative embodiments; -
FIG. 6 shows a method for requesting secure testing of a target application, in accordance with at least some illustrative embodiments; -
FIG. 7 shows a method for authenticating within a target application a request for secure testing, in accordance with at least some illustrative embodiments; and -
FIG. 8 shows a method for processing a request for secure testing of a target application, and for acting on an authorized request, in accordance with at least some illustrative embodiments. - Certain terms are used throughout the following discussion and claims to refer to particular system components. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including but not limited to . . . .” Also, the term “couple” or “couples” is intended to mean either an indirect or direct electrical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical connection, or through an indirect electrical connection via other devices and connections.
- Additionally, the term “system” refers to a collection of two or more parts and may be used to refer to an electronic system such as a computer system or a portion of a computer system. Further, the term “software” includes any executable code capable of running on a processor, regardless of the media used to store the software. Thus, code stored in non-volatile memory, and sometimes referred to as “embedded firmware,” is included within the definition of software.
- The following discussion is directed to various embodiments of the invention. Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure, including the claims, unless otherwise specified. The discussion of any embodiment is meant only to be illustrative of that embodiment, and not intended to intimate that the scope of the disclosure, including the claims, is limited to that embodiment.
-
FIG. 1 shows asystem 100 for debugging and profiling atarget system 110, constructed in accordance with at least some illustrative embodiments of the invention, which comprisesprocessor 200,memory system 170, and test interface (Test I/F) 120.Processor 200 couples to testinterface 120, which couples to bothmemory system 170 andtest workstation 180.Test workstation 180 permits a user to monitor debug and profilingdata 290 collected from bothprocessor 200 andmemory system 170 oftarget system 110, and further permits the user to control the testing oftarget system 110. Debug and profiling data may also be collected from a number of other sources withintarget system 110, and all such sources are intended to be within the scope of the present disclosure. -
Processor 200 also couples tomemory system 170, which compriseslevel 1 cache memory (L1 Cache) 130 (the highest cache level with the fastest memory), level 2 cache memory (L2 Cache) 150 (the lowest cache level with memory slower than the memory of the L1 cache), main memory subsystem 160 (with memory slower than the memory of both the L1 and L2 caches), and memory management unit (MMU) 125.L1 cache 130, which is the first level of a multilevel cached memory system, includesdata memory controller 132 andprogram memory controller 142, which each couple toprocessor 200.Data memory controller 132 couples toL1 data memory 134, which includes cached data (Data) 135, cached data tag information (Tag) 137, and data page attribute table (PAT) 139. Similarly,program memory controller 142 couples toL1 program memory 144, which includes cached program instructions (Prog) 145, cached instruction tag information (Tag) 147, and program page attribute table (PAT) 149. -
Data memory controller 132 andprogram memory controller 142 each couple tounified memory controller 152, which is part ofL2 cache 150.L2 cache 150 also includesL2 memory 154, which also couples tounified memory controller 152.L2 memory 154 includes cached data and program instructions (D/P) 155, cached data and program tag information (Tag) 157, and data and program page attribute table (PAT) 159.Unified memory controller 152 couples tomain memory controller 162, which is part ofmain memory subsystem 160.Main memory subsystem 160 also includesmain memory 164, which also couples tomain memory controller 162.Main memory 164 includes data andprogram information 165, as well as data and program page attribute table (PAT) 169.Memory management unit 125 couples to, and interacts with, each of the memory controllers (132, 142, 152, and 162) at each level of memory (L1, L2, and Main). - When
processor 200 reads an instruction or data from memory, an attempt is made to first retrieve the instruction or data fromL1 cache 130. If the instruction or data is not located withinL1 cache 130, an attempt is subsequently made to read the instruction or data fromL2 cache 150. If the instruction or data is located inL2 cache 150,L1 cache 130 may be updated to include the instruction or data from L2 cache 150 (making it available inL1 cache 130 for subsequent reads), andprocessor 200 may proceed with processing the instruction or data. If the instruction or data is not located withinL2 cache 150, the instruction or data is read frommain memory subsystem 160.L1 cache 130 andL2 cache 150 may be updated to include the instruction or data read. -
Processor 200, in accordance with at least some embodiments, is capable of executing code within two different execution modes, supervisor mode and user mode. In supervisor mode, all functions ofprocessor 200 are available to the program executing on the processor. In user mode, the program executing onprocessor 200 is blocked from executing some instructions and from accessing some control registers within the processor. This prevents an unprivileged program from bypassing the management of hardware by supervisory software.Processor 200 is also capable of operating at two different security levels, a secure level and a non-secure level. Resources (e.g., memory pages) withintarget system 110 are configured to operate at one of the two security levels, and programs executing while the processor is operating at a non-secure level are blocked from accessing resources configured as secure resources. - Security levels may be defined in a number of different ways depending upon the design of
processor 200. For example, in a single-stage processor, the security level reflects the security level of the instruction being executed by the processor. The security level of the instruction in turn depends upon the security level of the resource that stores the instruction (e.g., an instruction stored within a read-only memory that is configured as a secure resource is a secure instruction). Thus, if a single stage processor executes an instruction read from a secure memory, the instruction is a secure instruction and the processor is operating at a secure level. - Alternatively, if
processor 200 is a pipelined processor with multiple execution stages operating simultaneously, each stage operates at one of the defined security levels, independently of some or all other stages, Accordingly, the security level of each stage reflects the security level of the instruction being processed by that stage. Thus, if a secure instruction is being processed by an instruction fetch stage while a non-secure instruction is being processed by an instruction decode stage, the instruction fetch stage is operating at a secure level, and the instruction decode stage is operating at a non-secure level. Many alternative ways of defining security levels of a processor or processor stage, applicable to many types of processors, will become apparent to those skilled in the art, and all such definitions and processor types are intended to be within the scope of the present disclosure. - By combining multiple processor execution modes with resource specific security levels,
target system 110 can be configured to include “trusted” resources. These resources are configured to operate, execute and/or be accessed whileprocessor 200 is operating in supervisor mode by instructions loaded by the processor from a secure resource. Because the resource is secure, it may only be accessed by trusted code, and if the resource is a modifiable medium (e.g., a flash memory), the contents of the resource (i.e., the trusted code) may only be modified by the trusted code. Thus, for example,target system 100 is configured to initializeprocessor 200 in a supervisor mode, and to initially load and execute code from a secure region of non-volatile memory (e.g., an electrically erasable programmable read-only memory (EEPROM)). - Trusted code executed upon boot-up of the
target system 110 may be part of a basic input and output system (BIOS), or may be the core portion (kernel) of an operating system. In at least some embodiments, the trusted code configures the system for operation, and configures other selected resources as secure resources. By storing the BIOS or kernel code in a secure resource, the code is protected from modification by other programs, even if those programs are executing in supervisor mode. Only trusted code stored in a secure resource, such as the BIOS or kernel code itself, can make modifications to any portion of the trusted code (assuming the device within which the code is stored is writeable). Because trusted code is used to initialize the security configuration of the system before any other code executes, the secure resources of the system are also protected from unauthorized access or other tampering upon boot-up. - As noted above, a page attribute table is maintained within each memory (e.g., L1 data, L1 program, L2, and Main). In accordance with at least some embodiments, each page attribute table has a plurality of entries wherein each entry determines, among other things, the security level of a page of the corresponding memory. Thus, for example, entries within page attribute table 149 determine the security level of memory pages within
L1 program memory 144. Further, as instructions or data are updated within a particular cache level, the page attribute table entry (corresponding to the page of memory where the instruction or data is stored) is also updated to reflect the page attribute table entry of the source providing the updated instructions or data. - For example, if an attempt at reading data from
L1 cache 130 results in a cache miss, but the data is stored inL2 cache 150, the attribute corresponding to the memory page inL1 cache 130 where the data is stored is updated with the attribute corresponding to the memory page where the data is stored inL2 cache 150. Thus, as instructions or data ripple through the cache memory system, the attributes associated with the memory pages where the instructions or data are stored also ripple through the page attribute tables within each level of cache memory. It should be noted that each of the page attribute tables are each maintained within secure areas of memory to prevent unauthorized access and/or modification of the contents of the page attribute table. Thus, only trusted code and/or secure hardware may modify the contents of the page attribute tables. -
FIG. 2 illustrates an example of how some of the bits of a page attribute table entry may be used to determine the security level of an instruction, and to also control the export of debug and profiling information. The non-secure (NS) bit within the security field of the page attribute table entry shown reflects the security level of the page to which the entry corresponds. Thus, if a program instruction is read frommain memory 164, and the corresponding entry within page attribute table 169 indicates that the page is a secure page, the instruction read will be executed byprocessor 200 at a secure level and will be allowed to access other secure resources. The page attribute table entry shown inFIG. 2 also includes a secure emulation (EMU) bit within the security field. This bit, when combined with the non-secure bit, provides the ability to control the exportation of information when debugging and profiling a trusted applications using test interface 120 (FIG. 1 ). -
FIG. 3A shows how the export of debug and profiling information from amemory 320 is controlled by the security field bits of a page attribute table (PAT)entry 302.PAT entry 302 is associated withmemory page 304, which includesdata 306. Whendata 306 is read frommemory page 304,PAT entry 302 provides the security field bits that control whetherdata 306 is exported as debug and profile data to test workstation 180 (FIG. 1 ).Memory 320 couples to secureemulation logic 308, which combines the security field bits ofPAT entry 302 to generate secure emulation enablesignal 309. If the memory page is identified by the non-secure bit as a secure page, data will only be exported if the emulation bit is also asserted.Memory 320 and the output ofsecure emulation logic 308 both couple to inputs of ANDgate 311, allowing secure emulation enablesignal 309 to act as a gating signal that enables the export ofdata 306 as memory debug andprofile data 311. This data is forwarded to test interface 120 (FIG. 1 ) as part of the debug andprofiling data 290, which in turn is sent to testworkstation 180. - As already noted, in a pipelined architecture, the security level of a given pipeline stage reflects the security level of the instruction being executed by that pipeline stage. In accordance with at least some embodiments, the security level of the instruction being executed is tracked by providing a register for at least some of the pipeline stages which each stores the security field bits of the page attribute table entry corresponding to the instruction being executed. As with
memory 320 ofFIG. 3A , the exportation of information related to instructions being processed by a pipelined processor stage may also be controlled using the security field bits associated with the instruction. -
FIG. 3B illustrates an example of an embodiment of a section of a pipelinedprocessor 350, which provides secure emulation logic that stores and decodes the security bits of an instruction executing at each pipeline stage. A program instruction and the corresponding security bits enter the pipeline at stage Si (332) and secure emulation logic (SE) 338 respectively. Both the program instruction and the security bits are synchronously shifted through the pipelinedprocessor 350 until both have been processed by all of the pipeline stages in sequence as indicated by the arrows between stages shown inFIG. 3B . Each of the pipeline stages S1, S2 and S3 (332, 334, and 336) has corresponding secure emulation logic (338, 340, and 342). For example stage S2 (334) has a security designation determined bySE 340.SE 340 stores both the non-secure bit and the secure emulation bit for the instruction executed by stage S2. The bits are combined to generate secure emulation enablesignal 341. Processor stage S2 and the output ofsecure emulation logic 340 both couple to inputs of ANDgate 344, allowing secure emulation enablesignal 341 to act as a gating signal that enables the export of information related toprocessor stage 334 as processor stage debug andprofile data 345. This data is forwarded to test interface 120 (FIG. 1 ) as part of the debug andprofiling data 290, which in turn is sent to testworkstation 180. - Similarly, registers within pipelined
processor 350 of the illustrative embodiments described also store data and attribute bits. The attribute bits include security field bits that determine the security designation of the data stored within the register, as shown inFIG. 3C .Register 380 holds bothregister data 362 and anattribute 364.Attribute 364 includes the same non-secure and secure emulation bits described in relation to the page attribute table entry ofFIG. 2 . Continuing to refer toFIG. 3C , register 380 couples to secureemulation logic 366, which combines the security field bits ofattribute 364 to generate secure emulation enablesignal 367. If the register contents are identified by the non-secure bit as secure, the register contents will only be exported if the emulation bit is also asserted.Register 380 and the output ofsecure emulation logic 366 both couple to inputs of ANDgate 368, allowing secure emulation enablesignal 367 to control the export ofdata 362 as register debug andprofile data 369. This data is forwarded to test interface 120 (FIG. 1 ) as part of the debug andprofiling data 290, which in turn is sent to testworkstation 180. - The non-secure and secure emulation bits described above are stored and combined as shown in the illustrative embodiment of
secure emulation logic 400 ofFIG. 4A , which is representative of the SE logic inFIGS. 3A, 3B and 3C. Secure emulation input signal (EMU In) 401 and non-secure input signal (NS In) 403 drive the respective inputs that determine the values of the EMU and NS bits of security bits register 402. These signals may be driven by a number of sources, including, for example, values loaded from memory (e.g., from pageattribute table entry 302 ofFIG. 3A ), or the security bits register of a preceding pipelined processor stage (e.g., the security bits register withinSE 338 ofFIG. 3B ). Referring again toFIG. 4A , the output of each bit of the security bits register 402, secure emulation output signal (EMU Out) 405 and non-secure output signal (NS Out) 407, are provided as the inputs to OR gate 404 (and may also serve as inputs to another SE logic stage, as in the example ofFIG. 3B ). The output of OR gate 404 (secure emulation stage enable signal 409) is used to gate debug and profile information exported by a data source (e.g.,data 306 inFIG. 3A , stage S2 information inFIG. 3B , and registerdata 362 inFIG. 3C ). - As can be seen in logic table shown in
FIG. 4B , when the non-secure bit is asserted, the output of the OR gate is asserted regardless of the state of the secure emulation bit. When the non-secure bit is not asserted, the output of the OR gate depends upon the state of the secure emulation bit. For example, referring back toFIG. 3B , if the processor stage S2 (334) is executing a secure instruction (i.e., the non-secure bit is not asserted), and the secure emulation bit is asserted, the output ofSE 340 will be asserted. Assertion of the output ofSE 340 allows information from stage S2 to be forwarded through ANDgate 344 as processor stage debug and profile data signal 345, and to be transmitted as part of debug and profile data 290 (FIG. 1 ). Debug andprofile data 290 is forwarded to testinterface 120, and subsequently toworkstation 180. - By using a configuration bit to control access to secure debugging and profiling information, trusted applications can be debugged without adding any special code to the program that could alter the behavior of the code being tested. Once debugging is complete, only the boot-up code is altered, and only the value of the secure emulation bits for the pages of memory where trusted applications are stored are changed (and subsequently propagated throughout the system as the contents of the memory pages are loaded into registers and processor stages). Thus, the behavior of the trusted application will remain unaltered after the secure emulation bits are de-asserted. Once the secure emulation bits are de-asserted, access to the trusted application through the test interfaces is blocked, and the trusted application is protected from unauthorized access and observation. Such protection may be necessary, for example, if the trusted application handles encryption and decryption keys stored in secure memory. Such keys should not be accessible outside of a trusted, secure environment.
- The secure emulation configuration of the various secure applications that may be provided with the target system may also be changed after boot-up by a trusted application. For example, a secure kernel within an operating system that is loaded from a trusted resource (as previously described in the context of a system boot) can make such changes, provided that an authentication mechanism exists to confirm that a user or application requesting the change is authorized to do so.
FIG. 5 illustrates asystem 500 for debugging atarget system 510, constructed in accordance with at least some illustrative embodiments, configured to provide such an authentication mechanism. -
Target system 510 includesprocessor 502, which couples tomemory 570 andtest interface 520. Test interface also couples to testworkstation 580, which executes debug andprofiling application 582.Operating system 504 includeskernel 506, which executes onprocessor 502.Target application 578′ also executes underoperating system 504 onprocessor 502, and represents the portion oftarget application 578, resident withinmemory page 576, that is currently loaded and executing withinprocessor 502.Memory 570 includes page attribute table (PAT) 572, which includesPAT entry 574.PAT entry 574 is associated withmemory page 576, which includestarget application 578. Althoughtarget application 578 is shown inFIG. 5 as contained within a single memory page, other applications may occupy more than one memory page, and all such applications are intended to be within the scope of the present disclosure. -
Kernel 506 communicates with both executingtarget application 578′ and with debug and profiling application 582 (via test interface 520).Kernel 506, as a trusted application, has access to page attribute table 572 (stored in a secure area of memory). As a trusted application,kernel 506 is authorized to change the security field bits of PAT entries within page attribute table 572. The ability to alter the security field bits of PAT entries allows secure applications to be debugged in the field, even though the secure emulation bits are de-asserted when the system is first booted. The state of the secure emulation bit within a PAT entry can be toggled bykernel 506 upon request from a user controlling debug andprofiling application 582. - For example, a request is sent by debug and
profiling application 582 tokernel 506, identifying executingtarget application 578′ as the application targeted by the request.Kernel 506 verifies thattarget application 578′ is executing onprocessor 502 and forwards the request to executingtarget application 578′. The request is authenticated by executingtarget application 578′, which notifieskernel 506 of the success or failure of the authentication of the security credentials presented by debug andprofiling application 582. If the authentication succeeds, the request to alter the state of the secure emulation bits is honored, and the secure emulation bit of PAT entry 572 (associated with target application 578) is updated to reflect the state requested. -
FIG. 6 illustrates amethod 600 for requesting secure testing of a target application executing on a target system, in accordance with at least some illustrative embodiments. The debug and profiling application accepts a request from a user for secure testing of an application (block 602). The user generates the request by operating a test workstation (e.g.,test workstation 580 ofFIG. 5 ) on which the debug and profiling application executes. Continuing to refer toFIG. 6 , a request is built (block 604) that includes information that identifies the target application to be tested, as well as authentication credentials that can be verified by the target application to be tested (e.g., a digital signature generated by a private key provided by the user). The request is sent by the debug and profiling application to the kernel executing on the target system that also executes the target application (block 606). The debug and profiling application receives a response to the request from the kernel (block 608) and checks to see if the request was granted (block 610). If the request is granted, the debug and profiling application is given test access to the target application and can begin to receive debug and profiling test data from the target application, and the user may begin to test the target application (block 612). If the request is denied, the user is notified of the denial (block 614). Themethod 600 completes when the user ends the debug and profile session for the target application, or after the user is notified that the request was denied (block 616). -
FIG. 7 illustrates amethod 700 for authenticating within a target application a request for secure testing of the target application, in accordance with at least some illustrative embodiments. The target application receives a request for secure testing of the target application from the kernel executing on the same target system as the target application (block 702). The target application authenticates credentials provided within the request to determine if the request originates from an authorized user (block 704). This may be done, for example, by applying a public decryption key, embedded within the application, to a digital signature included within the request to verify the authorization of the requestor. If the credentials are valid (block 706), the target application notifies the kernel that secure testing of the target application is allowed (block 708), and the method completes (block 712). If the credentials are not valid (block 706) the kernel is notified of the refusal (block 710) and the method completes (block 712). -
FIG. 8 illustrates amethod 800 for receiving and processing a request for secure testing of a target application, and for acting on an authorized request, in accordance with at least some illustrative embodiments. The kernel executing on the target system receives a request for secure testing of a target application executing on the same target system as the kernel (block 802). The kernel checks to confirm that the target application identified in the request is actually executing (block 804), and the method ends if the application is not executing (block 820). If the target application is executing (block 804), the kernel forwards the received request to the target application for authorization (block 806). Once the kernel receives a response to the forwarded request (block 808), the response is check to determine if the request was authorized (block 810). If the request is not authorized by the target application, the kernel sends a message back to the originator of the request indicating that the secure testing request was denied (block 816), and the method ends (block 818). If the request is authorized by the target application, the kernel asserts the secure emulation bit of each page attribute table entry that is associated with a memory page in which the target application is loaded (block 812), thus enabling the export of debug and profiling data associated with the target application from the target system. The originator of the request is notified that the request was granted (block 814) and the method ends (block 818). - The combination of the above-described methods allows individual secure applications to provide a mechanism for providing debugging and profiling information after delivery of a system (hardware and software) and deployment in the field. Further, a target system can include a collection of software applications from different vendors, with separate authentication information embedded within each vendor's software application. Since each vendor can embed their own authentication key within their respective applications, each vendor is limited to debugging their own application, and the target applications included by other vendors are thus not exposed by the first vendor's testing. Each vendor may thus allow secure testing of their target applications by an authorized user, without that authorization extending to a user authorized to debug another vendor's target application.
- The above disclosure is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
Claims (39)
1. A computer system, comprising:
a processor; and
a memory coupled to the processor, the memory used to store information and an attribute associated with the stored information;
wherein at least one bit of the attribute determines a security level, selected from a plurality of security levels, of the stored information associated with the attribute; and
wherein asserting at least one other bit of the attribute enables exportation of the stored information from the computer system if the security level of the stored information is higher than at least one other security level of the plurality of security levels.
2. The computer system of claim 1 , wherein the security level of the stored information is a secure level, and the at least one other security level is a non-secure level.
3. The computer system of claim 1 , further comprising a test interface configured to couple to a test workstation, wherein the test interface is capable of transmitting the exported stored information to the test workstation.
4. The computer system of claim 1 , wherein the stored information is an instruction that can be executed by the processor.
5. The computer system of claim 1 , wherein the stored information is data that can be read and processed by the processor.
6. The computer system of claim 1 , wherein the processor comprises a processing stage, and wherein a security level of the processing stage is the security level of the stored information if the stored information is an instruction loaded into the processing stage.
7. The computer system of claim 6 , wherein exportation from the computer system of the instruction loaded into the processing stage and state information of the processing stage is enabled if the at least one other bit of the attribute is asserted, and if the security level of the processing stage is higher than the at least one other security level.
8. The computer system of claim 7 , further comprising a test interface configured to couple to a test workstation, wherein the test interface is capable of transmitting the exported instruction and state information to the test workstation.
9. The computer system of claim 1 , wherein the processor comprises a register, and wherein a security level of the register is the security level of the stored information if the stored information is data loaded into the register.
10. The computer system of claim 9 , wherein exportation from the computer system of the data loaded into the register is enabled if the at least one other bit of the attribute is asserted, and if the security level of the register is higher than the at least one other security level.
11. The computer system of claim 10 , further comprising a test interface configured to couple to a test workstation, wherein the test interface is capable of transmitting the exported data to the test workstation.
12. The computer system of claim 1 , wherein a single semiconductor die comprises the computer system.
13. A method, comprising:
receiving a request from a requestor to enable secure testing of a target application executing on a target system;
sending an authorization request to the target application; and
enabling secure testing of the target application and notifying the requestor that secure testing is allowed, if the target application allows the request.
14. The method of claim 13 , further comprising notifying the requestor that test access is denied if the target application rejects the request.
15. The method of claim 13 , further comprising:
storing the target application in a secure region of a memory within the target system;
storing a secure emulation bit in the memory; and
associating the secure emulation enable bit with the secure region of memory;
wherein enabling secure testing of the target application comprises asserting the secure emulation bit.
16. The method of claim 13 , wherein the target application is one of a plurality of applications executing on the target system, and wherein enabling secure testing of the target application does not comprise enabling secure testing of other applications of the plurality of applications.
17. The method of claim 13 , further comprising executing a kernel module of an operating system on the target system, wherein the kernel modules receives the request.
18. An Information carrier medium comprising software that can be executed on a processor to cause the processor to:
receive a request from a requester to enable secure testing of a target application executing on a target system;
send an authorization request to the target application; and
enable secure testing of the target application and notify the requestor that secure testing is allowed, if the target application allows the request.
19. The information carrier medium of claim 18 , wherein the software further causes the processor to notify the requester that test access is denied if the target application rejects the request.
20. The information carrier medium of claim 18 , wherein the software further causes the processor to:
store the target application in a secure region of a memory within the target system;
store a secure emulation bit in the memory; and
associate the secure emulation enable bit with the secure region of memory;
wherein causing the processor to enable secure testing of the target application comprises asserting the secure emulation bit.
21. The information carrier medium of claim 18 , wherein the target application is one of a plurality of applications executing on the target system, and wherein causing the processor to enable secure testing of the target application does not comprise causing the processor to enable secure testing of other applications of the plurality of applications.
22. The information carrier medium of claim 18 , wherein the software further causes the processor to execute a kernel module of an operating system on the target system, wherein the kernel modules receives the request.
23. A method, comprising:
receiving a request for secure test access to a target application executing within a target system, the request received by the target application;
attempting to validate the authentication credentials within the request using validation data stored within the target application; and
sending a response to the request indicating that secure test access is allowed if the authentication credentials are validated.
24. The method of claim 23 , further comprising sending a response to the request indicating that secure test access is denied if the authentication credentials are not validated.
25. The method of claim 23 , wherein the validation data comprises one or more public encryption keys and the authentication credentials comprise a digital signature generated using a private encryption key, and wherein attempting to validate the authentication credentials comprises using the one or more public decryption keys to validate the digital signature.
26. The method of claim 23 , further comprising configuring the target application to receive the request from a kernel module of an operating system executing on the target system.
27. An Information carrier medium comprising software that can be executed on a processor to cause the processor to:
receive a request for secure test access to a target application executing within a target system, the request received by the target application;
attempt to validate the authentication credentials within the request using validation data stored within the target application; and
send a response to the request indicating that secure test access is allowed if the authentication credentials are validated.
28. The information carrier medium of claim 27 , wherein the software further causes the processor to send a response to the request indicating that secure test access is denied if the authentication credentials are not validated.
29. The information carrier medium of claim 27 , wherein the validation data comprises one or more public encryption keys and the authentication credentials comprise a digital signature generated using a private encryption key, and wherein causing the processor to attempt to validate the authentication credentials comprises using the one or more public decryption keys to validate the digital signature.
30. The information carrier medium of claim 27 , wherein the software further causes the processor to configure the target application to receive the request from a kernel module of an operating system executing on the target system.
31. A method, comprising:
receiving a request from a user to securely test a target application;
sending a request to a target system to securely test the target application, the request comprising authentication credentials; and
receiving test data from the target application if a response is received to the request sent to the target system indicating that test access to the target application is allowed.
32. The method of claim 31 , wherein no test data is received from the target application if a response to the request sent to the target system is received indicating that test access to the target application is denied.
33. The method of claim 31 , further comprising generating the authentication credentials by creating a digital signature based upon a private encryption key.
34. An Information carrier medium comprising software that can be executed on a processor to cause the processor to:
receive a request from a user to securely test a target application;
send a request to a target system to securely test the target application, the request comprising authentication credentials; and
receive test data from the target application if a response is received to the request sent to the target system indicating that test access to the target application is allowed.
35. The information carrier medium of claim 34 , wherein no test data is received from the target application if a response to the request sent to the target system is received indicating that test access to the target application is denied.
36. The information carrier medium of claim 34 , wherein the software further causes the processor to generate the authentication credentials by creating a digital signature based upon a private encryption key.
37. A system for debugging and profiling a computer system, comprising:
a target computer system comprising a processor, wherein an operating system executes on the processor and a target application and a kernel execute within the operating system on the processor, and further comprising a memory coupled to the processor, wherein the target application and a page attribute table are stored in the memory; and
a test workstation coupled to the target system, wherein a debug and profiling application executes on the test workstation;
wherein the kernel asserts a bit within an entry in the page attribute table, the entry associated with the location in memory where the target application is stored, and the assertion enables the target application to provide test information to the debug and profiling application; and
wherein the target application is stored in a secure region of memory and executes one the processor in a secure mode.
38. The system of claim 37 , wherein the target application authorizes the kernel to assert the bit within the page attribute table entry.
39. The system of claim 37 , wherein the debug and profiling application initiates the request to enable the target application to provide test information to the debug and profiling application.
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/383,475 US20060259828A1 (en) | 2005-05-16 | 2006-05-15 | Systems and methods for controlling access to secure debugging and profiling features of a computer system |
US14/179,765 US9633213B2 (en) | 2005-05-16 | 2014-02-13 | Secure emulation logic between page attribute table and test interface |
US15/471,234 US10025955B2 (en) | 2005-05-16 | 2017-03-28 | Pipeline processor execution stages, secure emulation logic, gating debug/profile output |
US16/009,754 US10438023B2 (en) | 2005-05-16 | 2018-06-15 | Pipeline processor data and attribute register, secure emulation logic, gating |
US16/540,938 US11580264B2 (en) | 2005-05-16 | 2019-08-14 | Systems and methods for controlling access to secure debugging and profiling features of a computer system |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US68149405P | 2005-05-16 | 2005-05-16 | |
US68142705P | 2005-05-16 | 2005-05-16 | |
US11/383,475 US20060259828A1 (en) | 2005-05-16 | 2006-05-15 | Systems and methods for controlling access to secure debugging and profiling features of a computer system |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/179,765 Division US9633213B2 (en) | 2005-05-16 | 2014-02-13 | Secure emulation logic between page attribute table and test interface |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060259828A1 true US20060259828A1 (en) | 2006-11-16 |
Family
ID=37420618
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/383,475 Abandoned US20060259828A1 (en) | 2005-05-16 | 2006-05-15 | Systems and methods for controlling access to secure debugging and profiling features of a computer system |
US15/471,234 Active US10025955B2 (en) | 2005-05-16 | 2017-03-28 | Pipeline processor execution stages, secure emulation logic, gating debug/profile output |
US16/009,754 Active US10438023B2 (en) | 2005-05-16 | 2018-06-15 | Pipeline processor data and attribute register, secure emulation logic, gating |
US16/540,938 Active 2027-12-22 US11580264B2 (en) | 2005-05-16 | 2019-08-14 | Systems and methods for controlling access to secure debugging and profiling features of a computer system |
Family Applications After (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/471,234 Active US10025955B2 (en) | 2005-05-16 | 2017-03-28 | Pipeline processor execution stages, secure emulation logic, gating debug/profile output |
US16/009,754 Active US10438023B2 (en) | 2005-05-16 | 2018-06-15 | Pipeline processor data and attribute register, secure emulation logic, gating |
US16/540,938 Active 2027-12-22 US11580264B2 (en) | 2005-05-16 | 2019-08-14 | Systems and methods for controlling access to secure debugging and profiling features of a computer system |
Country Status (1)
Country | Link |
---|---|
US (4) | US20060259828A1 (en) |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070180269A1 (en) * | 2006-02-01 | 2007-08-02 | International Business Machines Corporation | I/O address translation blocking in a secure system during power-on-reset |
GB2449454A (en) * | 2007-05-22 | 2008-11-26 | Advanced Risc Mach Ltd | Cache memory storing validity data and control data for the cached data, such that the control data can be modified by the attached processor. |
GB2471482A (en) * | 2009-06-30 | 2011-01-05 | Nokia Corp | Secure method of tracing software |
US20140223237A1 (en) * | 2013-02-04 | 2014-08-07 | Alcatel-Lucent | Systems and methods for dynamic scan scheduling |
US20140258665A1 (en) * | 2010-03-30 | 2014-09-11 | Fujitsu Limited | Storage device, data processing device, registration method, adn recording medium |
US20150106871A1 (en) * | 2013-10-15 | 2015-04-16 | Electronics And Telecommunications Research Institute | System and method for controlling access to security engine of mobile terminal |
KR20150043954A (en) * | 2013-10-15 | 2015-04-23 | 한국전자통신연구원 | Access control system and method to security engine of mobile terminal |
US20150195276A1 (en) * | 2005-09-21 | 2015-07-09 | Broadcom Corporation | System and Method For Securely Provisioning and Generating One-Time-Passwords In A Remote Device |
US9172701B2 (en) | 2012-12-27 | 2015-10-27 | Netiq Corporation | Techniques for secure debugging and monitoring |
US20160224098A1 (en) * | 2015-01-30 | 2016-08-04 | Alexander Gendler | Communicating via a mailbox interface of a processor |
US9507931B2 (en) | 2014-02-10 | 2016-11-29 | Samsung Electronics Co., Ltd. | Security device and controlling method thereof |
US9910756B2 (en) * | 2015-09-03 | 2018-03-06 | International Business Machines Corporation | Response-time baselining and performance testing capability within a software product |
US10120999B2 (en) | 2012-03-30 | 2018-11-06 | Irdeto B.V. | Method and system for preventing and detecting security threats |
US20190361073A1 (en) * | 2018-05-24 | 2019-11-28 | Seagate Technology Llc | Secure debug system for electronic devices |
US10620266B2 (en) | 2017-11-29 | 2020-04-14 | Intel Corporation | System, apparatus and method for in-field self testing in a diagnostic sleep state |
US11741196B2 (en) | 2018-11-15 | 2023-08-29 | The Research Foundation For The State University Of New York | Detecting and preventing exploits of software vulnerability using instruction tags |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20230050729A1 (en) * | 2021-08-13 | 2023-02-16 | Texas Instruments Incorporated | Resource access security for multiple software contexts |
Citations (12)
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 |
US5623627A (en) * | 1993-12-09 | 1997-04-22 | Advanced Micro Devices, Inc. | Computer memory architecture including a replacement cache |
US5689565A (en) * | 1995-06-29 | 1997-11-18 | Microsoft Corporation | Cryptography system and method for providing cryptographic services for a computer application |
US20010016916A1 (en) * | 1998-08-06 | 2001-08-23 | Albrecht Mayer | Programmable unit |
US20010018736A1 (en) * | 2000-02-14 | 2001-08-30 | Kabushiki Kaisha Toshiba | Tamper resistant microprocessor |
US6345383B1 (en) * | 1994-09-14 | 2002-02-05 | Kabushiki Kaisha Toshiba | Debugging support device and debugging support method |
US20030005417A1 (en) * | 2001-06-29 | 2003-01-02 | Gard James J. | Debugger for a hardware-implemented operating system |
US6622184B1 (en) * | 1999-06-04 | 2003-09-16 | Kabushiki Kaisha Toshiba | Information processing system |
US6662314B1 (en) * | 1999-11-15 | 2003-12-09 | Mitsubishi Denki Kabushiki Kaisha | Microcomputer including program for rewriting data in an internal flash memory |
US20040010702A1 (en) * | 2002-07-12 | 2004-01-15 | Lewis Timothy A. | Secure system firmware by disabling read access to firmware ROM |
US20040143714A1 (en) * | 2002-11-18 | 2004-07-22 | Arm Limited | Apparatus and method for controlling access to a memory unit |
US6968420B1 (en) * | 2002-02-13 | 2005-11-22 | Lsi Logic Corporation | Use of EEPROM for storage of security objects in secure systems |
Family Cites Families (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE69415600T2 (en) | 1993-07-28 | 1999-07-15 | Koninkl Philips Electronics Nv | Microcontroller with hardware troubleshooting support based on the boundary scan method |
US5530804A (en) * | 1994-05-16 | 1996-06-25 | Motorola, Inc. | Superscalar processor with plural pipelined execution units each unit selectively having both normal and debug modes |
US5889988A (en) * | 1995-01-03 | 1999-03-30 | Intel Corporation | Debugger for debugging tasks in an operating system virtual device driver |
US6205560B1 (en) | 1996-02-27 | 2001-03-20 | Via-Cyrix, Inc. | Debug system allowing programmable selection of alternate debug mechanisms such as debug handler, SMI, or JTAG |
US5838897A (en) | 1996-02-27 | 1998-11-17 | Cyrix Corporation | Debugging a processor using data output during idle bus cycles |
US6112298A (en) * | 1996-12-20 | 2000-08-29 | Texas Instruments Incorporated | Method for managing an instruction execution pipeline during debugging of a data processing system |
US6185732B1 (en) | 1997-04-08 | 2001-02-06 | Advanced Micro Devices, Inc. | Software debug port for a microprocessor |
US6092180A (en) * | 1997-11-26 | 2000-07-18 | Digital Equipment Corporation | Method for measuring latencies by randomly selected sampling of the instructions while the instruction are executed |
US6542966B1 (en) | 1998-07-16 | 2003-04-01 | Intel Corporation | Method and apparatus for managing temporal and non-temporal data in a single cache structure |
US7225333B2 (en) * | 1999-03-27 | 2007-05-29 | Microsoft Corporation | Secure processor architecture for use with a digital rights management (DRM) system on a computing device |
US6804782B1 (en) | 1999-06-11 | 2004-10-12 | General Instrument Corporation | Countermeasure to power attack and timing attack on cryptographic operations |
US6367032B1 (en) | 1999-10-21 | 2002-04-02 | Sony Corporation Of Japan | Method and system for debugging a microprocessor core |
AU1405100A (en) * | 1999-12-15 | 2001-06-25 | Sun Microsystems, Inc. | Open debugging environment |
US6591378B1 (en) | 2000-02-22 | 2003-07-08 | Motorola, Inc. | Debug controller in a data processor and method therefor |
US7036129B1 (en) * | 2000-03-06 | 2006-04-25 | Pc-Doctor, Inc. | Diagnostic system integrated with device drivers of an operating system |
US7428661B2 (en) * | 2001-09-21 | 2008-09-23 | Sam Michael | Test and debug processor and method |
EP1331539B1 (en) * | 2002-01-16 | 2016-09-28 | Texas Instruments France | Secure mode for processors supporting MMU and interrupts |
US7149862B2 (en) * | 2002-11-18 | 2006-12-12 | Arm Limited | Access control in a data processing apparatus |
US7707621B2 (en) * | 2002-12-02 | 2010-04-27 | Silverbrook Research Pty Ltd | Creation and usage of mutually exclusive messages |
US7237151B2 (en) | 2002-12-17 | 2007-06-26 | Texas Instruments Incorporated | Apparatus and method for trace stream identification of a processor reset |
US7574585B1 (en) * | 2003-01-31 | 2009-08-11 | Zilog, Inc. | Implementing software breakpoints and debugger therefor |
US6963963B2 (en) * | 2003-03-25 | 2005-11-08 | Freescale Semiconductor, Inc. | Multiprocessor system having a shared main memory accessible by all processor units |
US8612992B2 (en) * | 2003-04-09 | 2013-12-17 | Jaluna Sa | Operating systems |
US7197745B2 (en) * | 2003-05-02 | 2007-03-27 | Microsoft Corporation | User debugger for use on processes running in a high assurance kernel in an operating system |
US7248069B2 (en) | 2003-08-11 | 2007-07-24 | Freescale Semiconductor, Inc. | Method and apparatus for providing security for debug circuitry |
US7321957B2 (en) * | 2003-10-24 | 2008-01-22 | Intel Corporation | Debugging a trusted component in a system |
US7334120B2 (en) * | 2003-11-14 | 2008-02-19 | Intel Corporation | Firmware emulation environment for developing, debugging, and testing firmware components including option ROMs |
US20050216895A1 (en) * | 2004-03-23 | 2005-09-29 | Tran Hieu T | Method and apparatus for remote debugging of kernel and application software |
US7313730B1 (en) | 2004-05-20 | 2007-12-25 | Xilinx, Inc. | Configuration logic for embedded software |
US20060294312A1 (en) * | 2004-05-27 | 2006-12-28 | Silverbrook Research Pty Ltd | Generation sequences |
JP4296996B2 (en) * | 2004-06-15 | 2009-07-15 | 富士通株式会社 | Multi-core processor control system |
JP4533682B2 (en) * | 2004-06-29 | 2010-09-01 | 株式会社東芝 | Trace analysis apparatus and trace analysis method |
US8181219B2 (en) * | 2004-10-01 | 2012-05-15 | Microsoft Corporation | Access authorization having embedded policies |
US7627784B1 (en) * | 2005-04-06 | 2009-12-01 | Altera Corporation | Modular processor debug core connection for programmable chip systems |
-
2006
- 2006-05-15 US US11/383,475 patent/US20060259828A1/en not_active Abandoned
-
2017
- 2017-03-28 US US15/471,234 patent/US10025955B2/en active Active
-
2018
- 2018-06-15 US US16/009,754 patent/US10438023B2/en active Active
-
2019
- 2019-08-14 US US16/540,938 patent/US11580264B2/en active Active
Patent Citations (12)
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 |
US5623627A (en) * | 1993-12-09 | 1997-04-22 | Advanced Micro Devices, Inc. | Computer memory architecture including a replacement cache |
US6345383B1 (en) * | 1994-09-14 | 2002-02-05 | Kabushiki Kaisha Toshiba | Debugging support device and debugging support method |
US5689565A (en) * | 1995-06-29 | 1997-11-18 | Microsoft Corporation | Cryptography system and method for providing cryptographic services for a computer application |
US20010016916A1 (en) * | 1998-08-06 | 2001-08-23 | Albrecht Mayer | Programmable unit |
US6622184B1 (en) * | 1999-06-04 | 2003-09-16 | Kabushiki Kaisha Toshiba | Information processing system |
US6662314B1 (en) * | 1999-11-15 | 2003-12-09 | Mitsubishi Denki Kabushiki Kaisha | Microcomputer including program for rewriting data in an internal flash memory |
US20010018736A1 (en) * | 2000-02-14 | 2001-08-30 | Kabushiki Kaisha Toshiba | Tamper resistant microprocessor |
US20030005417A1 (en) * | 2001-06-29 | 2003-01-02 | Gard James J. | Debugger for a hardware-implemented operating system |
US6968420B1 (en) * | 2002-02-13 | 2005-11-22 | Lsi Logic Corporation | Use of EEPROM for storage of security objects in secure systems |
US20040010702A1 (en) * | 2002-07-12 | 2004-01-15 | Lewis Timothy A. | Secure system firmware by disabling read access to firmware ROM |
US20040143714A1 (en) * | 2002-11-18 | 2004-07-22 | Arm Limited | Apparatus and method for controlling access to a memory unit |
Non-Patent Citations (1)
Title |
---|
Sklavos et al., Reconfigurable crypto processor design of encryption algorithms operation modes methods and FPGA integration, December 2003, 2003 IEEE 46th Midwest Symposium on Circuits and Systems, vol. 2, pp. 811-814 * |
Cited By (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150195276A1 (en) * | 2005-09-21 | 2015-07-09 | Broadcom Corporation | System and Method For Securely Provisioning and Generating One-Time-Passwords In A Remote Device |
US20070180269A1 (en) * | 2006-02-01 | 2007-08-02 | International Business Machines Corporation | I/O address translation blocking in a secure system during power-on-reset |
GB2449454A (en) * | 2007-05-22 | 2008-11-26 | Advanced Risc Mach Ltd | Cache memory storing validity data and control data for the cached data, such that the control data can be modified by the attached processor. |
US20080294848A1 (en) * | 2007-05-22 | 2008-11-27 | Arm Limited | Control data modification within a cache memory |
GB2449454B (en) * | 2007-05-22 | 2011-08-24 | Advanced Risc Mach Ltd | Control data modification within a cache memory |
US8131942B2 (en) | 2007-05-22 | 2012-03-06 | Arm Limited | Control data modification within a cache memory |
GB2471482A (en) * | 2009-06-30 | 2011-01-05 | Nokia Corp | Secure method of tracing software |
US20140258665A1 (en) * | 2010-03-30 | 2014-09-11 | Fujitsu Limited | Storage device, data processing device, registration method, adn recording medium |
US9367485B2 (en) * | 2010-03-30 | 2016-06-14 | Fujitsu Limited | Storage device, data processing device, registration method, and recording medium |
US20210173922A1 (en) * | 2012-03-30 | 2021-06-10 | Irdeto B.V. | Method and system for preventing and detecting security threats |
US10635807B2 (en) | 2012-03-30 | 2020-04-28 | Irdeto B.V. | Method and system for preventing and detecting security threats |
US10242184B2 (en) | 2012-03-30 | 2019-03-26 | Irdeto B.V. | Method and system for preventing and detecting security threats |
US10120999B2 (en) | 2012-03-30 | 2018-11-06 | Irdeto B.V. | Method and system for preventing and detecting security threats |
US10635808B2 (en) | 2012-03-30 | 2020-04-28 | Irdeto B.V. | Method and system for preventing and detecting security threats |
US9723007B2 (en) | 2012-12-27 | 2017-08-01 | Netiq Corporation | Techniques for secure debugging and monitoring |
US10171470B2 (en) | 2012-12-27 | 2019-01-01 | Netiq Corporation | Techniques for secure debugging and monitoring |
US9172701B2 (en) | 2012-12-27 | 2015-10-27 | Netiq Corporation | Techniques for secure debugging and monitoring |
US20140223237A1 (en) * | 2013-02-04 | 2014-08-07 | Alcatel-Lucent | Systems and methods for dynamic scan scheduling |
US9183105B2 (en) * | 2013-02-04 | 2015-11-10 | Alcatel Lucent | Systems and methods for dynamic scan scheduling |
KR102201218B1 (en) * | 2013-10-15 | 2021-01-12 | 한국전자통신연구원 | Access control system and method to security engine of mobile terminal |
KR20150043954A (en) * | 2013-10-15 | 2015-04-23 | 한국전자통신연구원 | Access control system and method to security engine of mobile terminal |
US20150106871A1 (en) * | 2013-10-15 | 2015-04-16 | Electronics And Telecommunications Research Institute | System and method for controlling access to security engine of mobile terminal |
US9507931B2 (en) | 2014-02-10 | 2016-11-29 | Samsung Electronics Co., Ltd. | Security device and controlling method thereof |
US10719326B2 (en) | 2015-01-30 | 2020-07-21 | Intel Corporation | Communicating via a mailbox interface of a processor |
US20160224098A1 (en) * | 2015-01-30 | 2016-08-04 | Alexander Gendler | Communicating via a mailbox interface of a processor |
US9910756B2 (en) * | 2015-09-03 | 2018-03-06 | International Business Machines Corporation | Response-time baselining and performance testing capability within a software product |
US10360126B2 (en) | 2015-09-03 | 2019-07-23 | International Business Machines Corporation | Response-time baselining and performance testing capability within a software product |
US10620266B2 (en) | 2017-11-29 | 2020-04-14 | Intel Corporation | System, apparatus and method for in-field self testing in a diagnostic sleep state |
US10962596B2 (en) | 2017-11-29 | 2021-03-30 | Intel Corporation | System, apparatus and method for in-field self testing in a diagnostic sleep state |
US20190361073A1 (en) * | 2018-05-24 | 2019-11-28 | Seagate Technology Llc | Secure debug system for electronic devices |
US11105850B2 (en) * | 2018-05-24 | 2021-08-31 | Seagate Technology Llc | Secure debug system for electronic devices |
US11741196B2 (en) | 2018-11-15 | 2023-08-29 | The Research Foundation For The State University Of New York | Detecting and preventing exploits of software vulnerability using instruction tags |
Also Published As
Publication number | Publication date |
---|---|
US20180293405A1 (en) | 2018-10-11 |
US10025955B2 (en) | 2018-07-17 |
US20190370502A1 (en) | 2019-12-05 |
US10438023B2 (en) | 2019-10-08 |
US11580264B2 (en) | 2023-02-14 |
US20170206381A1 (en) | 2017-07-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11580264B2 (en) | Systems and methods for controlling access to secure debugging and profiling features of a computer system | |
CN107771335B (en) | Protected area | |
CN109918919B (en) | Management of authentication variables | |
US7010684B2 (en) | Method and apparatus for authenticating an open system application to a portable IC device | |
US7139915B2 (en) | Method and apparatus for authenticating an open system application to a portable IC device | |
JP4872001B2 (en) | Memory access safety management | |
US7020772B2 (en) | Secure execution of program code | |
US7149854B2 (en) | External locking mechanism for personal computer memory locations | |
JP4925422B2 (en) | Managing access to content in data processing equipment | |
US9740887B2 (en) | Methods and systems to restrict usage of a DMA channel | |
JP5752767B2 (en) | Processor, method and system using multiple authenticated code modules | |
US20080046762A1 (en) | Protecting system control registers in a data processing apparatus | |
JP2006507548A (en) | Authentication code method and apparatus | |
Nasahl et al. | Hector-v: A heterogeneous cpu architecture for a secure risc-v execution environment | |
US20070180269A1 (en) | I/O address translation blocking in a secure system during power-on-reset | |
JP3982687B2 (en) | Controlling access to multiple isolated memories in an isolated execution environment | |
US8108905B2 (en) | System and method for an isolated process to control address translation | |
US7774758B2 (en) | Systems and methods for secure debugging and profiling of a computer system | |
US9633213B2 (en) | Secure emulation logic between page attribute table and test interface | |
KR100643814B1 (en) | Method and apparatus for communicating securely with a token | |
Sahita et al. | Security analysis of confidential-compute instruction set architecture for virtualized workloads | |
US11734457B2 (en) | Technology for controlling access to processor debug features | |
JP2021012679A (en) | Controller with flash emulation function and control method | |
Stoyanov et al. | Secure Heterogeneous Architecture based on RISC-V and root-of-trust | |
Ciravegna | Detecting compromise in TEE applications at runtime |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: TEXAS INSTRUMENTS, INC., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SWOBODA, GARY L.;REEL/FRAME:017845/0877 Effective date: 20060515 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |